S/4HANA conversion projects are taking off with more and more companies moving to the latest version of the the famous SAP ERP system. On one hand this is a huge opportunity to start using the latest features but on the other hand it can be a challenge are the conversion process may require code or process changes. With S/4HANA Selective Data Transition projects companies are implementing more complex projects (new business functions, systems consolidations for merging many individual systems into a larger single instance or even doing carvouts where one system is split into a few simpler systems). The question is how can we make sure that the SAP EDI scenarios are working in the same way after the conversion as they did before the conversion?
Testing for S/4HANA projects
If we try to find out what parts of a typical S/4HANA conversion project can be automatically retested we may come into the conclusion that it can be very little as User Interface (UI) testing cannot be tested due to changes in the UI (SAPGui to Fiori/UI5). Is there anything left? What about the SAP interfaces (legacy, EDI, etc.)? Would those connections change after the conversion? Would EDI customers or vendors require a new set of messages to be exchanged after the S/4HANA conversion project? Most likely not. That’s why we have a great opportunity of retest that automatically with the use of SAP API testing tools like Int4 IFTT.
Scope of the SAP EDI test for the S/4HANA conversion project
There can be many changes to the SAP EDI interfaces during a typical S/4HANA conversion project:
a)
custom code migration - custom ABAP code may need to be enhanced to work in the same way after the S/4HANA conversion
b)
ABAP code updates - for consolidations, carvouts, code cleaning. Those changes can be very significant but still the SAP EDI interface need to work in the same way after the S/4HANA conversion project
c)
change of the middleware - at the time of the S/4HANA conversion project companies want to change the middleware (from SAP PO to SAP Cloud Platform Integration Suite for example)
d)
change of the integration technology - some companies want to replace IDOCs with other integration technologies (SOAP/APIs)
e)
change of the EDI provider - some companies can use the S/4HANA conversion project to switch the SAP EDI interfaces from it’s own middleware to an EDI provider (Seeburger, Opentext, etc.) or do the opposite move.
In all of those cases SAP EDI scenarios need to be tested from end to end (SAP S/4HANA system and the EDI endpoint) but how to achieve it?
Automated SAP EDI testing for S/4HANA with Int4 IFTT
Int4 IFTT with it’s smart repeater and full SAP API testing virtualization functions can automate SAP EDI testing for all flavors of S/4HANA conversion projects. Int4 IFTT smart repeater function allows reprocessing the existing production SAP EDI messages on the new S/4HANA landscape and automated comparing of the results with the old landscape. Int4 IFTT virtualiazation on the other hand allows doing the testing in a very isolated way without availability of EDI business partners by completely emulating them for the testing purposes.
How does it work?
Step 1
At first we can start with collecting test cases based on current/old solution and store them in Int4 IFTT. Test cases can be quickly created based on existing production SAP EDI messages which means test case creating is almost completely scriptless as we already have all available test cases and just need to select them In Int4 IFTT. This approach is shown in Figure below.
Step 2
After the S/4HANA conversion is finished we can automatically test all EDI messaged and all EDI customers in the following way:
a) for inbound - EDI to SAP ERP - messages - Int4 IFTT can rerun all (usually a few thousands) stored EDI messages for all SAP EDI B2B partners and validate the SAP business documents which got created as a result. In this scenario EDI B2B partners are completely virtualized and they don’t need to take part in the test.
b) for outbound - SAP ERP to EDI - messages - Int4 IFTT can repeat the output messages from existing SAP backend documents and compare the EDI outputs after the S/4HANA conversion with the EDI messages created from the same documents before the S/4HANA conversion took place. In this scenario EDI B2B partners are completely also virtualized and the EDI validation will be done completely by Int4 IFTT as shown in Figure below.
Result
All testing results are immediately visible after the automated test run and depending on the test direction you can validate different things:
a) for inbound - EDI to SAP ERP - messages - where Int4 IFTT sends the test messages to the middleware or SAP S/4HANA system directly can you check if the new business document is exactly the same as the one created before the S/4HANA conversion as shown in Figure below.
As we can see the same EDI message created a new sales order in the S/4HANA system but the Plant number is different. That means that the S/4HANA conversion project changed something causing a difference when reposting the same EDI message. Now it can be validated with the SAP functional expert or SAP developer and the test can be easily repeated once the issue is found.
b) for outbound - SAP ERP to EDI - messages - where Int4 IFTT would repeat the SAP EDI message output from the existing transactions on the S/4HANA backend system (so the ABAP code creating the IDOC/SOAP messages would be also tested) we only need to automatically validate the EDI messages as shown in Figure below.
Summary