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 Integration Suite relies on an open-source integration framework called Apache Camel (or Camel for short).
Note: Cloud Integration is currently based on Apache Camel version 3.0. Be aware that you can't just use any Apache Camel feature, property, or header in Cloud Integration. You should only use the features, properties, and headers that are explicitly supported by Cloud Integration, as described in the documentation here.
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:
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 Cloud 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 Cloud 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 with SAP.
Editor’s note: This post has been adapted from a section of the book Cloud Integration with SAP Integration Suite: The Comprehensive Guide by John Mutumba Bilay, Shashank Singh, Swati Singh, Peter Gutsche, and Mandy Krimmel.