In this post I'll write about how it is possible to create a better way to transport and govern SAP Integration transport. The Figaf tool is integrating all the components required for performing and documenting transport like testing, change tracking, configuration and documentation.Since February this year, Figaf IRT have created our own transport mechanism for SAP CPI, to allow users to transport individual iflows. So you do not need to only transport single iflows. We added support for API mgt proxies also. And later we added options if customers were using CTS+ for SAP PI.
We had a task to create a migration tool for SAP PI/PO, that will allow users to automate the copy, configuration, transport test and documentation of a migration project. For that, to work we need to create our own way of handling transport. Then the part grew and we could use it for a much broader purpose for migrations.
Why a different transport system makes sense
Over the year I have present our vision for governance for SAP PI/PO. In this process, we have asked if they used CTS+/Charm or file-based integrations. Maybe 40% is using file-based transports. I managed to setup CTS+ in 5 hours, so it is not difficult.
The biggest challenge I have with it that CTS+ transports are just a blob of objects. Sure you can go see what is in transport if you wanted to but it will take some time figuring out what is in the transport.
You will still have to perform manual steps once the transports have been imported, which is that takes time and may result in other changes than excepted change.
For CPI you have the option to use CTS+ also or SAP Cloud Platform Transport Management. Both of the options does currently only give you the option to transport full packages. It either means you must manage your iflows pr packaged after your release strategy and not what makes sense. I'm sure they will be able to transport individual iflows sometime.
For API mgt there is a new command-line SDK out that will allow you to export an iflow and import it to different tenants. So it will fit well if you use some tool for the deployment part.
Figaf Transport
So over the last year, we have improved the way we handled transports as all been improved in just one go.
1) Version control
The process starts with Figaf monitors and synchronizes all the Repository and Directory from PI/PO, Iflows from CPI, and Proxies from API Mgt. This will be saved so and each time a new version is created it will be saved here. You can then see when the object has been changed, and you will be able to see when something was changed and if it uses other objects.
An example of such a version is the following of a CPI iflow. Here we able to see when the different resources were changed and if there was any tickets for it. It is possible to compare different versions of objects so you can see specifically what was changed between versions. This gives a great insight into what is happening in the landscape.
For SAP PI/PO it will list all the links between objects so you can move from ICO to Operation Mappings or the other direction.
You can trigger a synchronization of the agent or just let the scheduled part process it.
2) Ticket assigning
Once your development is done it is time to document it. We use the concept ticket to cover the reason why you are making the modification. In most cases, this will be the Service Request, ServiceNow request, Jira Issue or Solution Manager issue you want to solve. The Figaf ticket will not replace those systems, it is just a way to save the relevant information about the change. After completion of the change, you can upload relevant information to the service desk system. In the ticket, you also specify which landscape the change is related to.
We can add the ticket directly from any of our version objects or we can assign the objects to a ticket.
Now I have created a ticket that contains the objects that are affected by the changed.
3) Testing
Nobody should release anything that has not been tested.
We did start out at creating a testing tool, so the Figaf will enable you to test quite well no matter if it is SAP CPI or SAP PI/PO. Based in the objects on your Ticket the Figaf tool will lookup all relevant test cases. This way you can run all your regression tests and see how they perform.
You can run the test cases on multiple platforms on Development or QA.
There are a number of options for how you can run the tests both for SAP PI or CPI. In general, they work by sending a message thru the iflow / ICO and then check if the output is as it was supposed to be.
You will need to check for errors in the flow. If the errors are just the change you expected then you can accept the result and set is as the new expected testing result. You can also create new test cases to ensure you test the new feature you want to validate.
4) Transport
Now you can start the transport. Just click the button to start transport. The transport works a little different depending on if it is CPI or PI you are transporting.
4.1) CPI Transport
The CPI transport contains all the iFlows that you have added to the processing. You can see if there has been added different iflows to the transport.
If you click the cogwheel you will be able to configure how the iFlow should be configured across the landscape. This will allow you to specify what hosts, users or keys should be different in the different systems. This configuration will then be applied once the iflow is imported to the environment.
If an authentication artifact is missing in the target landscape it will give a warning you probably better correct before you continue the transport. You will also get a warning when you import the transport to the environment if something is missing.
4.2) SAP PI Transport
The SAP PI transports are a little different. The reason is that we both have Repository and Directory, that need to be handled a little different.
Repository objects need to be transported pr SWCV. In our overview, we now have the option to view all objects in transport. If we click the scale we will be able to see how this version is different than what currently is running in the target environments.
For Directory transport, you have the option to see all objects that will be transported. Here you can also click on the cogwheel to configure what values for all artifacts should be in the target enviorment.
You can then configure what should happend with objects once they are imported to QA or production. This is what you normally will specify in some document and send to the people doing the configuration.
The system will perform some validations like you need to have filled in passwords if they exist on the development system. We add more of the validations depending on customer requirements.
You can seven simulate how this transport would be different than what is configured before.
4.3) SAP API management
The API management part works just the same ways as CPI transports. You can transport one API Proxy at the time. We may add the other objects where some configuration may be possible at a later stage.
5) Transport approval
Once developers have done all the development, test and configuration of the transport it can be sent to approval. Then the Architect in charge of governance can see if the objects are in the transport.
You can configure if transports on a landscape should be approved and by which users. If approval is required the transport cannot be imported before it is transported.
Here the architect can also use the simulate buttons to see what will happen if the change is approved.
Once the transport has been approved it is not possible to make modifications to the configurations. So if you want to fix something you have to cancel the transport and create new transport with the new configurations.
6) Import
Now you have the option to import to the QA environment by clicking the import button.
The tool will then import to the relevant system, apply configuration and if needed deploy the flow. It will also do a new synchronization and link the object in QA/Production system with the ticket. Then you know if there is an object that does not have a ticket number in production something is not documented.
For SAP CPI we support virtual landscapes, here the tool will use the same tenant but just add pre and postfixes to technical names and update URLs with prefixes. This is convenient if you do not have a 3 tier landscape.
7) Ticket documentation
The tool can now generate a report in Excel that states what objects have been touched as a part of this change. You can then upload it to your ticket system as proof of what as been done.
You can also generate iflow and ICO documentation, that will contain information about all the parts that were changed and link to tickets.
Roadmap
I hope we will never finish the Figaf tool, there is still room for improvement in the process. So the next part we will look at is how you configure QA and Production. Should it automatically run test cases, do they need to pass, do you need an extra sign off, when should it be imported.
For validation, I would also like to add CPILint, since it will give much more validation for CPI flows. And then extend the to use some new objects like CPI value mappings, API mgt Products and KVM.
Open Connector could also be run using the same transport mechanism if it is requested by customers.
Try Figaf out
We have tried to make the Figaf tool as simple as possible to use so you can get started fast.
You can signup at
It is pretty simple to run on your laptop.
- Register on https://figaf.com/irt
- Download the Jar file
- Run the Jar file
- Add the license from the email
- Add agents
- Create a landscape
- Start transporting
I do hope you like the tool and want to purchase it. For our cloud offering, we start at 450 EUR/month and for our SAP PI/PO offering the solution starts at 15.000 EUR/year.
Comments
We are working to improve the solution to make it easier to run SAP Integration. If you have any wishes or ideas for improvements please let me know.
- SAP Managed Tags:
