USE
Testing of synchronous interfaces is based on validation of
...
- 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: (3.10) SAP PI/PO JAVA Stack Persistence - 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.
...
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:
...
- Identify sample payload of request message of the tested interface.
- Identify an ICO and collect:
- sender
- sender interface & namespace
- 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.
Create a new object definition with description, name, and the namespace of the tested interface
- set Additional Parameters:
- PI: Synchronous: Receiver Channel BC with Business Component in which channel from step 3 was created
- 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)
- PI: Synchronous: Receiver channel name with the name of created channel
- In Object Variables & Variable Processing, define variables names and descriptions (optional).
- Define Number Ranges that can be used, e.g., to generate values for messages created after the test case execution (optional).
- Define Database Comparison Rules define Table Names of those tables that should be compared (optional)
- Define Payload Validation Ignore List for expected differences in responses.
- Create a first test case and test your object definition.
...