Testing SAP B2B Addon Splitter Scenario (IFTT < 2.7.0)

Introduction

To test PI processing for a scenario using an SAP B2B Splitter, we need to connect two types of IFTT test cases (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 (described below in parts A and B).

The first ICO receives a collective message from the EDI partner and sends it to the EDISeparator adapter. In this case, the validation in Int4 IFTT would only show the incoming message being forwarded. The second ICO, on the other hand, receives the collective message also via the EDISeparator channel. However, the message is split and filtered by type to single messages, e.g., EDI sales order. This message is already mapped to the final SAP form, e.g., IDOC.

Example case

An example scenario in which we want to test the EDI Splitter is presented in the scheme below:

Open

This article describes the part of the flow presented above related to the EDI Splitter. As an example, how to verify the operations

• before the Separator (the part between "EDI Customer" and "Splitter")

• after the Separator (the part between "Splitter" and ECC system).

Testing the rest of the flow is described in the Outbound Flat File scenario with 'PI Outbound' interface testing.

Procedure

Part A. PI Inbound Testing

Testing the scenario described above requires virtualizing an EDI Partner and uploading a collective message to the SAP PO. The first test case (of type PI GUID E2E Inbound) is used for this purpose. In this step, we will test ICO with "File" as Adapter Type in Inbound Processing:

Open

And “EDI Separator” as Adapter Type in Outbound Processing:

A. Automation Object creation.

1. Go to transaction /INT4/IFTT_CONF and create a new object definition, e.g., providing the following data:

IFTT Automation Object and Description can have any name. However, in the Name and Namespace fields, we should provide the interface name and namespace used in the ICO of the tested interface. 

For more info on how to fill this section, check Automation Object Definition.

2. Go to Variables and define Variable name and Variable description. You can declare an unlimited number of variables.

For more info on how to fill this section, check Variables.

3. After selecting a single variable, move to the Variable Processing tab. Here you define actions for every variable declared in the previous step. For more specific information, check the Variable processing section. Be aware that for constructing XPath Expressions for flat files, Expression language for flat files should be used.

4.  Since the tested interface uses a flat-file, in the Additional Parameters tab, you should set parameters for flat-file interfaces and line separator as follows:

For more info on how to fill this section, please check Additional Parameters.

5. [Optionally] Create a number range that can be assigned to a specific variable or multiple variables in the variable processing section (in this example, the name of the defined number range is $1). We can overwrite the original numbers with the new test values. Please note that this is only needed if we do not want to send duplicates from original documents (e.g., sales orders to the final customer).

For more info on how to fill this section, check Number ranges.

A. Test Case creation.

After creating and defining Automation Object, create and save the IFTT test case. Provide Test case description, Interface Type as PI GUID E2E Inbound, Automation Object created above and choose reference message for tested interface):

Part B. PI Outbound Testing

In the second part, we will create test cases of type PI E2E Outbound connected with the test case from part A. Their role is to find the appropriate single messages created from collective messages and then compare their values after mapping with a previously prepared pattern. This search is done by analyzing the content and matching, for example, order numbers from a collective message with single final results. For this purpose, test cases are connected (using test case property "Parent ID"). Their automation objects have also defined variables that take the value from the previous case to be linked together. In this example, it is a variable named "PO". Details on how to make this connection are described in point 2 below (Variables subsection)).

In this step we will test ICO with “EDISeparator” as Adapter Type in Inbound Processing:

And “Idoc_AAE” as Adapter Type in Outbound Processing:

B. Automation Object creation.

1. Create an Automation Object in the same way as before, but remember to choose proper Service Interface Name and Service Interface Namespace from tested ICO.

2. Define Variables:

Define also Variable processing. Please note that the PO number is being read from the parent test case. In the case of a one-to-many relationship between "parent" and "child" test cases (as it is in this example), we should use a variable processor named "READ_PREVX" together with the Action "Populate variable before execution" and proper Processing Parameter value. Combining these parameters (first record on the screenshot below) is used to filter the comparison between the new messages with their respective reference messages. Filtering is done using values taken from the message based on the path entered in the field Processing Parameter). In this example, we compare IDOCs, defining XPath to the segment that contains the purchase order number: //E1EDK01/BELNR/text().

3. Optionally, we can define Payload Validation Ignore List, i.e., fields that should not be compared during verification between reference and current message. As an example, a difference in the generated document number or the date can be used here. For more info on how to use this section, check the Payload Validation Ignore List.

B. Test Case creation.

After creating and defining Automation Object, create and save the IFTT test case. Provide Test case description, Interface Type as PI E2E Outbound, Automation Object created above and select reference messages for mentioned interface). To make sure that we get the right messages while crating "child" test cases, we can select the parent test case and click the "Content" button to see the input message as shown below:

There we can see the input for the test case:

For the "child" test cases, we should select (using the IFTT message selector) three messages containing purchase order numbers marked on the screenshot above. In this example, the values are DD05847, DD05848, and DD05849.

Please remember to choose the number of the previous test case as Parent ID before saving “child” test cases:

Part C. Execution of Test Cases

1. Select all created test cases (from Part A and B) and click the “Execute Selected” button:

2. After processing the test cases, you will receive a Test Case Execution Result Report:

For details of each test case, click on the given test case (below is a report for a test case where the reference PO reference value is DD05847).