Page Comparison

...

...

USE

Testing of synchronous interfaces is based on validation of

...

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

Configuration The configuration object described like below will allow to create creating test cases based on existing messages in PI persistence. It would also allow to use 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 Or, this might be already settings of global persistence settingspersistence settings, as Int4 recommends it is recommended by Int4: 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:

...

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

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

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

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

3. Additionally  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 wrong incorrect 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 , Int4 IFTT handles only UFT-8 encoding the synchronous calls using dedicated receiving channels.

...

In opposite to Option 1, the test cases are created based on uploading manually 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 real actual PI interface and is going to be tested.

4. Create a new object definition with:  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 which channel from step 3 was created
   2. PI: Synchronous: Receiver Channel Party with Party where the business component was createdmade. 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 i, e.eg., 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

...