Normal DevOps can be a challenge to set up. Yet, DevOps for SAP CPI should be very easy to set up.
I have received numerous questions about how we set up DevOps for our SAP Integration Suite/Cloud Integration (CPI). Additionally, people wanted to get started with some DevOps process to control their code and deployments easily. However, there are a couple challenges.
Two challenges:
- Where is the master source of the code? Is it the Web IDE or your Git repository?
- How many projects will you have? One global project or one project for each IFlow?
There are two options for setting this up: using Flashpipe or using SAP’s Jenkins pipelines.
We also made a PoC on using our Open Source Gradle plugins for Azure DevOps that works well. I don’t really like the solution because it is difficult to see what has changed and this requires a lot of effort from the developers. Also, branching was not easy for developers. In most cases only one developer will be working on an IFlow at the time or otherwise you will encounter some problems.
Why the Figaf DevOps Suite is different
We tried to make our application easy to use so you do not need to spend hours to create the infrastructure needed for a migration. It should be easy to help developers get started with and govern.
Testing is also an important part of the process and the Figaf DevOps Suite is built around a testing tool for Integration flows so it is effortless to start with creating the transport.
The process of delivering integration has improved a lot both in terms of time it takes to process but also with the richness of functionality. See what the transport of an IFlow can look like from the developer perspective.
The transport process
You simply select the IFlow you want to transport and assign it to a ticket.
Then you can add test cases already created for the IFlows and attach them to the ticket. This way you are able to test all the IFlows you have in your change.
Next, you will then be able to run the tests with a few clicks and see if the IFlows perform as expected. If there are changes, you can easily update the test cases to match the IFlow.
Then you create the transport from the ticket. From there you can see all the artifacts you want to transport. Plus, you will also be able to compare the IFlow in a number of ways.
In the transport you now have access to configure the IFlow across the landscape.
After filling the information, you can send the transport to Approval. Here the architect can compare the IFlow in a number of different ways to see what has changed to make informed decisions if the IFlow can be approved.
Lastly, after the IFlow is approved it can be imported, configured and deployed.
Improved governance
One of the important aspects of the Figaf DevOps Suite is the ability to improve the governance process. This is where our software has a lot of advantages including:
- You can find changes and approve them
- Handle the 2-eyes principle about approval of transports
- The changes in configuration happens via Figaf, so they will be a part of your approval process
- The different ways for you to compare versions of IFlows either when transporting or in the history
- Possible to check all changes from the Figaf DevOps Suite and link to Service Requests/Tickets
- Users should not have access to QA or Production systems because it makes it more difficult to log changes
The Figaf DevOps Suite can do so much more
The Figaf DevOps Suite does contain a lot more details to simplify the operations like monitoring and much more advanced features to deploy IFlows.
