Page Comparison

SAP CPI provides the header SAP_ApplicationID that can be populated when a message is triggered into CPI , or from within an IFlow using a Script or Content Modifier step. The value populated in this header in is searchable from Web UI monitoring.

When testing CPI IFlows with Int4 IFTT, it is important essential to take into consideration consider if this the header is modified in the IFlow being tested, as . Int4 IFTT populates the header SAP_ApplicationID with a correlation GUID to track the messages.

Int4 IFTT supports various adapters used as sender channels of an IFlow. For sender channels that behave synchronously (as listed below), if the header SAP_ApplicationID is modified in the IFlow, this will interfere with the correlation and may cause incorrect matching, and therefore incorrect false test results.

• ProcessDirect

• HTTPS

• IDoc

• SOAP (with Message Exchange Pattern = Request-Reply)

If Suppose the population of SAP_ApplicationID in the IFlow being tested is still required. In that case, the following are some alternatives for design changes in the IFlow in order for it to be compatible for testing with Int4 IFTT.

IFlow with sender ProcessDirect channel

• Do not modify the header within this IFlow. Instead, the header should be populated (with appropriate logic/value) in the matching IFlow that sends the message to this ProcessDirect endpoint.

• Add SAP_ApplicationID as an allowed header in this IFlow.

IFlow with sender ProcessDirect channel

• Do not modify the header within this IFlow. Instead, the header should be populated (with appropriate logic/value) in the matching IFlow that sends the message to this ProcessDirect endpoint.

• Add SAP_ApplicationID as an allowed header in this IFlow.

...

The behavior will be as follows:-

1. When message is triggered via Int4 IFTT triggers a message,  SAP_ApplicationID will be populated with IFTT GUID, and correlation will be successful.

2. When a message is send sent end-to-end (from the source system), sender IFlow will populate SAP_ApplicationID, which will be passed  passed on via ProcessDirect adapter to this IFlow.

Using Groovy script to handle populating SAP_ApplicationID

If it is not possible impossible to use the above approach, and the SAP_ApplicationID still needs to be set in the IFlow under test, consider handling the SAP_ApplicationID using Groovy script.

• Add SAP_ApplicationID as an allowed header in this IFlow (same as the previous approach)

• Store the value in a different header instead, ie.eq. UniqueID (example below)

...

• Handle populating SAP_ApplicationID using the following Groovy script.

The header SAP_ApplicationID will only be modified if it does not exist in the first place , and UniqueID is populated.

import com.sap.gateway.ip.core.customdev.util.Message

Message processData(Message message) {

    def applicationID = message.getHeader('SAP_ApplicationID', String)
    def uniqueID = message.getHeader('UniqueID', String)

    if (uniqueID && !applicationID)
        message.setHeader('SAP_ApplicationID', uniqueID)

    return message
}

...

1. When message is triggered via Int4 IFTT, SAP_ApplicationID will be populated with IFTT GUID, therefore . Therefore it will not be modified in the IFlow, ensuring correct correlation.

2. When a message is send sent end-to-end (from the source system), SAP_ApplicationID will be empty, so it is empty and will be replaced with the value stored in UniqueID.