Excerpt from the book SAP HANA Cloud Integration by @johnbilay, @peter.gutsche, and @volker.stiehl. Used with permission of SAP PRESS. All rights reserved.

 

Summary: This blog gives an overview of how the Apache Camel Framework is used for processing messages in SAP HCI.

From a modeling perspective, the message processing flow in SAP HCI is based on BPMN. But how is the integration flow interpreted and executed during runtime? For this purpose, SAP HCI relies on an open source integration framework called Apache Camel (or Camel for short). To understand the inner workings of SAP HCI, you should be familiar with the inner workings of Camel. That’s why you find additional names for message processing in the following figure, because, in Camel, the respective terms for the handling of messages are route or processor chain.

So, what exactly is Camel? It is a message routing and mediation engine. Interestingly enough, Camel is payload-agnostic. This 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 (such as for routing purposes), Camel can handle any message format. However, some basic structure must also be available in Camel, as depicted below.

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 (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 the exchange is as follows:

Let’s briefly go over the parts that make up an exchange:

  • Exchange ID: A unique ID that identifies the exchange.
  • MEP (abbreviation for message exchange pattern): This field can contain two possible values: InOnly and InOut.
    • InOnly: The route handles a one-way message, where the sender does not 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: The 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: In case of an error 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.

A big difference regarding message handling within SAP HCI, as compared to SAP PI, is the flexible pipeline concept that stands behind Camel. In SAP PI, you basically have three fundamental steps:

1. Receiver determination

2. Interface determination

3. Mapping

In addition, the sequence of these three steps is fixed. It is 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 HCI, this changes significantly. You have many more steps at your disposal, and you can use them in (almost) any sequence that your scenario requires.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply