SAP NetWeaver PI Dual-Stack Installation

Components

The following figure shows the main components of an SAP NetWeaver PI dual-stack installation.

Figure 1: Components of an SAP NetWeaver PI Dual-Stack Installation

The main components for design and configuration time are the Enterprise Services Repository (ES Repository) and the Integration Directory. Using these tools, an integration expert can design integration content (for example, interfaces and process integration scenarios) and specify the configuration settings for message exchange for a specific system landscape. The design and configuration tools are connected to the System Landscape Directory which contains, for example, the description of software components and systems. The ES Repository and the Integration Directory are technically based on AS Java.

The Integration Directory is connected to the ES Repository to allow access to specific design time objects (for example, mappings) also at configuration time.

More information:

Design Time

Configuration Time

Based on the configuration settings from the Integration Directory, messages are exchanged between the connected business systems at runtime. In a dual-stack installation of SAP NetWeaver PI, there are the following runtime engines:

Integration Engine (based on AS ABAP)
Business Process Engine (based on AS ABAP)

More information: Cross-Component Business Process Management
Advanced Adapter Engine (based on AS Java)

To process messages, the involved runtime engines use information from the Integration Directory. This information is made available to the runtime engines via runtime caches.

Different modes of message processing can be configured. Read the following section to learn more about that.

Integration Engine-Based Message Processing

“Integration Engine-Based”

When you install SAP NetWeaver PI (dual-stack installation option), you set up an “Integration Server” .

The Integration Server contains the Integration Engine that is based on AS ABAP and that provides the mediation services to process messages at runtime (mapping and routing).

Note

All SAP systems based on Application Server ABAP release 6.20 or higher contain a local Integration Engine, also when used as an application system. This local Integration Engine enables the system - when used as an application system - to connect to another system via an SAP NetWeaver PI runtime engine. This kind of connectivity is also referred to as connectivity based on the proxy runtime. All other systems - either SAP or third-party - connect to the SAP NetWeaver PI runtime using adapters.

More information: Connectivity

Additionally, the Integration Server contains a Java-based Advanced Adapter Engine (AAE). If the AAE is also involved in the communication, depends on the adapters used for inbound and outbound processing.

Note

Adapters run either on the Integration Engine or the AAE. The following adapters run the Integration Engine: IDoc, XI, HTTP, WS (connectivity to systems based on Web Services Reliable Messaging). All other adapters run on the AAE. In case an HTTP adapter is used, for example, for inbound processing, the AAE is not involved as runtime component, as this adapter runs on the Integration Engine.

For example, in case a JDBC (sender) adapter is used for inbound processing, the AAE is also involved in the communication to provide the required connectivity. The following figure illustrates this situation for the case where the AAE is connected upstream to the Integration Engine (providing the required connectivity at sender side):

Figure 2: Integration Engine-Based Communication Including the AAE at Sender Side

In the figure, the communication performed at runtime is marked with red arrows. The design and configuration tools (ES Repository, Integration Directory, and System Landscape Directory) are added to the figure in order to point out that they are needed to set up the shown communication.

Local Message Processing Using the AAE

You can also process messages “locally” on the AAE without involving the Integration Engine. This option ensures a considerably higher performance. However, there are some restrictions regarding the mediation capabilities compared to scenarios with full involvement of the Integration Server. For example, the “WS adapter” cannot be used. The following figure illustrates local message processing on the AAE:

Figure 3: Local Message Processing on the AAE, Bypassing the Integration Engine

In the figure, the communication performed at runtime is marked with red arrows. It is also illustrated that besides the fact that the Integration Engine is “bypassed” at runtime, the design and configuration time tools are still needed to set up the communication.

Message Processing Using the non-Central AAE

In addition to using the AAE as part of the Integration Server (the central Adapter Engine), there's also the option to use the AAE stand-alone, next to the Integration Server (non-central AAE). That means, the AAE can be installed on a system with a different SAP system ID (SID) than the Integration Server and be used as an independent integration hub. However, note that you need an ES Repository and an Integration Directory as design and configuration tools in order to set up the scenarios.

The following figure shows the basic communication flow at runtime:

Figure 4: Message Processing Using the non-Central AAE