Blog > Testing SAP PI/PO Splitter with Int4 IFTT

Testing SAP PI/PO Splitter with Int4 IFTT

Michał Ibrom profile image
Michał Ibrom SAP Integration Consultant | ABAP Developer
icon__calendar 2020-11-04

In this article you will learn:

  • The concept of EDI message splitting using SAP PI B2B EDISeparator,
  • How to test such cases using the Int4 IFTT.

Reading time: 6 minutes


Int4 IFTT is a tool that allows testing of different types of SAP interfaces and business scenarios. Many of them use the EDI (Electronic Data Interchange) standard to communicate business objects like sales orders, invoices, etc. between business partners. EDI allows the interchange of data between many partners without modifications or developments of new interfaces for every partner because it provides a generic and standardized definition of business documents. And therefore this type of communication is often used in B2B (Business-to-Business) scenarios, where there is a need to exchange large amounts of data between trading companies. In order to optimize such processes, instead of sending multiple messages separately a more efficient solution may be to transfer one EDI file containing many transaction data which can be divided into individual messages. On the one hand, such a solution may provide benefits through the reduction of transmission costs (because of sending single instead of multiple files), but on the other hand, it may complicate the interface logic. But for this purpose, you can use the Int4 IFTT tool, thanks to which you will be able to test such scenarios. And in case of changes or developments in the interface logic, apply automatic regression testing as well.


EDI Splitter test scenario

This article covers testing of a scenario where several purchase orders are created from one input EDI message after processing in SAP PI/PO (thus a process in relation: single input to multiple outputs). An example of such a B2B integration scenario in which the Splitter adapter is used is presented in Figure 1.

EDI Splitter test scenario diagram

Figure 1. EDI Splitter test scenario diagram.

The presented case consists of two ICOs (Integrated Configurations) in SAP PI, whose basic technical information are as follows:

1. The first ICO receives a collective EDI message from the EDI partner and sends it to the EDISeparator adapter (Outbound Processing tab in Figure 2):
Input ICO?s Outbound Processing configuration

Figure 2. Input ICO’s Outbound Processing configuration.

2. The second ICO receives the collective message via the EDISeparator channel (Inbound Processing tab in Figure 3) and then the message is being separated and filtered by type to single IDOCs:

OutputI CO?s Inbound Processing configuration

Figure 3. Output ICO’s Inbound Processing configuration.

Configuration in Int4 IFTT

In order to test SAP PI/PO processing for a scenario using a B2B EDI Splitter we need to connect two types of the Int4 IFTT test cases (of type PI GUID E2E Inbound and PI E2E Outbound). We cannot use the standard PI Unit Test type, because the scenario consists of two separate ICOs.

  • The “parent” test case is used to virtualize the EDI Partner and validate the first part of the process, i.e. uploading a collective EDI message (example in the Listing 1) to the Middleware Platform.

Listing 1. Example input EDI message.

As you can see, the incoming EDI message consists of three same messages which in the next step will be divided into single messages. In order to identify each of these messages in the Int4 IFTT automation object you should define a unique variable (in this case purchase order number) which will allow to connect the input and output the Int4 IFTT test cases:

Configuration of the IFTT automation object for input test case

Figure 4. Configuration of the Int4 IFTT automation object for input test case.

  • The role of subsequent “child” test case(s) is to find the relevant single messages from collective messages processed in the first test case and then compare their values after mapping with a prepared pattern. For this purpose test cases are connected to each other. As already mentioned, automation object for “child” test case have defined variables that take the value from the previous test case, so that they can be linked together:

Configuration of the IFTT automation object for output test case

Figure 5. Configuration of the Int4 IFTT automation object for output test case.

Testing in Int4 IFTT

After creating the appropriate automation objects configuration, you can go to the Int4 IFTT Cockpit and create test cases for interfaces. In tested scenario there is one input EDI message and three IDOC output messages, therefore you should create one test case of type PI GUID E2E Inbound and three test cases of type PI E2E Outbound:

Created Int4 IFTT test cases

Figure 6. Created Int4 IFTT test cases.

However, attention should be paid to defining the Parent ID for “child” test cases (marked with a yellow frame in the Figure 6) to correctly link them together.

Finally, select all created Int4 IFTT test cases and execute them. As a result you will receive the Test Execution Report visible in Figure 7.

Int4 IFTT Test Execution Report

Figure 7. Int4 IFTT Test Execution Report.


The EDI splitting is a common approach in B2B integration and it is important to correctly test and prevent errors in such scenarios. Therefore, bear in mind that testing even complex SAP interfaces can be facilitated and automated with the use of Int4 IFTT tool. If you would like to learn more about the testing approach presented in this article, I encourage you to read the detailed documentation available on Int4 IFTT Wiki Page.

And if you want to find out more about this (or other) Int4 IFTT features, just book a consultation with the product demo or contact us.


Read also:

1. Get advantage of the Int4 IFTT IDoc Message Selector during Test Case creation

2. Int4 IFTT and SAP Test Suite integration – Business Scenarios

Michał Ibrom profile image
Michał Ibrom SAP Integration Consultant | ABAP Developer
SAP Developer and Integration Consultant since 2017. Involved in several international SAP projects. Certified in ABAP and experienced in developing various solutions based on SAP technology stack. Team player focused on continuous development and achieving goals not only at work.