Posts

Change Management can be simple

In the old-time, you had the SAP R3 ABAP system. There it was a pretty good tool to do change management. There was a limited number of objects that you could change and they could all be managed by one way of handling transports. In the new world, it is a lot more complicated.

Now the landscape is completely different. You have many different services that you need to find a way to manage. And if you start using SAP cloud solutions many of them have their own way of handling transports.

I have created a video to show, how I see the concept in some more details.

You have two options for Change Management: A generic approach or a specialized approach for your most important systems.

Generic Change management

No matter what you need to develop change, everything is handled in the same way. Then all developers know how to do change management for everything. It will speed up making it possible for other developers to handle the tooling.

The downside is that you will need to make a process that can encompass all systems. You will, therefore, get to little information or spend to much time creating the documents that you need for your project.

You may also miss an important part, and that is the ability to like changes both ways

Tool specific change management

If you have a lot of development or highly critical tools. It does make sense to have a better way to handle it.

When we are working on our Java application for the Figaf tool. We use Jira to create tickets in, Developers will then use this ticket number for all commits to a given ticket. Changes to our unit tests are also linked with the ticket. That is allowing us to trace all changes back to a ticket. That is a hyper-specialized tool to make change management for just one case. It can then be bundled with Jenkins to make build and test automation.

This type of specialization of your change management saves you time for your development. Because developers don’t need to note all the different places they are making modifications. It is handled automatically by the tool and captured as a part of the change.

Sure it will cost you more to buy or create an environment. It will cost both money, time and effort to get it working. Hopefully, this investment will be returned with better documentation, easier change management and faster delivery of code.

If you are using SAP Integrations products like SAP PI/PO, CPI or API mgt then we have a tool that will allow you to optimize your delivery process. Check the tools at https://figaf.com/IRT there are even free versions that allow you to get started.

With our approach we will handle all the tool-specific requirements in our application and then let your original system containing all organizational data.

Virtual SAP CPI landscapes

Some SAP CPI customers do not have a full 3 tier system landscape for their SAP CPI. But you may want to experience having all the systems connected and be able to test the flow. You can do it manually, with using the copy functionality, but it requires a lot of governance to keep the QA updated.

We did originally create the virtual landscape just to test, how our transport system worked because we did only have one CPI system. Now we have improved the functionality because it enables customers to take advance of our transport and leverage using one CPI system. We did earlier change Sender system to match with having a prefix with the system name.

We have now improved the functionality so the system is added to the Process Direct adapter. Here we are adding the prefix in the URL to both sender and receiver channels. You will thereby have the option to run it in a “QA environment”.

You can see a demonstration of how this works in the video.

Updated: If you import a package it will be auto deployed.

The transportation system also provide option to create Iflow documentation, and you can test the impact of a change. You can also make modification of Externalize Parameters across the landscape, so you can specify that the target URL on QA is this. Then IRT will handle the configuration once it deploys.

Try it out the Figaf IRT tool as an onpremish or use our cloud for it.

Figaf now improves your SAP PI/PO CTS transports

SAP PI/PO Change management and documentation have not developed much. And the full cycle of development is the same. It is really a manual process that requires people are spending a lot of time on documentation.

Is your Integration Important. Do you want to minimize the downtime and failures? Then the documentation and QA important.

If you are doing spending too much time on documentation, and if you are not you don’t have enough documentation of the changes made.

We have automated the full process from start to end designed to optimize SAP PI/PO. So you can get the transport documented with all integration objects have been changed.

This means that all your SAP PI/PO transports will be

  • Documented all your development objects
  • Changed link to a business reason, so you know how have approved the change and why.
  • Tested and validated in the QA system with same set of test cases, so you know that everything works as expected.
  • Configured in once place so developers do not need access to configure production system
  • Linking with the incident system so you can get information about what is wrong with your system faster

Check out the video

Because of the above reason, you will be able to:

  • Deliver integrations faster because of an automated delivery process with less time consumption
  • Happier employees because they do not need to perform documentation manually
  • Your QA process will be a lot faster because you don’t have everything delivered automatically
  • Higher quality with fewer errors because you are able to test all integrations fast
  • Fewer differences in the productive system because people are not doing modifications in other systems

Try IRT

We also support the same change management process for SAP CPI

SAP PI/PO Governance made easy

One of the biggest challenges with SAP PI/PO has been the lack of governance models for users. Documentation part has really been lacking making it and it has required a lot of manual work to get it done.

The process for handling governance for SAP PI/PO is just the same as with SAP XI for 15 years ago. The tooling has not changed much. There have just been a few changes that could say to improve the area. Ever since I started with XI/PI i have been working on different ways to improve the process of documentation but we have not made the dream solution yet.

Last year we added the option to use the ticket and thereby log changes to any object in SAP PI and PO, so all versions between them would be remembered. This was the first step in making documentation easier with Figaf IRT.

Now we are ready with the next big thing liking the full development together. So all documentation of your development is linked to CTS transports. That way you will know why something was changed and can see what is being transported much more transparent.

We have also added a central configuration of your channels. So there is just one place where you need to configure the information. IRT will then apply the configuration once the transport has been imported.

You can then make exports of your Integration scenarios documentation, and then show a changelog of this. And also show what was performed as a result of a ticket that you can add to your Jira, Solman to prove what you have done.

Here you can find the recording of the webniar that I did on 1 May 2019, where we showed this information to the public.

We are soon adding this to the release, so signup to check out the current version, and be the first to know once we have released the new iteration. If you have ideas on how to improve the tool and be a part of the beta program reach out to support@figaf.com.

Figaf IRT now supports API management

Over the last couple of weeks, we have been making transports easier for SAP CPI. Now the turn has come to SAP API management. As I understand from APIGEE the normal way is to have a build server that allows you to transport and test scripts. It does require some time and skill in setting up such a server. From the last roadmap session SAP was planing to relase some CTS+ integration in Q3 if I recall correct.

We are using the same approach to document changes of APIProxies. So you can see which Proxy part has been updated, or which script was changed. This makes it a lot easier to document what is going on and why something was changed. You will therefore know what is changed in each release.

We also allows users to make transports based on the business requirements. It is therefore easier to document changes made to the proxy, and link all changes to a business reason.

You can try it out your self at Figaf IRTCloud and see how it performs in your landscape.

With Figaf IRT you have one enviorment that allow you to document all your SAP Integrations in just one application.

We are going to add other functions to monitor your API management, so you can get some more detailed alerts about what is going on in your landscape.