PI 7.31- Advanced Adapter Engine Extended (AEX) – Overview

What is the new Advanced Adapter Engine Extended (AEX)?

• SAP Net Weaver Process Integration installation alternative.

• Fully independent, single-stack solution based on SAP Net Weaver AS Java only– Own integration domain.

• Own tools for design, configuration, and operations.

• ES Repository, Integration Directory, SLD, NWA, Monitoring.

• Powered by Advanced Adapter Engine (AAE) introduced in 7.1 (but with more capabilities).

• Not to be confused with a non-central AAE.

• Additional mediation and connectivity features to allow for major scenario shifts to AEX Available starting from SAP Net Weaver PI 7.3.

Architecture of Adapter Engine Extended (AEX)

Advanced Adapter Engine Extended (AEX) provides the connectivity capabilities of the AAE as well as the design and configuration tools to set up scenarios based on the AAE.  AEX uses the Advanced Adapter Engine as runtime engine. To process messages, the AAE uses information from the Integration Directory. This information is made available to the AAE via a runtime cache.

The following figure shows the main components of the AEX

•  Design Time-Enterprise Services Repository

•  Configuration Time -Integration Directory

• SLD – System Landscape Directory

Adapter Engine Extended (AEX) – Installation Options and Use Cases. 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.
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

Using AEX as “lightweight” and low-cost integration middleware
 This installation option for AEX is technically based only on the AS Java for scenarios that do not contain any integration processes (cross-component BPM).
Using AEX as test environment
 AEX installation provides not only a runtime engine AAE but also the ES Repository and the Integration Directory.

 It provides a complete and consistent toolset to set up, configure and test integration scenarios in your landscape.

 AEX provides only a restricted functional range as compared with SAP Net Weaver PI complete installation. In particular, you cannot test integration processes (ccBPM) with this setup.
Using AEX as fail-over system
 It gives option for transport complete integration scenarios (integration content from the ES Repository) as well as the configuration content (Integration Directory) from a productive landscape to a “fail-over landscape” based on AEX.

 This transport option is restricted to those Integration Directory objects that are supported by AEX, for example integrated configurations.

In NWA navigate to the below path: Configuration –> Infrastructure —-> Application Resources

Enter “inboundRA” in the Resource Name and click on filter icon Select Resource Adapter, inboundRA

Click on “Properties” Enter a value for “MaxReaderThreadCount” between 5 to 10 Enter “true” for Local

XI_IDOC_DEFAULT_PIDEV, PIDEV refers to the PI system ID.
The ProgramID visible here, XI_IDOC_DEFAULT_ PIDEV, must be used when creating the RFC destination of type T on the ECC system shown belo
Integrated Configurations
Primarily the objective of using the local processing in the AAE is to improve the performance of the message processing by eliminating the need for the ABAP stack. By doing this, we can still keep the existing monitoring and support functionalities. We make Integration Configurations instead of the Configuration Scenarios that are generally made. By doing this, the number of hits to the IS are reduced and the performance improved by around four folds.
The AAE local message processing provides all the features of the message processing done using the Integration Engine but here only one Persistence step is done, against four in the latter scenario. So the Performance is improved considerably.
As we can see that the Integration Server step is missed out, leading to a 3 fold improvement, basically three steps, persistence, Transfer and parsing are skipped. Also skipped is the routing step, basically because the Integration Configuration object contains all the steps inside itself.
Using Integrated Configuration you can specify the complete configuration settings for the clear exchange of a message in one single object. This object replaces the ‘classic’ configuration objects (sender agreement, receiver determination, interface determination, and receiver agreements). The Integrated Configuration supports elementary communication scenarios for which the message receiver is already defined at the time of configuration and whose message processing only requires a simple mapping (multiplicity 1:1).
You cannot configure additional communication scenarios that contain, for example payload-based routing or a message split, with Integrated Configuration. You must define separate receiver determinations, interface determinations, and communication agreements to configure communication scenarios of this type. You can only use Integrated Configuration to set up communication scenarios where the message is only to be transferred within an Adapter Engine from a sender to a receiver adapter. Upon activation the “Integrated Configuration” is replicated to the AAEs local caches. That means that all the routings and mappings are executed locally.
SAP Process Integration – Roadmap and Future Direction -> PO:
The only major feature missing on an AEX is supporting integration processes. On PI dual-stack, this is addressed by ccBPM which runs on top of the ABAP stack, and hence is not available on a Java-only server. Moving forward on the Single stack option, SAP has introduced Process Orchestration (PO) which is a co-installation of the AEX and BPM/BRM usage types. In the long term, the PO will become our integrated stack offering where you can run any kind of scenarios, let it be stateless message processing, stateful so called integration-centric processes or human-centric processes.
SAP NetWeaver Process Orchestration combines the power of SAP NetWeaver Business Process Management, SAP NetWeaver Process Integration on AEX and SAP NetWeaver Business Rules Management into one integrated offering. Integrated Configurations are further enhanced by integration Flows built and deployed using eclipse based editors in Process Orchestration. Figure below illustrates iflow in eclipse.
You can immediately identify…
 Who is the sender?  Which interface is being sent?  Via which channel is the sender communicating?  Who are the receivers of the message and which interfaces do they expect?  Via which channels are the receivers communicating?  How is the data mapped in case the messages are different?
The SAP Process Integration Runtime perspective allows you to directly navigate into the respective monitoring environments of PI such as message monitoring and channel monitoring. SAP NetWeaver Process Orchestration also support SAP’s overarching strategy in regards to HANA and cloud

1 Comment

Leave a Reply

Your email address will not be published.