From SAP NetWeaver PI 7.1 on you can configure scenarios that only run on the Java stack using the Advance Adapter Engine (AAE) when only Java-based adapters are used. A new configuration object is used for this that is called Integrated Configuration. When using this, the steps executed so far in the ABAP pipeline (Receiver Determination, Interface Determination and Mapping) are also executed by the services in the Adapter Engine.
6.4.1 General performance gain when using Java only scenarios
The major advantage of AAE processing is a reduced overhead due to the context switches between ABAP and Java. Thus, the overall throughput can be increased significantly and the overall latency of a PI
message can be reduced greatly. If possible, interfaces should always use the Integrated Configuration to achieve best performance. Therefore, the best tuning option is to change a scenario that is using Java based sender and receiver adapters from a classical ABAP-based scenario to an AAE-based one.
Based on SAP internal measurements performed on 7.1 releases the throughput as well as the response time could be improved significantly as shown in the diagrams below.
Based on these measurements the following statements can be made:
1) Significant performance improvements can be achieved always with local processing (if available) for a certain scenario.
2) This is valid for all adapter types; huge mapping runtimes, slow networks, slow (receiver) applications reduce the throughput and therefore, rated for the overall scenario, also reduce the benefit of local processing in terms of overall throughput and response time measurements.
3) Greatest benefit is recognized for small payloads (comparison: 10k, 50k, 500k) and asynchronous messages.
6.4.2 Message Flow of Java only scenarios
All the Java based tuning options mentioned in chapter Analyzing the (Advanced) Adapter Engine and Long Processing Times for “PLSRV_MAPPING_REQUEST” are still valid. Just the calling sequence is different.
The following describes the steps used in Integrated Configuration to help you better understand the message flow of an interface. The example is JMS to Mail:
1) Enter the JMS sender adapter
2) Put into the dispatcher queue of the messaging system 3) Forwarded to the JMS send queue of the messaging system 4) Message is taken by JMS send consumer thread:
a. No message split used:
In this case, the JMS consumer thread will do all the necessary steps previously done in the ABAP pipeline (like receiver determination, interface determination, and mapping) and will then also transfer the message to the backend system (remote database, in our example). Thus, all the steps are executed by one thread only.
b. Message split used (1:n message relation):
In this case there is a context switch. The thread taking the message out of the queue will process the message up to the message split step. It will create the new message and put it in the Send queue again from where it will be taken by different threads (which will then map the child message and finally send it to the receiving system)
As we can see in this example for Integrated Configuration, only one thread does all the different steps of a message. The consumer thread will not be available for other messages during the execution of these steps.
The tuning of the Send queue (Call for synchronous messages) is therefore much more important for scenarios using Integrated Configuration than for ABAP-based scenarios.
The different steps of the message processing can be seen in the audit log of a message. If, for example, a long-running mapping or adapter module is indicated, then you can use the relevant chapter of this guide.
There is no difference in the analysis except that for mappings no JCo connection is required since the mapping call is done directly from the Java stack.
The example audit logs below are based on a Java only synchronous SOAP to SOAP scenario.
In the highlighted areas you can see that all the steps are very fast except the mapping call which lasts around 7 seconds. To analyze the long duration of the mapping now the same steps as discussed in chapter Long Processing Times for “PLSRV_MAPPING_REQUEST” have to be followed.
6.4.3 Avoid blocking of Java only scenarios
Like classical ABAP based scenarios, Java only scenarios can face backlog situations in case of a slow or hanging receiver backend. Since the Java only interfaces are only using send queues the restriction of consumer threads on the receiver queue as described in chapter Avoid Blocking Caused by Single Slow/Hanging Receiver Interface is no solution.
Based on that an additional property messaging.system.queueParallelism.queueTypes of service SAP XI AF MESSAGING was introduced via Note 1493502 - Max Receiver Parameter for Integrated Configurations.
The parameter can be set for synchronous and asynchronous interfaces. Please keep in mind that messaging.system.queueParallelism.maxReceivers is a global parameter for all adapters and for all configured Quality of Service. This global restriction can be avoided starting with 7.31 SP11/ 7.40 SP06, as per SAP Note 1916598 - *NF* Receiver Parallelism per Interface. Usually a restriction for the parallelization can be highly critical for synchronous interfaces. Therefore we generally recommend to set
messaging.system.queueParallelism.queueTypes in most cases to Recv, IcoAsync only.
6.4.4 Logging / Staging on the AAE (PI 7.3 and higher)
Up to PI 7.11 on the PI Adapter Engine only one message version was persisted. Especially for Java only scenarios this was often not sufficient for troubleshooting since for instance the result of a mapping could not be verified.
Starting from PI 7.3 the persistence steps can be configured globally in the Adapter Engine for synchronous and asynchronous interfaces. This is similar to the LOGGING or LOGGING_SYNC on the ABAP stack. In later version of PI you will be able to do the configuration on interface level.
The versions that can be persisted are shown in the diagram below (the abbreviations in green are the values for the configuration):
In the Messaging System we generally distinguish Staging (versioning) and Logging. An overview is given below:
For details about the configuration please refer to the SAP online help Saving Message Versions.
Similar to the LOGGING on the ABAP Integration Server, persisting several versions of the Java message can cause a high overhead on the DB and can cause a decrease in performance.
The persistence steps can be seen directly in the audit log of a message:
Also the Message Monitor shows the persisted versions:
While this additional monitoring attributes are extremely helpful for troubleshooting they should be used carefully from a performance perspective. Especially the number of message versions and the
logging/staging mode you choose can have a severe impact on performance. Therefore you have to find the balance between business requirement and performance overhead. Some guidelines on how to use staging and logging are summarized in SAP Note 1760915 - FAQ: Staging and Logging in PI 7.3 and higher.