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).
What is Apache Camel?
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:
- Exchange ID: A unique ID that identifies the exchange.
- MEP: Short for message exchange pattern, field can contain two possible values: InOnly and InOut. InOnly is when a route handles a one-way message, where the sender doesn’t wait for a reply from the receiver. Hence, the exchange carries an in message only. A scenario where a message travels in one direction only and where no response message is expected during the communication is also known as asynchronous message handling. InOut is when a route handles a request-response message. The sender expects a reply from the route, which will be stored as an out-message in the exchange. This behavior is also known as synchronous message handling.
- Exception: If an error occurs during message processing, the reason for the error is stored in the Exception field of the exchange.
- Properties: A form of temporary storage where process steps can store data in addition to the header area in the message. Properties can contain global-level information. Developers can store and retrieve properties at any point during the lifetime of an exchange.
Difference between Headers and Properties
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:
- Receiver determination
- Interface determination
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, 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.