Show TOC

Background documentationMessage Processing at Runtime Locate this document in the navigation structure

 

The business process is executed in the system landscape at runtime, which means that the process is executed and messages are exchanged between the systems involved. In mediated scenarios, messages are processed by a central instance — or: runtime engine — that interconnects the systems.

As described under Installation Options, a dual-stack SAP NetWeaver PI instance provides the following runtime engines:

  • Integration Engine (IE)

    Applications using the proxy runtime or Web services runtime send messages to the IE. Further-on, the IE enables connectivity to systems sending IDocs and via the native HTTP interface (via the HTTP adapter).

    The IE is based on SAP Application Server ABAP (AS ABAP).

  • Advanced Adapter Engine (AAE)

    Enables connectivity to external systems via a variety of adapters.

    The AAE is based in SAP Application Server Java (AS Java).

Note Note

For sakes of simplicity, we do ignore the Business Process Engine (which also runs on AS ABAP) within this section as this runtime engine comes only into play in scenarios that use integration processes (cross-component Business Process Management).

End of the note.

The Advanced Adapter Engine Extended (AEX: Java-only installation option) provides only the Advanced Adapter Engine as runtime engine.

This section provides detailed information on how a message is processed by the involved runtime engines.

With a dual-stack installation of SAP NetWeaver PI, messages can be processed in different ways. On the one hand, both runtime engines can be involved. Correspondingly, in that case we talk about “dual-stack message processing”. In contrast to that, you can also configure scenarios that way that only one runtime engine (either the AAE or the IE) is involved.

The following figure shows how the involved systems and runtime engines communicate with each other for a dual-stack message processing scenario (at left) and a single-stack message processing scenario (at right).

Note Note

The figure shows two different message processing options in case the dual-stack installation option of SAP NetWeaver PI is used.

End of the note.

This graphic is explained in the accompanying text.

Dual-Stack (Left) and AAE-only (Right) Message Processing

For the dual-stack processing scenario, only the case is shown where the AAE is connected upstream to the Integration Engine (providing the required connectivity at sender side). As single-stack message processing option, only the case is shown where the AAE is involved as runtime engine. In the following, additional possible cases are shown.

The following figure shows in more detail all possible ways a messages can pass through the runtime engines.

Note Note

To make the process flow of each individual option more transparent, the individual cases are shown in separate figures in the subsequent sections.

End of the note.

This graphic is explained in the accompanying text.

Overview of Message Processing Options

The kind of message processing that applies at runtime depends on the configuration settings in Integration Directory that match the incoming message. Configuration settings in Integration Directory are structured as configuration objects. In general, those configuration objects apply for processing of a specific message that have an object key that matches the address header of the message.

For more information on these concepts, see:Configuration Time.

The conditions that determine which message processing option applies at runtime, are indicated in the figure above as comments besides the corresponding branch of the process flow. These conditions are explained in detail below.

Note Note

Note that branches (where a decision is taken) are indicated as white rhombuses, whereas joints (where two message processing paths are merged) are indicated as grey rhombuses.

End of the note.

The inbound message contains information about the sender of the message and the service interface that specifies the message data structure. As soon as inbound message processing is started (by the sender adapter), the message header is evaluated.

There are the following cases:

  • A system sends a message to the IE.

    In specific cases (for example, when an SAP system is connected to an SAP NetWeaver PI instance via the proxy runtime) a message is sent to the IE. In the runtime cache that sender agreement is searched for and evaluated that has an object key that matches the header of the incoming message.

    Further message processing is specified by a set of Integration Directory configuration objects of the following type: receiver determination, interface determination and receiver agreement.

    After the pipeline processing steps like routing and mapping (that are specified by receiver and interface determinations), the matching receiver agreement is evaluated in order to execute outbound processing. Here, the following cases can occur:

    • An IE adapter (which means: an adapter that runs on the IE) is assigned to the receiver agreement.

      In that case, outbound processing is continued on the IE and the message sent to the receiver system by the IE.

    • An AAE adapter is assigned to the receiver agreement.

      In that case, the message is handed over to the AAE, where further outbound processing is executed.

  • A system sends a message to the AAE.

    Example Example

    As an example, the sender system is connected to the SAP NetWeaver PI instance via the SOAP adapter.

    End of the example.

    In that case, the following situations can occur:

    • For the incoming message (and the applied sender adapter) a sender agreement is found in the runtime cache.

      In that case, after inbound processing the message is forwarded to the IE where the further processing steps are performed.

      This is one case of dual-stack message processing.

      Note Note

      If during that processing sequence a receiver agreement applies with an AAE adapter assigned, the message is again handed over from the IE to the AAE and sent from there to the receiver system.

      End of the note.

    • For the incoming message (and the applied sender adapter) an integrated configuration is found in the runtime cache.

      Message processing is continued on the AAE.

      Note Note

      This is the case of AAE-only message processing. Using the AEX installation option, only this path is possible.

      End of the note.
Single-Stack Message Processing Options (Detail)

We explain in more detail the case when only the AAE is used at runtime. The following figure illustrates this case.

This graphic is explained in the accompanying text.

AAE-Only Message Processing

A message with a header that matches an integrated configuration passes through the following steps:

  1. Sender adapter processing

  2. Advanced Adapter Engine pipeline processing

  3. Receiver adapter processing

For more information on the steps in detail, in particular on the steps within the messaging system, see Message Processing (Advanced Adapter Engine).

For sake of completeness, the following figure illustrates the case where only the IE is involved at runtime. This case applies when a sender agreement is found for the inbound message and an IE adapter is used for both inbound and outbound processing.

This graphic is explained in the accompanying text.

IE-Only Message Processing

Dual-Stack Message Processing (Detail)

The following figures illustrate the possible cases of dual-stack message processing.

We discuss in detail the first example.

This graphic is explained in the accompanying text.

Dual-Stack Message Processing (AAE Sender Adapter, IE Receiver Adapter)

According to the figure above, a messages passes through the following steps:

  1. Sender adapter processing

    Based on the configuration of the sender adapter, the message is transformed technically to the XML message format the PI runtime can process (“XI message format”). In case also additional security-related configuration settings apply, the message is handled accordingly.

    Because a sender agreement applies, the message is handed over to the IE, and further processing is executed there.

  2. Integration Engine pipeline processing

    Processing of the message in the IE pipeline contains the following steps:

    1. Inbound XML validation

      Based on the configuration settings, the inbound message is checked with regard to validity of its XML schema.

    2. Receiver determination

      Based on the receiver determination that is found for the message, the receivers of the message and the routing conditions are evaluated. The receiver is written into the message header. In case multiple receivers are configured, for each receiver, a separate message is created.

    3. Mapping

      Based on the interface determination that is found for the message, the assigned mapping program is performed and the content of the message transformed accordingly.

    4. Interface determination

      Based on the interface determination that is found for the message, the assigned inbound interface (at the receiver side) is evaluated.

      Note Note

      More sophisticated scenarios can be configured where a message is sent to multiple inbound interfaces or where a large message is split into several “message chunks” which are then sent to different inbound interfaces. For sakes of simplicity we do not consider these cases here and instead of that refer to the corresponding section: Defining Message Splits.

      End of the note.

    5. Outbound XML validation

      Based on the configuration settings, the outbound message (to be sent to the receiver) is checked with regard to validity of its XML schema.

  3. Receiver adapter processing

    In the example illustrated in the figure above, a receiver adapter is assigned for outbound processing that runs on the IE. Therefore, the message processing is continued on the IE. Based on the configuration of the receiver adapter (that is assigned to the receiver agreement), the message is transformed technically from the “XI message format” to the format the receiver can process. In case also additional security-related configuration settings apply, the message is handled accordingly.

For the sake of completeness, the following figures illustrate the additional cases.

This graphic is explained in the accompanying text.

Dual-Stack Message Processing (IE Sender Adapter, AAE Receiver Adapter)

This graphic is explained in the accompanying text.

Dual-Stack Message Processing (AAE Sender Adapter, AAE Receiver Adapter)

More detailed information on the individual steps in a dual-stack message processing scenario: Saving Message Versions in the AAE (Dual-Stack Message Processin