SAP Process Integration is the most common SAP middleware platform so far. Its widely used to connect various SAP and non-SAP systems, providing a single point of integration. According to SAP PI dual stack installations (ABAP and JAVA) will be supported by SAP only until the end of 2020. Very likely in the next couple of years there will be an increase in the number of SAP PI migration projects as SAP XI/PI dual stack installations will need to be migrated to a single stack JAVA only SAP PO architecture.
When we speak of SAP PI migration, we need to keep in mind it’s not only about moving objects from one system to another. I.e. due to significant differences in architecture between different SAP PI/PO versions, new configuration objects must be created re-using existing communication channels and ESR objects such as service interfaces or operation mappings. In some interfaces there might be need to convert ABAP mapping into Java-based message mapping, as ABAP mappings are no longer supported in single-stack. Also all of the ccBPM scenarios need to be rebuilt as NW BPM as there is no simple way to perform this transformation. When migrating 10 interfaces, validating if the interfaces work doesn’t seem to be a great challenge. But let’s face it – on a regular migration project the number is more likely to hit 50 and beyond, and if we multiply this by the number of recipients in each of the scenarios, it calls for some proper testing.
There are plenty of pros for the SAP PI/PO migration, but that kind of upgrade is always a risk. Errors in integration may lead to posting of incorrect documents in the production system. They may also cause legal or reporting issues such as incorrect taxes or other faulty information that can be reported to the shareholder. In the worst scenario integration errors can also lead to production or distribution stoppage, what generates high costs and affects reputation of IT. All of this can be avoided by applying appropriate testing process.
In Int4 we look at projects in a way a climber looks at mountains. Each is different, and requires a specific equipment and technique to get to the top. When it comes to SAP PI migration projects we always make sure that in our backpacks we have our automated testing tool Int4 IFTT.
While working on various SAP PI/PO migration projects we have gone through many different issues and in most cases we were able to track and resolve them quickly, long before the UAT phase with the help of Int4 IFTT software. Not only it saved us precious time, that we could later use for completing the most complex scenarios, but it also gave us significant edge during UATs when i.e. we could mass create documents on ERP at times when 3rd party resources were unavailable due to month end activities.
Int4 IFTT Support during SAP PI/PO Migration
Int4 IFTT installation and initial configuration is very quick and simple. Together with a Quick Guide, containing step-by-step ready to use testing scenarios, it allows consultants an test team members to commence testing of the migrated interfaces almost instantly, within just a few hours from deployment and since it’s installed on Solution Manager in most cases the connectivity options are also available within minutes.
On every SAP PI/PO migration project, Int4 IFTT was the tool we used to confirm that all the interface components have been configured properly, and that after the SAP PI/PO migration the system behaves in exactly the same way as before. The creation of a test case in Int4 IFTT is very simple to the main function of Int4 IFTT “the Repeater” function. All that you need is an existing message which came from the dual stack SAP PO through the migrated interface. On our latest migration project we used successfully processed messages found on the old production SAP PI. Thanks to the Message Selector functionality Int4 IFTT allows to retrieve messages from the selected SAP PI’s persistence directly, without the need for logging manually to a particular SAP PI instance.
After the original message payload is saved as a new test case, Int4 IFTT will allow you to send the original message to ERP through new SAP PO single stack installation. It will automatically compare the final document created with the original message that came through the old dual stack SAP PI, against the newly created one from the new single stack SAP PO system. Int4 IFTT will also generate reports which can be later used as official test confirmations.
Testing SAP PI/PO Migration Examples
Int4 IFTT supports wide range of scenarios on both dual stack, and single stack SAP PI installations, covering inbound, outbound and synchronous interfaces testing. Here is a brief overview of the ones in which Int4 IFTT helped us during the SAP PI/PO migration.
The first on the list, and probably the most common validations to be conducted when migrating to the new SAP PO single stack installation, are the ones of the message mappings. As mentioned before there might be customers out there that maintain large numbers of ABAP mapping. Those need to be transformed into Java mappings, and usually testing them would take time. But thanks to Int4 IFTT it can be done in a blink of an eye, by reusing existing messages i.e. from old production interface that had ABAP mappings implemented, to create test cases. Running them through single stack SAP PO will allow to validate the new mapping logic, and confirm if it works exactly the same as the old ABAP one.
Connectivity and configuration
During the first test runs we didn’t know if all the connections “to” and “from” the new single stack SAP PO system are configured properly. One of the pros of testing the SAP PI/PO migration with Int4 IFTT is the ability to send test messages and trigger any selected interface (inbound, outbound or synchronous) in order to test each channel’s connectivity.
For example we had a SOAP to IDOC interface, and while pinging the channels in the channel monitoring there were no errors to be seen. Only by running test cases we were able to learn that there was initial configuration missing on the ECC system side.
Furthermore there was a need to begin testing the outbound interfaces with external system receivers which by that time were not yet configured. Int4 IFTT allowed us to test such scenarios by preventing the message to be sent to the receiver side. In this scenario we were able to test selected interface on the SAP PO side. This functionality also proved beneficial at times when we didn’t want to make a mess on our client data base or ECC systems during intensive testing period.
We have successfully used Int4 IFTT for testing synchronous interfaces on the new single stack SAP PO installation. For synchronous interfaces the test case consists of an inbound and outbound message. During tests we were looking both for the final response but also at what happened in the backend. For example while testing synchronous sales order interface, for the test to be marked as passed we would need to receive sales order number in the response. We were able to test a number of synchronous interfaces in a glimpse of an eye without the need of manually checking any data on the target system or accessing SAP PI monitoring as Int4 IFTT gathered all the required data and presented it in the ultimate test case results.
Another challenge on the project that we had to deal with occurred during UAT phase. By accident, someone from the customer side has switched back online part of the communication channels in the old testing environment. This resulted in messages being processed through the old dual stack SAP PI instead of the new one. Due to the business specific of these particular interfaces it was said earlier that most likely we will have only one go to test them. As soon as we have realised what happened we have switched the channels off, but the milk has been spilled. There were plenty of messages in the old SAP PI monitoring, and normally this would compromise any chances to test the interfaces with the UAT test cases. Fortunately, having Int4 IFTT on board we have managed to quickly find out messages that have reached the test environment, and use them to create test cases. Now, that the messages were safely stored in our test case repository we could rest assured that we can replicate the UAT tests any time we need.
To sum it up Int4 IFTT gives us the ability to continuously regression test selected interfaces helping to prevent any errors and inconsistencies in the configuration. It reduces the time required to test even the most complex scenarios such as:
- Rapid changes in the interface logic
- Deployment of new sites in rollout projects
- Merging project & maintenance landscape
- Patches & upgrades (SAP PI/PO, ECC)
- PI dual stack (ABAP & JAVA architecture) to SAP PO single stack migration
- Continuous testing/deployment for SAP PO landscapes
Int4 IFTT – https://int4.com/iftt