Message Headers and Properties Transfer Behavior

Retained or not retained? That’s the question.

When it comes to asynchronously passing messages between IFlows using a Data Store or JMS Queue on Cloud Integration, I was often scratching my head when trying to remember in which case headers or properties are passed on to the receiver IFlow. Sometimes they get retained and therefore passed on, sometimes they get lost and not passed on.

In the synchronous case of forwarding a message to another IFlow, using Process Direct Adapter, it’s less confusing as it’s more simple: Headers are retained, properties lost. For the sake of completeness, I have also added the synchronous cases at the end of the table.

But the asynchronous case, where you could use the Data Store or JMS Queues, this is not so straightforward as header parameters and properties are treated differently depending on the technique used to store or forward messages in between processing by multiple IFlows.

This post aims to provide an overview serving as a quick reference for developers designing or developing IFlows. The first part is about the asynchronous cases (temporarily persisting data and picking them up from another IFlow) and is split up in two parts, one for Data Store and one for JMS Queues. The second part is for the asynchronous cases.

The table lists if a writing step or receiver adapter retains some of the data and on the other hand if a reading step or sender adapter makes the data available again on the receiver’s Integration Process side.

Properties

Asynchronous Messaging

Data Store Steps/Adapter

Save in Data Store (Write step)

retained (if configured in channel)

lost

Configuration needed.

Read any message from Data Store (=> get all entries in bulk) – Select Operation

lost

lost

see 1)

Read specific message from Data Store (by specifying the entry ID) – Get Operation

available

lost

see 2)

1) This step creates a bulk (multi-) message with a messages node and a message node per message (with attribute id containing the message ID). Therefore it’s logically not possible to retain headers/properties for every message in the actual message properties of the bulk message. However, there’s a workaround if you still need to retrieve headers! See comment at Get Operation, don’t use the Select Step.

2) We can use a DataStore sender adapter as Iflow sender channel – instead of using a Select Step – which sets the header SapDataStoreId and then use this value in the Get step to get any DS entry including its header! See also my follow up blog (coming soon).

JMS Adapter

JMS queue write – JMS receiver channel

lost

retained (if configured in channel)

Configuration needed.

JMS queue read – JMS sender channel

lost

available

Persist Step

Save message with Persist step

retained

lost

Can only be read with external tools (like CPI Helper), therefore only for monitoring purposes.

Synchronous Messaging

Process Direct Adapter

PD receiver channel

retained

lost

PD sender channel

available

lost

Remember to list the headers that you whish to retrieve in the field Allowed Headers of the integration flow’s runtime configuration.

HTTP Adapter

Same behavior as with Process Direct.

Hope this is helpful for others as it is for me.

In case of questions or if you find any errors or inconsistencies, please let me know.