Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
MichalKrawczyk
Active Contributor
1,237
When testing SAP Interfaces (APIs) for different purposes like S/4HANA conversion projects, middleware migrations we often need to take into account that a single SAP interface as a software component is in most cases made of 2 applications (middleware and backend system) as shown in Figure below.

 


 
You can test those separately but at some point in time what you want to do is to start testing a complete software component or an SAP interface.

 

Complete testing of SAP APIs as a single software component


 
With Int4 IFTT you can always test both parts (middleware and ABAP) as this is the foundation of SAP API testing introduced in Int4 IFTT, however in the past it was only possible to test inbound interfaces in a single test case (using Inbound IDOC, PI or CPI adapters) where for doing the same for the outbound messages we needed to combine two test cases one generating or repeating a document and a second one catching the outbound message.

 
With 2.6.0 version of Int4 IFTT this has changed and for testing documents which just need to be reprocessed we can now customize testing of outbound interfaces in a single automation object.

 

How to customize Int4 IFTT to test ABAP and middleware in a single outbound automation object


 

Step 1


 
Let’s imagine we have 100-500 outgoing IDOCs for typical EDI process: order acknowledgments, outgoing shipments or outgoing invoices and we need to change some parts of those interfaces (either in the SAP backend system, middleware or in both places). Int4 IFTT gives us the possibility to regression test those documents in a matter of minutes just by repeating the existing documents from the business system.

 
At first we need to create a new Int4 IFTT automation object with variables which would allow us to repeat sending the messages using output control. Most of those we can specify as constants (KAPPL, KSCHL, PARNR, etc.)


 

Some of them however (as OBJKY) we want to make dynamic so we can use Int4 IFTT message selector to select messages on a massive scale and just repeat those.



Step 2


 
Using this configuration we can now use the Int4 IFTT message selector to select messages (IDOCs, SAP PO or SAP CPI messages) which were generated from the business document and create test cases from them.


 

Step 3


 

Once we run them from Int4 IFTT cockpit they will retrigger the original message on the SAP backend system as shown in the figure below from transaction WE02.


Int4 IFTT will catch the output message (from the middleware - SAP PO/SAP CPI or in the SAP backend system) and compare the original message with the current execution as show in the Figure below.


 

Result


 

This means that in a matter of minutes we can test the whole SAP interface (middleware and SAP backend) for any kind of migration or conversion project.

Further References:


 

Automated SAP EDI testing for S/4HANA conversion projects

SAP PRESS book: Testing SAP APIs: Strategy and Execution – where testing of SAP APIs for S/4HANA conversion use case is described in detailed

openSAP course: Virtualize and Automate Your SAP Testing Using Int4 IFTT (7200 participants and over 1.000 certified) lesson – Week 2 – Unit 4: SAP S/4HANA Conversion Testing

SAP Insider: Automated Testing and Virtualization of SAP Application Interfaces in SAP S/4HANA Conversion Project...
Labels in this area