Handling of header SAP_ApplicationID in CPI IFlows

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

When testing CPI IFlows with Int4 IFTT, it is essential to consider if the header is modified in the IFlow being tested. 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 false test results.

ProcessDirect
HTTPS
IDoc
SOAP (with Message Exchange Pattern = Request-Reply)

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 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:

When Int4 IFTT triggers a message, SAP_ApplicationID will be populated with IFTT GUID, and correlation will be successful.
When a message is sent end-to-end (from the source system), sender IFlow will populate SAP_ApplicationID, passed on via ProcessDirect adapter to this IFlow.

Using Groovy script to handle populating SAP_ApplicationID

If it is 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, e.q. 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
}

Following is a visual representation of the two steps.

The behavior will be as follows:-

When message is triggered via Int4 IFTT, SAP_ApplicationID will be populated with IFTT GUID. Therefore it will not be modified in the IFlow, ensuring correct correlation.
When a message is sent end-to-end (from the source system), SAP_ApplicationID is empty and will be replaced with the value stored in UniqueID.