Creating the configuration object for 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 synchronous interface (optional)

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

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

b) Option 2: By 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

Configuration object described like below will allow to create test cases based on existing messages in PI persistence. It would also allow to use 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 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 it is recommended by Int4: SAP PI/PO JAVA Stack Persistence
2. Please note that in Message Monitoring the messages are visible with 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, so actually the Interface name is a name of Receiver Interface (see above ICO screenshot).

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

but we need to let int4 IFTT know that those messages appear in SAP PO monitoring differently as on above screenshot. This is done by additional parameters:

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 BI version, that logging we activated in ICO in step 1:

This is mandatory otherwise the wrong content will be fetched 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 manually the request payloads.

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 sender. This channel will be used to trigger the real 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 wchich channel from step 3 was created
   2. PI: Synchronous: Receiver Channel Party with Party where the business component was created. Even if component was created without party the parameter is needed (with empty value)
   3. PI: Synchronous: Receiver channel name with name of created channel
      
6. In Object Variables &  Variable Processing define variables names and descriptions (optional).
7. Define Number Ranges that can be used i.e. 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 direct call of HTTP endpoint (used for REST adapter testing)

please follow Creating the configuration object for REST/JSON interface