SAP Process Integration (PI) or Process Orchestration (PO) still has a huge impact on a lot of customers. This importance ensures that SAP PI/PO processes will continue going into 2022 and beyond. See how you can better handle your SAP Process Integrations in 2022.
You will still use SAP Process Integration
SAP Integration Suite is the new platform and has a lot of good advantages when it comes to integration with cloud applications.
However, even with those advantages, there are a few limitations. You will encounter limitations if you have:
- B2B setup
- On premise communication
- Operation and monitoring
- Exactly one communication.
SAP Cloud Integration is improving in the above areas.
However, maybe it will be best suited to use the SAP Integration Suite in 2-3 years if you have 500+ integrations to migrate. Moreover, depending on your timeline then maybe it will be longer. In the meantime, you can utilize the Figaf DevOps Suite to simplify operations and governance.
Figaf DevOps Suite
We started work on the Figaf Tool 6 years ago to simplify the testing process of SAP Process Integrations.
In the process, we discovered that we needed to know, for understanding, what is happening with the integration platform. This feature we improved to simplify the deployment process.
The Figaf DevOps Suite connects to the different SAP PI systems and download all the objects both in the Repository and the Directory. Therefore, because of that capability, it’s possible to compare different object versions.
Recently, a large SAP Customer asked us to improve the process so they could simplify operations of the SAP PI system while handling their S/4 HANA project.
Standard processes
The normal way you can handle a transport would be the following:
- The business user create a ticket in the service request system
- Then the developer completes the development
- Once complete, the developer creates the transports needed
- The developer then creates documentation of the change
- Next, the developer creates the documentation on how the integration should be configured in test and production environments
- The developer sends a request of approval of change to Architect
- Then the architect reviews documentation and transport
- If all is well, the architect approves the change
- Next, the basis team can import the change to test
- After that, the basis team configure the integration
- Then the business user test the change in the test system
- Hopefully everything is clear and the business user approves the change
- Following all of that, the basis team imports the change to production
- Finally, the basis team configures the integration
During the whole process there are a lot of handoffs between different teams and the documentation created has a higher probability for errors. Someone inserts the wrong value at some location and create a difference between the system and the documentation. There are way too many opportunities for discrepancies and errors to occur.
A lot of the work consists of Copy-Paste data between documents and the SAP PI/PO system. There is a risk that even with the clear errors, everything works.
Audibility and supportability
One important aspect of governance is the ability to audit the change. To show which changes occurred on a system and be able to find the real reason why those changes happened.
Also, It is also interesting to be able to look at any object in the system and find the changes that have happened and know the reasons for those changes. For a large system, with a lot of changes, it is difficult to find what has changed.
What your processes would look like?
There is a lot of room for improvement in the process. It is what we have helped one of our clients with. They have a huge SAP PI landscape with 1000+ ICOs they needed to manage.
We have removed the need to have any Excel files to document your changes. Everything will happen in the system and with all the approvals and documentation needed.
Moreover, to illustrate the process, lets say a developer wants to transport a new integration into the landscape. The developer attested that everything is working in development and is now ready to start the transport process in the Figaf Tool.
The developer adds all the objects needed to be changed and creates a ticket in the Figaf Tool . It is easy to add all the objects he have worked on. This way it is possible to monitor all the objects needed for the change. The Ticket is linked to a Jira or Service Now ticket for finding the change request for it.
The developer selects the test cases for the current objects and run the tests to ensure all the changes does not affect any unexpected things. After running the test and validating everything, it is possible to update the test case to match the current run.
After running the test it is easy to see if everything is as expected. And if any problems arise, it’s easy find the problem or the difference. The test cases will be updated after the problems are resolved.
What happens in between the Systems?
Between the systems the transport starts. Now the developer have the option to specify which objects to change in the configuration in the landscape. It is easy to compare changes on objects in the landscape for all objects including Message Mappings or Channels.
Here is an example of how the channel configuration looks. It is possible to see all the details about the configuration. You will be able to have different filters to show non-transportable items or see where any changes have been made. It is also possible to setup a global search to replace the hostnames so they match the landscape you are working with.
Once the developer is done with the setup, it is possible to send the change for approval. Then an architect has the same options to validate the transport. If everything is correct it is possible to submit the change. Lastly, the system logs all approvals.
The transport is imported via the import button or via API once the transport is approved. Moreover, all the links to the target objects will be visible and you can find changes on your systems.
To transport to the next system in the landscape the developer, you can just create a new ticket and transport with the required objects. The objects will all be linked so you can view which ticket and service request was made earlier.
ICO filtering
In some scenarios, you want to limit the configurations that you want to handle as a part of your transports. It could be if you just want to transport one condition you have developed and not all the other conditions. It will allow you to transport ICOs and select the receivers or reviver interfaces you want to transport. This is the way of delivering specific changes on a granular level.
S/4 HANA Migrations required easy renaming of systems
If you are implementing S/4 HANA you are going to setup a new landscape with the S/4 system. This will impact your current integration setup where you will need to configure your systems to support integration both with S/4 and the old systems during the migration process.
We have added an option so you can easily copy your integration to connect with different systems. It will simplify the process.
You get transparency since all the changes made are documented.
Just as in the transport above just transport the IFlow on a landscape pointing to the same system.
This is better than standard transports
The flow is much better than the standard transport process. It skips the need to for having Excel documents and manual process for handling transports.
It also allows you to test your integration much easier, so it becomes a part of your standard delivery process.
Are you ready to have better SAP Process Integrations/Process Orchestrations? Then you should take a look at the Figaf DevOps Suite which includes our SAP PI/PO Management feature. The Figaf DevOps Suite is easy to start. If you are ready discuss this further, then book a session with us to understand how it can help your processes. Or, if you are ready to give our product a test run, then you can just signup for the free trial here.