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 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. |
|
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.
|
|||
|
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 in the field Allowed Headers of the integration flow’s runtime configuration. |
|
HTTP and Kafka Adapters |
|||
|
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.
References
Data Store Operations:
JMS Adapter:
Data Store Adapter:
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.
