Testing Async/Sync Bridge Scenario - Int4 Suite

Owned by Mateusz Nowak
Last updated: Dec 07, 2023

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 Int4 Suite 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:

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. Request Message Testing Configuration

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):

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. Int4 Suite Automation Object creation

  1. Go to tile Automation Objects and create new automation object definition e.g., providing the following data:

 

Int4 Suite 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.

Please note that you can use the SAP PI/PO Wizard instead of creating an automation object manually.

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 and Variables Processing.

3. After selecting the created variable, go to the details to read the content of the variable:

 

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.

Then in the next step provide in the Output Automation Object a name of the automation object that will be used for fetching the response sent to the external system. You will create this automation object name in the next step.

 

 

 

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. 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. Int4 Suite 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:

 

 

Part C. Test Cases Creation

After creating the automation object for the first ICO and second ICO, go to Int4 APITester 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.

You should see that the input from the first ICO and Output from the second ICO have been saved.

 

Part D. Execution of Test Case

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

2. After processing the test cases, you will receive a Test Case Execution Result Report with the details of the response message comparison:

 

 

© 2017 - 2022 Int4 AG All rights reserved