Testing Async/Sync Bridge Scenario

Introduction

This article describes how to test an integration scenario where an asynchronous system is connected to a synchronous system utilizing an Async/Sync Bridge. To test PI processing for such scenarios, we need to combine two 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 Integrated Configurations.

Example case

An example in which we want to test the Asynchronous to Synchronous Bridge scenario is presented in the scheme below:

Open

In this example, we have a scenario where the sender system that only supports asynchronous message processing communicates with the asynchronous receiver system. The Async/Sync Bridge handles the conversion from an asynchronous message sent from the sender into an asynchronous message for the receiver and the other way round also for the synchronous reply.

The example scenario consists of four service interfaces (SI) (marked with blue letters in the graphic above):

1. Asynchronous outbound request interface from the Sender system

2. Synchronous inbound interface to the Receiver system

3. Asynchronous outbound response interface from the Receiver (this interface is based on the response message of the synchronous interface 2)

4. Asynchronous inbound response interface from the Receiver system

And based on listed interfaces, two Integration Configurations (ICOs) are created:

ICO 1: Asynchronous outbound request interface [SI 1] → Synchronous inbound interface [SI 2] (testing of this part is described in Part A. PI Inbound Testing below),

ICO 2: Asynchronous outbound response interface of the receiver [SI 3] → Asynchronous inbound response interface [SI 4] (testing of this part is described in Part B. PI Outbound Testing below).

Procedure

Part A. PI Inbound Testing

A. SAP PO/PI configuration

The first ICO sends SOAP asynchronous requests from the sender system (Inbound Processing tab shown below) to the synchronous receiver system. On this system, an RFC function module is called (Outbound Processing tab shown below):

Open

Most of the configuration is standard; the exception is the Receiver Communication Channel that has the following module configurations added:

The RFC function module on the SAP system that this ICO is calling has only one import parameter:

A. IFTT 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 our ICO. For more info on how to fill this section, check Automation Object Definition.

2. Go to the Variables tab and define Variable name and Variable description. You can declare an unlimited number of variables here. However, in this example, we will explain only one variable for the import parameter of the RFC FM ZFM_RFC_MATGETDESC:

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

3. After selecting the created variable, move to the Variable Processing tab. Here you define actions for every variable declared in the previous step.

The path (Processing Parameter column on the screenshot above) through which you can get the variable value should be defined based on the soap request. In our example, the request message looks like below:

For more information regarding this section, please check the Variable processing.

A. IFTT Test Case creation

After creating the automation object for the first ICO, go to IFTT Cockpit (transaction /INT4/IFTT_COCKPIT) and provide test case description, select interface type as PI GUID E2E Inbound, select the created automation object, and choose reference message for tested interface):

Then save the test case.

Part B. PI Outbound Testing

In the second part, we will create a test case of type PI E2E Outbound connected with the test case from part A. For this purpose, test cases will be connected using the test case property: “Parent ID.” The automation object for the second ICO will also have defined a variable that will take the value from the previous case. Thanks to that, they can be linked together (in this example, it is variable “MATNR” corresponding to the material number included in the request SOAP message).

The second ICO sends the output response interface of the receiver (synchronous) system (where the RFC FM was executed) to the source (asynchronous) system in File format. Inbound and outbound processing configuration of this ICO are as follows:

And the export parameters of the RFC FM that are the response of the whole tested scenario are as follows:

B. IFTT Automation Object creation

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

2. Define Variables.

In this example, there will be only two variables in the output message. RFC FM export parameters: EP_MATNR for material number and EP_MATDESC for material description. They both should be defined in the automation object for the second ICO:

3. Define Variable processing.

The procedure is the same for the variable MATDESC, as shown in Part A (for variable MATNR). That means we need to define a path in the response message based on which we will take the value for the MATDESC variable:variable:

While the variable MATNR will connect both test cases (“parent” from Part A and “child” from Part B) and therefore two actions should be defined for it:

• the first one is responsible for directly reading the value from the parent test case (from the variable MATNR in that automation object),

• the second is responsible for reading the same value in the response message for the second ICO attached below:

B. IFTT Test Case creation

Once the automation object is created, create a test case in the same way as before. Provide test case description, Interface Type as PI E2E Outbound, newly created automation object, and select reference message for this interface):

Please remember to select Parent ID (marked in the screenshot above) referring to the previously created test case of Interface Type “PI GUID E2E Inbound”.

Part C. Execution of Test Case

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

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

2.1. After clicking on the details of the first TC, we can see that the asynchronous request message (with a material number) has been processed correctly:

2.2. The asynchronous response message has been processed correctly as well (with the same material number and the corresponding material description):

And the payloads comparison (from the reference and current massage) is also correct: