The installation option Advanced Adapter Engine Extended (AEX) provides the connectivity capabilities of the Advanced Adapter Engine (AAE) as well as the design and configuration tools (ES Repository and the Integration Directory) to set up scenarios based on the AAE. The Integration Directory installed with AEX contains the same subset of configuration options as that of the AAE, basically the integrated configuration.
The following figure shows the main components of the AEX:
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.
Based on the configuration settings from the Integration Directory, messages are exchanged between the connected business systems at runtime. AEX uses the Advanced Adapter Engine as runtime engine.
To process messages, the Advanced Adapter Engine (AAE) uses information from the Integration Directory. This information is made available to the AAE via a runtime cache.
AEX supports the mediation capabilities of the AAE. In particular, you can use the following adapters:
SAP Business Connector Adapter
IDoc Adapter (Advanced Adapter Engine) (adapter type IDOC_AAE)
HTTP Adapter (Advanced Adapter Engine) (adapter type HTTP_AAE)
More information on the individual adapters: Adapter Configuration (AAE)
The RNIF and CIDX adapters, together with the corresponding business packages, allow you to set up business-to-business scenarios based on the corresponding industry standard (RosettaNet, respectively Chem eStandards).
More information: Setting Up Integration Based on SAP Business Packages
Note that when you have installed the Advanced Adapter Engine Extended (AEX), integration processes cannot be used. Therefore, those scenarios of the business package that use integration processes are not supported in that case.
Technically, the installation option AEX is based on AS Java.
Since AEX is based on AS Java alone, it is easier to install and maintain as it needs less memory and data storage. Therefore, AEX is a cost-saving option compared to a full installation of SAP NetWeaver PI.
Compared to a complete SAP NetWeaver PI installation, AEX has the following restrictions:
The connectivity options are restricted to the adapters of the AAE.
That means, you cannot use the following adapter types: IDoc (IE), XI, HTTP (IE), WS (connectivity with systems based on Web Services Reliable Messaging).
You cannot use integration processes (cross-component Business Process Management).
You can only use process integration scenarios as modelling option in the ES Repository.
Parameterized mapping programs are not supported.
ABAP mapping is not available.
Basically, you can use AEX in the following ways:
Using AEX standalone
Using AEX in combination with an additional SAP NetWeaver PI landscape
Using AEX Standalone
You can use AEX standalone as integration middleware. The basic communication options are illustrated in the following figure:
This use case is suitable in the following situations (examples):
Using AEX as “lightweight” and low-cost integration middleware
For scenarios that require only connectivity capabilities provided by the AAE and that do not contain any integration processes (cross-component BPM), you can choose the installation option AEX which is technically based only on the AS Java. In former releases, also for those scenarios a standard installation of SAP NetWeaver PI (technically based on both AS Java and AS ABAP) was required.
Using AEX as test environment
As an AEX installation provides not only a runtime engine (Advanced Adapter Engine) but also the ES Repository and the Integration Directory, it supports the complete life-cycle of an integration project. Therefore, you have a complete and consistent toolset to set up, configure and test integration scenarios in your landscape.
Note that, however, AEX provides only a restricted functional range as compared with SAP NetWeaver PI complete installation. In particular, you cannot test integration processes (ccBPM) with this setup.
Using AEX as fail-over system
You can transport complete integration scenarios (integration content from the ES Repository) as well as the configuration content (Integration Directory) from a productive landscape (for example based on a SAP NetWeaver PI standard installation) to a “fail-over landscape” based on AEX. Note that this transport option is restricted to those Integration Directory objects that are supported by AEX, for example integrated configurations.
Using AEX in Combination with an Additional SAP NetWeaver PI Landscape
You can connect your AEX-based landscape to a landscape that is based on SAP NetWeaver PI. The basic communication options are illustrated in the following figure:
This use case is suitable in the following example situations:
Separating network zones
As an example, you can set up a landscape based on an SAP NetWeaver PI standard installation for your security-critical scenarios. You can add an AEX installation in your demilitarized zone (DMZ) that is used for the external communication. Between the AEX in the DMZ and the “PI standard system” , you can easily configure a change of the transport protocol in order to provide maximum security.
Separating landscapes for different regions of an enterprise
As an example, you can use landscapes based on AEX as cost-saving integration solution for the regional business processes and a PI standard installation for the central processes of an enterprise.
When you use AEX in combination with a landscape based on an SAP NetWeaver PI standard installation, you carefully need to take into consideration all implications that come along also in case of federated PI landscapes. For example, the content of the individual ES Repositories (installed with the AEX on the one and with the standard PI system on the other hand) is not aligned automatically so that suitable transport scenarios have to be planned.
Using a Non-Central AAE as Part of an AEX Installation
Analog to a standard dual-stack installation you have the option to install a non-central Advanced Adapter Engine (non-central AAE) separately on a system with a different SAP system ID (SID) than the central AAE. At runtime, the non-central AAE works independent from the central one.
The design and configuration environment (ES Repository and Integration Directory) resides on the server of the central AAE. Both central and non-central AAE register themselves at the same System Landscape Directory (SLD).
With regard to user management, the non-central AAE works completely autarkic, because it uses a local User Management Engine.
The following figure illustrates the set up.
Note the following characteristics of the usage of a non-central AAE in an AEX installation:
You configure the non-central AAE using the Java Service Properties in SAP NetWeaver Administrator.
You cannot set up scenarios where an Integration Engine is involved in the communication.