Posts

Governing SAP CPI with Figaf Tools Webinar replay

Managing and running an SAP CPI system can be easy. You can if you don’t have any quality control and can move everything. I have examples on fixing a feature request and move it to production in 30 minutes. No governance was made in this process. Which was not optimal nobody would know what was going on.

If you want to be able to govern the approach then you need it will take some longer. Govern is about managing the process to ensure there is proper audit trail for all changes, testing, and documentation is in place. This is something that can take a lot of manual hours to get working. With the Figaf tool we have automated the full process, so you developers, architects, and business experts no longer need to spend as much time on the tasks.

You can see the replay of a webinar below. This covers a lot of the process around change management and it even shows what is possible with the development process.

Try the Figaf tool

You can try the Figaf tool you can signup here

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.

If you want to see how our tool works to make DevOps possible check this video

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.

Watch the full flow of Figaf to handle SAP CPI Change Management

We have an integrated approach for handling Change Management for SAP CPI (Cloud Platform Integration aka HCI). In this video (25 minutes) I show how the full application is connected. It is a way to have a central place to manage all your SAP Integration development.

In the video I show how you can get a good change management process for SAP CPI with

  • Full traceability for all modifications made for the development, and linking with business request
  • Ability to view differences between objects and understand how they have been changed because of a business request
  • Test the process have been developed correctly
  • Configuration of Iflows across the landscape, so there are no manual steps for the transport
  • Transport of individual iflows in the landscape
  • Document all changes in the process

There is also part of the monitoring that makes monitoring of the CPI easier and enables you to setup alerting if a message is in a specific state.

If you like it and want to see how we are able to support the change management process in SAP PI/PO.

If you want to try it out then try our cloud offering for Figaf IRTCloud

How do you Document your SAP CPI Iflows

Documentation of integration has always been a strange thing. It has been pretty difficult to make sure we documented the details correctly and had enough information with. Normally you will just get some document designed to document some other thing and then try to adapt it to your integration. That will never give a good result. You may be compliant but just a waste of time if the documentation is not useful.

For SAP PI/PO we have for ages been using a Word template for the documentation of each interface. We support that with the Figaf IRT tool, so you can generate it fast. You can see an example of the SAP PI documentation here. The inspiration was to avoid having the documentation that was never updated and always had the initial version.

SAP Best practive

I did find an example of a SAP CPI template in the best practice guide. I did not like if for a few assumptions:

  • It was focusing on the wrong things that were a bit to detailed and too generic. Like a file conversion, or mapping it just has empty tabs that users need to fill in.
  • It could not be automated every well, which ment it did require a lot of user governance to host the information
  • It was juggling 3 different adapters and not showing the required details

I wanted to improve the process and make it even easier to capture the most important part of a CPI Iflow. It ended up with the following information:

  • Overview of the iFlow header information like name and description
  • History of changes logged with business requirements
  • Connection sender and receiver together with information
  • Test cases you have created for the tool
  • Flow description which is a table representation of the iflow. It will give some overview of how the different steps are connected
  • Configuration parameters configured in the full landscape, so you got some information on what is being used and the relavant resources.
  • Resources and the lat change data for them.

You can download an example of the document here for the SF to AD iflow.

There are ways to improve the document with more information. If you have anything that you think will provide value and make it easier to understand the documentation. Do let us know.

Automated documentation does have some limits like being able to update it different places, and add the extra information that makes sense.

You can try it own on your own iflows and see how it performs in your landscape.