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 from within an IFlow using a Script or Content Modifier step. The value populated in this header in searchable from Web UI monitoring.

When testing CPI IFlows with Int4 IFTT, it is important to take into consideration if this 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 test results.

• ProcessDirect

• HTTPS

• IDoc

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

If the population of SAP_ApplicationID in the IFlow being tested is still required, 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.

The behavior will be as follows:-

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

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

Using Groovy script to handle populating SAP_ApplicationID

If it is not possible 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 previous approach)

• Store the value in a different header instead, i.e. 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:-

1. 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.

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