Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 49 Current »

Introduction

Testing of PI processing for a scenario using SAP B2B Splitter relies on PI message references. Such scenario consists of separate ICOs used for receiving a collective message from the EDI partner and ICOs 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 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.

Inbound Processing Adapter Type: “File”

and Outbound Processing Adapter Type: “EDI Separator”

Automation Object creation.

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

IFTT Automation Object and Description can have any name, but 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. 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 Type as PI GUID E2E Inbound, Automation Object created above and choose reference message for tested interface):

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.

IFTT will save input message and all subsequent output messages.

Test case execution

  1. Select created test case and click “Execute Selected” button:

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

IFTT validates and compares all output messages and optionally business documents created in backend systems.

  • No labels