Once I started to make my first SAP CPI transports I did not like that you needed to transport the full package. I wanted just to transport a single Iflow and log what was changed with it, then I knew what was being changed. But it was a rather difficult process to make sure you did it correctly. So I thought we could optimize the process to make it easier to apply transports for single iflows.
Update: This blog was written in February 2019. The tool has evolved since but the concept still reflects the same process with a number of improvements.
So we have created a flow for developers where they will make the normal changes.
- Save it as a version in the development CPI system after normal development
- Syncronize the IRT with the CPI system (by clicking the button or wait for the scheduled synchronization job)
- Create a ticket and assign the object version to the ticket. A ticket can correspond to a Service Request or Incident. It is possible to update the version if you have multiple attempts to fix the problems
- From the ticket, you then create transport with one of the Iflow on the systems
- IRT can then import that QA/production system. It will delete the existing iflow and upload the new version.
I have recorded a demonstration video you can see how it works
The following are we working on before it will be released.
- Fix some of the few bugs we have seen in our test environment
- Have a way to get the configuration in a global table, so once you import an iflow on QA it will apply the configured configuration from IRT
- Investigate if we can upload the new iflow without removing the old version.
There may also be other ways we can integrate this both with our testing application part and make a flow that better fits with a DevOps focus of development.
We expect this functionality to be released within the next few weeks both in our cloud application as well as the on-prem deployment of IRT.
Want to try it on your own system
You can signup for the trial below. It is pretty simple to get started.