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.
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:
Camel Messages
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.
Camel Exchanges
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 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:
- Receiver determination
- Interface determination
- Mapping
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.
Conclusion
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.
Comments