Cloud Integration: Message Headers and Properties Transfer Behavior

[philippeaddor]

Update 11 Dec. 2023: Added the note regarding the exception for retaining properties in case of the JMS default queues created by the XI sender adapter.

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

But in 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 synchronous 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.

Activity	Header	Properties	Remarks
Asynchronous Messaging
Data Store Steps/Adapter
Save in Data Store (Write step)	retained (if configured in channel)	lost	Configuration needed to retain Header.
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
DS Sender Adapter	available	lost	Remember to list the headers in the field Allowed Headers of the integration flow's runtime configuration.
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. If you need this, use the Data Store Sender Adapter instead that creates single messages per DS entry and keeps the headers! JMS Adapter
JMS queue write - JMS receiver channel	retained	retained (if configured in channel)	Configuration needed to retain Properties. Exception: Not possible for the default queues of the XI Sender Adapter! Properties are lost in case of retry!
JMS queue read - JMS sender channel	available	available (if configured JMS receiver channel)	Remember to list the headers in the field Allowed Headers of the integration flow's runtime configuration.
Note: Headers and exchange properties defined in the integration flow before the message is saved to the queue must not exceed 4 MB in total. Persist Step
Save message with Persist step	retained	lost	Can only be read by API or with external tools (like CPI Helper), and only available after message processing finished. Therefore only for monitoring purposes.
Synchronous Messaging
Process Direct Adapter
Process Direct receiver channel	retained	lost
Process Direct sender channel	available	lost	Remember to list the headers in the field Allowed Headers of the integration flow's runtime configuration.
HTTP and Kafka Adapters
Same behavior as with Process Direct.

Hope this serves as a helpful cheat sheet.
In case of questions or if you find any errors or inconsistencies, please let me know.
 

References

Data Store Operations:
https://help.sap.com/docs/CLOUD_INTEGRATION/368c481cd6954bdfa5d0435479fd4eaf/79f63a4bf5a44b5996aa34c...

JMS Adapter:

https://help.sap.com/docs/CLOUD_INTEGRATION/368c481cd6954bdfa5d0435479fd4eaf/79edc04c91574a6bb8c15ae...

Data Store Adapter:

https://help.sap.com/docs/CLOUD_INTEGRATION/368c481cd6954bdfa5d0435479fd4eaf/0993f2aa14124376a4adc7c...
 

Update: Blog updated as per Alexander Bundschuh's comments

Update 09/20: Update header/property limit for JMS queues as per jeremy.ma's comment.