| Table of Contents |
|---|
Introduction
In order to test Testing of PI processing for a scenario using a SAP B2B Splitter we need to connect two types of IFTT test cases (of type PI GUID E2E Inbound and PI E2E Outbound). We cannot use the standard PI Unit Test type, because the relies on PI message references. Such scenario consists of two separate ICOs (described below in parts A and B). The first ICO receives used for receiving 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, but here the message is being splitted and filtered by type to single messages, e.g. EDI sales order. This message is already mapped to the final SAP form, e.g. IDOCICOs processing individual messages.
Since version 2.7.0 Int4 IFTT can be used to test these scenarios using a single test case. Instructions for configuring this scenario on older versions using combination of inbound and outbound test cases can be found here.
Example case
Example scenario in which we want to test the EDI Splitter is presented in the scheme diagram below:
...
This article describes the part of the presented above flow related to the EDI Splitter, ie. verify the operation both before the Separator (part between “EDI Customer” and “Splitter”) and after the Separator (part between “Splitter” and ECC system). Testing the rest of the flow is described in the article Outbound Flat File scenario with 'PI Outbound' interface testing.
Procedure
...
Testing the scenario described above requires virtualization of an EDI Partner and uploading a collective message to the SAP PO and 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:
...
And “EDI Separator” as Adapter Type in Outbound Processing:
...
.
Inbound Processing Adapter Type: “File”
...
and Outbound Processing Adapter Type: “EDI Separator”
...
Automation Object creation.
Go to transaction /INT4/IFTT_CONF and create new object definition, e.g. providing following data:
...
For more info on how to fill this section check Automation Object Definition.
2. Go to Variables and define Variable name and Variable description. Unlimited number of variables can be declared.
...
For more info on how to fill this section check Variables.
3. After selecting a single variable move to Variable Processing tab. Here you define actions for every variable declared in the previous step. For more specific information check Variable processing section. Be aware that for constructing XPath Expressions for flat files Expression language for flat files should be used.
...
4. Due to the fact, that the tested interface uses a flat file, in Additional Parameters tab you should set parameters for flat file interfaces and line separator as follows:
...
:
...
Two additional parameters are used to:
enable validation of output message (PIOUTPUT)
collect output messages from subsequent ICOs based on Reference ID (PISUCREFID)
For more info on how to fill this section, please check Additional Parameters.
5. Optionally create a number range that can be assigned to specific variable or multiple variables in variable processing section (in this example the name of the defined number range is $1), so that 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 final customer).
...
For more info on how to fill this section check Number ranges.
...
Test Case creation
...
After creating and defining Automation Object, create and save the IFTT test case (provide Test case description, Interface Typeas PI GUID E2E Inbound, Automation Object created above and choose reference message for tested interface):
...
...
In the second part we will create test cases of type PI E2E Outbound in connection 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 final single results. For this purpose test cases are connected to each other (using test case property “Parent ID”). Their automation objects have also defined variables that take the value from the previous case, so that they can be linked together (in this example it is 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.
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:
...
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 Payload Validation Ignore List.
B. Test Case creation.
...
There we can see the input for the test case:
...
And we can notice that for the “child” test case’s we should select using the IFTT message selector three messages containing purchase order numbers marked on the screenshot above (in this example: 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
...
IFTT will save input message and all subsequent output messages.
...
Test case execution
Select created test case and click “Execute Selected” button:
...
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 test case where the reference PO reference value is DD05847).
...
IFTT validates and compares all output messages and optionally business documents created in backend systems.