Creating the configuration object for the PI synchronous interface

USE

Testing of synchronous interfaces is based on validation of

1. Response message

2. Validation of the document posted in SAP Backend by the synchronous interface (optional)

There are three ways to create a configuration for testing the synchronous interface:

a) Option 1: Regular way like any other asynchronous interfaces (without connectivity testing)

b) Option 2: By the creation of Receiver Channel that will call tested interface Sender channel  (within connectivity testing) 

c)  Option 3: Direct call of HTTP endpoint (used for REST adapter testing) in SAP PO system

OPTION 1 - Recommended option for testing synchronous scenarios

The configuration object described below will allow creating test cases based on existing messages in PI persistence. It would also allow using PI Message Selector.

PROCEDURE

1. Make sure the PI interface staging & logging is set as below:
   
   The BI Logging (not staging) must be activated to fetch the original input message with the correct sender interface in XI 3.0 Header. This stores the request source and response target messages
   There is no staging for synchronous messages. Whatever you configure will be ignored anyway.
   Or, this might be already settings of global persistence settings, as Int4 recommends it: SAP PI/PO JAVA Stack Persistence
2. Please note that in Message Monitoring, the messages are visible with the Inbound (Receiver) Interface name.
   This is opposite to all asynchronous scenarios that staging MS leaves them with Outbound (Sender) Interface name.

Exemplary ICO of synchronous interface:

And the sample message in PI/PO monitoring:

The request message is presented with the "SI_I_CR_SALESORDER_SYNC" interface. The Interface name is the name of Receiver Interface (see above ICO screenshot).

In the object definition, we will add the proper sender interface (as per ICO):

We need to let Int4 IFTT know that those messages appear in SAP PO monitoring differently, as in the above screenshot. This setting is done by additional parameters:

You will find more details on the parameters in the additional parameter section

3. Additionally, we must indicate that as a request message, we would like to fetch the BI version that logging we activated in ICO in step 1:

This setting is mandatory; otherwise, IFTT will fetch the incorrect content from PI.

4.  Create a first test case and test your object definition. The test case is created based on GUID of existing message

More details about SAP PO behavior: https://launchpad.support.sap.com/#/notes/2515359

OPTION 2 - Testing via dedicated Receiver Channel (obsolete)

This approach will also fully validate the communication channel processing. 

Please note that currently, Int4 IFTT handles only UFT-8 encoding the synchronous calls using dedicated receiving channels.

The Proxy Sender channel testing is unsupported via option 2 (Option 1 must be used instead).

In opposite to Option 1, the test cases are created based on uploading the request payloads manually.

PROCEDURE

1. Identify sample payload of request message of the tested interface.
2. Identify an ICO and collect:
   1. sender
   2. sender interface & namespace
3. Create a receiver communication channel for the sender. This channel will be used to trigger the actual PI interface and is going to be tested.

4. Create a new object definition with description, name, and the namespace of the tested interface

5. set Additional Parameters: 
   
   
   1. PI: Synchronous: Receiver Channel BC  with Business Component in which channel from step 3 was created
   2. PI: Synchronous: Receiver Channel Party with Party where the business component was made. Even if the component was created without a party, the parameter is needed (with an empty value)
   3. PI: Synchronous: Receiver channel name with the name of created channel
6. In Object Variables &  Variable Processing, define variables names and descriptions (optional).
7. Define Number Ranges that can be used, e.g., to generate values for messages created after the test case execution (optional).
8. Define Database Comparison Rules define Table Names of those tables that should be compared (optional)
9. Define Payload Validation Ignore List  for expected differences in responses.
10. Create a first test case and test your object definition.

Option 3: Only for pure HTTP interfaces, by the direct call of HTTP endpoint (used for REST adapter testing)

please follow Creating the configuration object for REST/JSON interface