First let us have a look at the XI and PI architecture prior to release 7.1. From a
Inside the Java stack, we had the Adapter Engine and the mapping runtime environment.
On the Adapter Engine, we had the Adapters (like RFC, FILE, JDBC, JMS, etc…), the Module Processors and the messaging system.
On the ABAP stack, we had the Integration Engine and the Business Process Engine. Inside the Integration Engine we had the Pipeline Services, the message queues and a few adapters.
Figure 105: SAP NetWeaver PI Architecture in Detail – Prior to 7.1
2008 © 2008 SAP AG. All rights reserved.
135
A typical message flow in the architecture version described above was looking like the following.
1. The message arrives at the sender adapter where it is parsed.
2. Then it is sent to the module processor.
3. he message goes to the messaging system, where it is persisted.
4. Later, the message is transmitted to the Integration Engine (therefore it has to be transformed into XML format, replicated, authenticated, and parsed again).
5. Then, the message is logically routed to the destinations and persisted again.
6. For every destination, the message is mapped (usually executing a JCO call to the Java stack).
7. Then, the XI adapter starts the transmission back to the Adapter Engine executing all the internal steps from above.
8. After that, the module processor takes action again and finally it is sent to the receiver adapter and to the target system.
Figure 106: Classical Message Processing in Detail
In the new PI 7.1 architecture, routing and mapping functionalities have been added to the Advanced Adapter Engine, which makes it possible to execute end-to-end scenarios just there on the JAVA stack, without having to go over
Figure 107: SAP NetWeaver PI 7.1 Architecture in Detail
Now we look at a typical message flow, using the local processing functionalities of the Advanced Adapter Engine.
1. The message arrives at the Sender Adapter where it is parsed.
2. Then, it is sent to the module processor.
3. Then, the message is logically routed to the destinations.
4. Subsequently, it goes to the messaging system, where it is persisted.
5. For the destination, the message is mapped locally in the Java stack.
6. After that, the module processor takes action again.
7. Finally, it is sent to the receiver adapter and to the target system.
Compared to classical processing, there is a significant reduction in the number of steps that have to be executed. Many internal latency-producing steps are removed.
2008 © 2008 SAP AG. All rights reserved.
137
Figure 108: New Message Processing Capability – Processing takes place entirely on Advanced Adapter Engine
The new features introduced with the Advanced Adapter Engine include:
• Perform end-to-end message processing without any help from the Integration Engine.
• Increase in message processing speed and throughput by reducing latencies and resource consumption (both memory and processing time).
• Local processing is probably most feasible for existing Java-based adapters, and it delivers an improvement in performance and resource usage.
Features of the AAE:
• Supports synchronous and asynchronous messages
• Supports Non-central Adapter Engines
• All Java-based adapters already in use are supported, in the future some other adapters will be supported as well
• Integration processes (ccPBM) are not supported
• Normal one-to-one Java-based mapping types
• Static routing
In upcoming enhancement packages, additional functionality will be added, such as IDoc and Web services adapters on the JAVA stack, further adapter availability
Also, you can use the Runtime Workbench or the forthcoming SAP NetWeaver Administrator to monitor the messages (RWB→ Message Monitoring). Of course, the ABAP based transaction SXMB_MONI won’t be able to show messages residing on the Java part.
Figure 109: Advanced Adapter Engine Scope – Monitoring the Messages in RWB
Other features that are already included in the AAE are sequence mappings in the operations mappings, access control lists, lookups, principal propagation, value mappings, XML schema validations, header mappings, and virtual receivers.
2008 © 2008 SAP AG. All rights reserved.
139
Figure 110: Advanced Adapter Engine Scope – Further Features
The system has to be configured to do the local processing in the AAE instead of going through the integration engine. Automatic detection is not supported.
At configuration time, instead of creating a Sender Agreement, Receiver Determination, Interface Determination and Receiver Agreement, you have to create an “Integrated Configuration” object, formerly referred to as “all-in-one”
configuration.
Figure 111: Integrated Configurations
The “Integrated Configurations” object divides all the required configurations into three tab strips.
• Sender Connectivity: Basically corresponds to the “Sender Agreement”.
• Routing and Mapping: It comprises the “Receiver Determination” and
“Interface Mapping” objects.
• Receiver Connectivity: Basically corresponds to the “Receiver Agreement”.
Upon activation, the “Integrated Configuration” is replicated to the AAEs local caches. That means that all the routings and mappings are executed locally, so there is no need to read the Integration Engine cache either.
2008 © 2008 SAP AG. All rights reserved.
141
Figure 112: Integrated Configuration in Detail
During preliminary performance testing sessions, with a SOAP-to-SOAP scenario processing small 8Kb messages, it was possible to boost message processing throughput up to 10 times, evidently increasing message processing speed with the help of the local processing in the AAE.
Figure 113: Throughput Comparison Analysis for Local Processing in the AAE
Summary of Advanced Adapter Engine Features:
• Increase in Message Processing speed (improved response time) and throughput.
• Reduces resource consumption.
• Supports Synchronous and Asynchronous Messages.
• Sender and receiver adapters located on the same Adapter Engine, Non-central Adapter Engines are also supported.
• Available for adapter types hosted on the Adapter Engine only