Once you start developing more complex integration scenarios in CPI, it is likely that you may come across some unexpected behaviors. Once such recent experience was related to the usage of message header/property in a multicast pattern.
Initially, it was puzzling why runtime errors were occurring or data were not populated correctly. Upon further trial-and-error, it was identified that it was related to the usage of the sequential multicast pattern.
Specifically, when creating/updating a message's header or property within one branch of the multicast, it is not available in the subsequent branch. As such behavior is not documented, it was not immediately obvious and require further investigation to confirm the behavior.
Let's proceed to see how this works with a sample integration flow.
To test this out, the below integration flow is used.
Additionally, for header/property created in the main route, it is also tested with the following object types:-
With additional logging in each of the scripts, the content of the message headers and properties are logged into the MPL as attachments. Below are the test results when a message is triggered into the integration flow.
1 - Main Route
Following headers and properties are created and populated with data; MainHeader, MainProperty, MainHeaderMap, and MainPropertyMap.
2 - Route 1
In the first branch of the multicast, the main headers/properties are modified. Additionally, Route1Header and Route1Property are created and populated. These are highlighted in yellow below.
3 - Route 2
Finally, when the message reaches the second branch of the multicast, the following are observed in the logs:-
The following table summarises the behavior of message header/property when using the multicast pattern.
If you noticed the other details in the above logs, you might have observed that the Camel Exchange ID changes when it moves from the main route to the multicast branches. This can be verified further in the MPL, where it indicates that a new Exchange ID is created during branching.
Therefore the behavior documented above could be attributed due to the change in the Camel Exchange during a multicast.
As such, it is important to take note of this when using a multicast in an integration flow to prevent any undesired side-effects.
Initially, it was puzzling why runtime errors were occurring or data were not populated correctly. Upon further trial-and-error, it was identified that it was related to the usage of the sequential multicast pattern.
Specifically, when creating/updating a message's header or property within one branch of the multicast, it is not available in the subsequent branch. As such behavior is not documented, it was not immediately obvious and require further investigation to confirm the behavior.
Let's proceed to see how this works with a sample integration flow.
Sample Integration Flow
To test this out, the below integration flow is used.
- An HTTPS sender is used to trigger a message into the integration flow.
- The main route is split into two branches using a sequential multicast.
- Script1 - Creates headers and properties in the main route
- Script2 - Modifies headers and properties (from main route) and creates new header and property
- Script3 - Accesses all headers and properties created from above
Additionally, for header/property created in the main route, it is also tested with the following object types:-
- java.lang.String
- java.util.HashMap
Test Results
With additional logging in each of the scripts, the content of the message headers and properties are logged into the MPL as attachments. Below are the test results when a message is triggered into the integration flow.
1 - Main Route
Following headers and properties are created and populated with data; MainHeader, MainProperty, MainHeaderMap, and MainPropertyMap.
2 - Route 1
In the first branch of the multicast, the main headers/properties are modified. Additionally, Route1Header and Route1Property are created and populated. These are highlighted in yellow below.
3 - Route 2
Finally, when the message reaches the second branch of the multicast, the following are observed in the logs:-
- Modifications made in Route 1 to the String-based header/property of the main route are not seen.
- Header/Property created in Route 1 are not accessible.
- Modifications made in Route 1 to the HashMap-based header/property of the main route are seen.
Conclusion
The following table summarises the behavior of message header/property when using the multicast pattern.
| Header/Property Object Type | Created In | Accessible in Subsequent Branch | Modifications in Predecessor Branch seen in Subsequent Branch |
| java.lang.String | Main route | Yes | No |
| java.util.HashMap | Main route | Yes | Yes |
| Any | Multicast branch | No | N/A |
If you noticed the other details in the above logs, you might have observed that the Camel Exchange ID changes when it moves from the main route to the multicast branches. This can be verified further in the MPL, where it indicates that a new Exchange ID is created during branching.
Therefore the behavior documented above could be attributed due to the change in the Camel Exchange during a multicast.
As such, it is important to take note of this when using a multicast in an integration flow to prevent any undesired side-effects.
- SAP Managed Tags:
4 Comments
