While the venerable Content Modifier flow step is arguably not the most interesting tool in the Cloud Integration toolbox, it’s a real workhorse that you probably use in most of your integration flows. With this flow step, you can:
You do so on the Message Header, Exchange Property and Message Body tabs, respectively, of the flow step configuration:
You can use the same Content Modifier flow step to, for instance, add both a header and set the message body. However, what’s not immediately obvious (nor documented, as far as I can tell), is whether the header is created first, and is therefore available to be included in the message body, should you need to do so.
In other words, are headers, properties and the message body evaluated in the order indicated by the UI? Let’s find out.
For starters, let’s set up a Content Modifier flow step which adds a header (
After the Content Modifier flow step, the message body looks like this:
This would seem to support, that headers are evaluated first, then properties, and finally the message body, but it doesn’t really prove anything conclusively. The evaluation order might in fact be random, and we just chanced on that particular order.
Let’s try something else. We’re going to store the “Hello, world!” message in the property, set the header to the value of the property, and insert the value of the header into the message body with the expression
Now, following the Content Modifier flow step, the message body looks like this:
If headers are evaluated first, then properties, and finally the message body, the message body would indeed end up looking like this (since in that case, the property has not been evaluated yet, when we create a header based on its value). However, the behaviour we’re seeing could still be random or the result of some opaque timing issue.
Luckily, there’s a way for us to find out for sure. As you may already know, CPI is based on the open source Apache Camel integration framework. Behind the scenes, your integration flow is converted to a so-called Camel route. The route contains the logic of the integration flow, as well as its various configuration details. Unfortunately, the Camel route is not accessible through the Web UI, but we do have access to an XML representation of the route generated by CPI.
To find it, download your integration flow from the operations view of the Web UI (if you download it from the design view, the Camel route XML is not included in the archive). In the downloaded JAR-file, open the
The following three elements hold the key to determining the evaluation order of headers, properties and the message body:
I’ve been able to confirm with Claus Ibsen of the Apache Camel project, that these three elements are indeed processed in the order they occur in the XML document.
So there we have it: Within the same Content Modifier flow step, headers are evaluated first, then properties, and finally the message body. This means that the message body can safely use headers and properties defined in the same Content Modifier, and properties can safely use headers defined in the same Content Modifier.
Thank you for reading, and thank you to Claus Ibsen for his valuable input. Also, a hat tip to my fellow SAP Mentor engswee.yeoh for pointing out that the Camel route XML is contained in the integration flow JAR downloaded from the operations view.
- Create and delete headers
- Create and delete exchange properties
- Set the message body
You do so on the Message Header, Exchange Property and Message Body tabs, respectively, of the flow step configuration:
You can use the same Content Modifier flow step to, for instance, add both a header and set the message body. However, what’s not immediately obvious (nor documented, as far as I can tell), is whether the header is created first, and is therefore available to be included in the message body, should you need to do so.
In other words, are headers, properties and the message body evaluated in the order indicated by the UI? Let’s find out.
For starters, let’s set up a Content Modifier flow step which adds a header (
headerMessage), adds an exchange property (propertyMessage) with the value of the header, and finally adds an XML message body, which includes the exchange property using the expression ${property.propertyMessage}. Here’s the required configuration:After the Content Modifier flow step, the message body looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<message>Hello, world!</message>This would seem to support, that headers are evaluated first, then properties, and finally the message body, but it doesn’t really prove anything conclusively. The evaluation order might in fact be random, and we just chanced on that particular order.
Let’s try something else. We’re going to store the “Hello, world!” message in the property, set the header to the value of the property, and insert the value of the header into the message body with the expression
${header.headerMessage}. The configuration looks like this:Now, following the Content Modifier flow step, the message body looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<message></message>If headers are evaluated first, then properties, and finally the message body, the message body would indeed end up looking like this (since in that case, the property has not been evaluated yet, when we create a header based on its value). However, the behaviour we’re seeing could still be random or the result of some opaque timing issue.
Luckily, there’s a way for us to find out for sure. As you may already know, CPI is based on the open source Apache Camel integration framework. Behind the scenes, your integration flow is converted to a so-called Camel route. The route contains the logic of the integration flow, as well as its various configuration details. Unfortunately, the Camel route is not accessible through the Web UI, but we do have access to an XML representation of the route generated by CPI.
To find it, download your integration flow from the operations view of the Web UI (if you download it from the design view, the Camel route XML is not included in the archive). In the downloaded JAR-file, open the
OSGI-INF/blueprint/beans.xml XML document. Within, you’ll find the Camel route and its configuration inside the <camel:route> element.The following three elements hold the key to determining the evaluation order of headers, properties and the message body:
I’ve been able to confirm with Claus Ibsen of the Apache Camel project, that these three elements are indeed processed in the order they occur in the XML document.
So there we have it: Within the same Content Modifier flow step, headers are evaluated first, then properties, and finally the message body. This means that the message body can safely use headers and properties defined in the same Content Modifier, and properties can safely use headers defined in the same Content Modifier.
Thank you for reading, and thank you to Claus Ibsen for his valuable input. Also, a hat tip to my fellow SAP Mentor engswee.yeoh for pointing out that the Camel route XML is contained in the integration flow JAR downloaded from the operations view.
- SAP Managed Tags:
2 Comments
