For the SAP CPI projects that I have been involved in, I have seen some challenges with how to use SAP CPI tool. It is some of them we have been adding to the Figaf IRT tool, making it a lot easier for you to run SAP CPI.
Some of the features that we have implemented may at some point be implemented by SAP as a part of the standard SAP CPI flow. I know some are scheduled, but not when they will be delivered and the scope of them. I hope that we will be able to integrate the functions and still provide some better functions.
I do think that some of the features will be useful for you, and make your SAP CPI development process even faster.
About Figaf IRT
Figaf IRT is an application, we started about 3 years ago to make it easier to test SAP PI/PO. Our first approach for testing was not good, but we since had a number of implements. A lot has happened in the process, we are doing much more than just testing. It also handles the full change management process, enabling you to test all affected interfaces by a change.
We have added SAP CPI support about 1 year ago, and have since improved the tool a lot in the area. There is a number of different improvements that I’m currently working to give a better development environment for SAP CPI.
Change management process
I think one of the biggest aspects of developing Integration flows fast is the ability to manage what is changed and how is released.
It is difficult to see what the difference is between two versions of an iflow. There is no comparison between them. You just have two version numbers and hopefully some text description.
The Figaf IRT tool is constantly downloading all your CPI content. This includes the BPMN model, scripts, mappings, and configuration parameters. The system can then give you a comparison between two versions and show what was changed in the versions.
You can then take an iflow version and assign to a ticket. The Ticket is a concept in Figaf IRT that can contain all relevant information about the change. The change should be linked to a business requirement like Service Request, Request for Change, Jira ticket or incident, that way you can document what is happening. IRT is not a replacement for those systems, just a good way to create data for it automatically.
Configuration in your landscape
You want a way to transport your SAP CPI integrations. So you have a way you can transport your SAP CPI iflows.
When we tested it initially we only had access to one CPI instance, so we created a virtual landscape. This meant that it would just rename the object to allow it to be imported. It did prove to be a useful way to reuse your development system for test/QA also.
You can add as many systems as you want to the transport flow. And it is also possible to have one development tenant that transports to multiple different systems.
Transportation of Iflow
There is a number of different ways to transport SAP CPI content. You can use CTS+ for transport or you can use normal file-based approach. There is also a cloud transport system, that could be used. In most cases, you need to transport packages and not individual iflows. It could lead to some challenges with regards to understanding what is released.
We wanted to make it simple to only transport one integration flow at a time, so you know what was changed at that point in time. Since you have already linked the change with a business reason it makes sense to be able to transport that iflow across the landscape. So you can have one or more iflows in one transport.
So from a ticket, you can transport the iflows that have been changed across your landscape. You can see when they were created and create new transports. Once you import an iflow the configuration for the landscape is applied.
Another problem with at least the file transport is that you needed to configure everything again. It meant you had to configure the parameters that changed every time. If there was not a lot of parameters is was okay, but you had to remember to change them and deploy.
We added an option to configure all parameters in an iflow in just one screen. That way there is no reason for manual configuration by users after the transport has been imported.
There is even a warning if the specified password/certificate property is not on the expected target system.
Documentation is an important part of a software lifecycle process. There are different needs for all customers. Most cases I have seen two different types of documentation. In an SAP PI/PO world, this is the kind of document that is created with a lot of copy paste to show what kind of object, interfaces, and channels is used. For SAP CPI the structure of the content is different
- Is the documentation that describes having been developed. Both some text that describes the process, what are some of the resources that are used, and what kind of connections it has.
- Documentation of all change made to the process, so people are able to understand why something has been changed. And how you have tested the process.
The documents can normally take a lot of time to craft and place in the correct location for future reference. We have made that process an integrated part of the application so you can create the two documentations with a click of a button. You will then get standard content that makes it a lot easier for you to see what has been developed.
You need to have a good way to test all of your SAP CPI iflows. I have seen many iflows that can be tricky to run, and if the main developers leaves it is almost impossible to figure out what is going on. It should be possible for developers to run the test to validate that nothing vital has changed.
We opted to make testing based on the tracing data provided by setting the Iflow into trace mode. Then it becomes possible to download all data on the different stages like headers, properties, and body. This serves as a baseline.
If you want to retest you can then just send the first payload and headers into the flow. You do need to have an adapter that you can trigger. Then it is just about running the message and download all the trace data and compare it. The system allows you to ignore headers, payloads that change between run. So you can easily see if there were errors you did not expect.
You also have the option to set up test cases with SOAPUI or other testing application that you would normally use. It does require that you have set up your scenario to be able to process such requests, which some times can be challenging to create.
In Figaf we have automated the process about creating tests cases from the Trace data and then sent the payload in again. It supports a number of different ways of testing because some scenarios may be really difficult testing.
- Normal testing if the sender adapter is HTTP, ProcessDirect or SOAP.
- Mock data service where the iflow is converted to a Mock iflow where the calls instead of calling original endpoints will call the Figaf IRT system via HTTP. This makes it possible to test the cases where you cannot easily fetch the data again.
You will get a comparison as the one above, here you can see what is changed. Hopefully, it will be all green. The two options make it a lot easier to run the test to make sure you know what is changed in your iflows. And it can be a part of your scenario documentation.
SAP has been improving SAP CPI for to solve customers need. I do hope they will in some areas be able to solve the challenges that we have to address in our tool. It would obviously be better if there is a standard solution to solve the challenges. In the meantime, I hope our tool can make it possible to speed up your integration development. There will be areas that will not be covered by the standard functions.
We are also adding new functions constantly making it a lot easier to run and monitor SAP CPI. We also have a host of other functions that could make it into other blogs like monitoring, alerting and generation of test scripts from content and sharing of scripts between iflows.
There is a free 30 days trial of the Figaf cloud, that you can sign up for.
If you have any questions or feedback do let me know.