...
This article describes how to test an integration scenario , where an asynchronous system is connected to a synchronous system by means of utilizing an Async/Sync Bridge. In order to To test PI processing for such scenarios, we need to connect combine two types of IFTT test cases (of type type PI GUID E2E Inbound and and PI E2E Outbound). We cannot use the standard standard PI Unit Test type, type because the scenario consists of two separate Integrated Configurations.
Example case
Example 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 a synchronous the asynchronous receiver system. The Async/Sync Bridge handles the conversion from an asynchronous message sent from the sender into a synchronous an asynchronous message for the receiver and the other way round also for the synchronous reply.
...
The first ICO sends SOAP asynchronous request requests from the sender system (Inbound Processing Processing tab shown below) to the synchronous receiver system. On this system, where a an RFC function module is being called (Outbound Processing 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 is being called by this ICO is calling has only one import parameter:
...
A. IFTT Automation Object creation
Go to transaction transaction /INT4/IFTT_CONF and create a new object definition, e.g., providing the following data:
...
IFTT Automation Object and Description can Object and Description can have any name. However, but in the Name and Namespace fields in the Name and Namespace fields, we should provide the interface name and namespace used interface name and namespace used in our ICO. For more info on how to fill this section check , check Automation Object Definition.
| Info |
|---|
Please note that instead of creating automation object manually you can also use the the SAP PI/PO Wizard instead of creating an automation object manually. |
2. Go to Variables the Variables tab and define Variable name and Variable description. Unlimited You can declare an unlimited number of variables can be declared here. However, but in this example, we will define explain only one variable for the import parameter of the RFC FM FM ZFM_RFC_MATGETDESC:
...
For more info on how to fill this section, check Variables.
3. After selecting the created variable, move to to the Variable Processing Processing tab. Here you define actions for every variable declared in the previous step.
...
The path (Processing Parameter column column on the screenshot above) through which you can get the variable value should be defined based on the basis of the soap request. In our example, the request message looks like below:
...
For more information regarding this section, please check 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 typeas PI GUID E2E Inbound, select the created automation object, and choose reference message for tested interface):
...
Part B. PI Outbound Testing
In the second part, we will create a test case of type type PI E2E Outbound in connection connected with the test case from from part A. For this purpose, test cases will be connected to each other ( using the test case property: “Parent ID”). In addition, 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, so that they can be linked together (in this example, it is variable “MATNR” corresponding to the material number that was included in the request SOAP message).
...
| Info |
|---|
Please note that similar to Part part A above, instead of creating automation object manually you can also use the the SAP PI/PO Wizard instead of creating automation objects manually. |
2. Define Variables.
In this example, there will be only two variables in the output message (. RFC FM export parameters: EP_MATNR MATNR for material number and and EP_MATDESC MATDESC for material description), which . They both should be defined in the automation object for the second ICO:
...
3. Define Variable processing.
For the variable MATDESC the The procedure is the same for the variable MATDESC, as shown in in Part A (for variable variable MATNR), i. e. That means we need to define a path in the response message based on the basis of which we will take the value for the MATDESC 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:
...
Once the automation object is created, create a test case in the same way as before (provide . Provide test case description, Interface Typeas as PI E2E Outbound, newly created automation object, and select reference message for this interface):
...
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:
...