You likely know that, from a modeling perspective, integration flow is based on BPMN. But how is the integration flow interpreted and executed during runtime?
For this purpose, SAP Cloud Platform Integration relies on an open-source integration framework called Apache Camel (or Camel for short).
So, what exactly is Camel? It’s a message routing and mediation engine. Interestingly enough, Camel is payload-agnostic, which means you can feed the engine with any data format, and Camel forwards it to the respective receivers depending on the modeled route. As long as there is no need to access the message’s content (e.g., for routing purposes), Camel can handle any message format. However, some basic structure must also be available in Camel, depicted here:
To understand the inner workings of SAP Cloud Platform Integration, you should be familiar with the inner workings of Camel. If you’re looking for an overview of Camel, check out Claus Ibsen and Jonathan Anstey’s book Camel in Action (Manning Publications Co., 2010). Another valuable source of information for the Camel framework is the online documentation, found at http://camel.apache.org/documentation.html.
Assuming you have some background in Apache Camel, you’ll be prepared to follow along with this scenario of Apache Camel and SAP.
Note: Be aware that you can’t just use any Camel feature, property, or header in SAP Cloud Platform Integration. You should only use the features, properties, and headers that are explicitly supported by SAP Cloud Platform Integration. Please refer to the SAP documentation found at https://help.sap.com/viewer/product/CLOUD_INTEGRATION/Cloud.
Camel messages consist of headers, a body containing the raw data (the payload), and (optional) attachments. Messages are uniquely identified by an identifier of the type java.lang.String (which are not shown in the figure above). The headers are additional values associated with the message, such as sender identifier, hints about content encoding, and authentication information.
This information is added as headers in the form of name-value pairs. The name is a unique, case-insensitive string, whereas the value is of the type java.lang.Object. This is quite interesting, as almost anything can be added as an object to the header. The same is applicable for the body, which is also of the type java.lang.Object. Attachments are typically used for web service and email components and can transport additional data as separated items, if necessary.
During message processing, Camel requires a dedicated container for the message. The container is called an exchange, and it holds additional data besides the message. The exchange is passed along, step by step, in the processor chain, and every step has access to all the information the exchange carries. It can be seen as a global storage for the route as long as the message is being processed. The structure of an exchange looks like this:
Let’s briefly go over the parts that make up an exchange:
Note that headers are part of a message and are propagated or transferred to a receiver. On the other side, properties last for the entire duration of an exchange but aren’t transferred to a receiver.
A big difference regarding message handling within SAP Cloud Platform Integration, as compared to SAP Process Integration, is the flexible pipeline concept that stands behind Camel. In SAP Process Integration, you basically have three fundamental steps:
In addition, the sequence of these three steps is fixed. It’s not possible to have, for example, a mapping step before an interface determination step. The result is a rather static message-processing environment. With SAP Cloud Platform Integration, this changes significantly. You have many more steps at your disposal, and you can use them in (almost) any sequence that your scenario requires.
Message processing with Apache Camel and SAP is an important process to undertake. In this blog post, we took a look at Camel itself, messages and exchanges, and headers and properties. With this in mind, you should be prepared to begin working on message processing within SAP Cloud Platform.
Editor’s note: This post has been adapted from a section of the book SAP Cloud Platform Integration: The Comprehensive Guide by John Mutumba Bilay, Peter Gutsche, Mandy Krimmel, and Volker Stiehl.