Wed. Feb 26th, 2020

Analyzing the Adapter Framework in SAP PI

3 min read

This blog describes checks and possible reasons for bottlenecks in the Adapter Framework. The following aspects are important to know for the analysis of a performance problem on the AFW:

  • The AFW contains the Messaging System that is responsible for the persistence and queuing of messages. Within the flow of a message, it is placed in between the sender adapter (for example, a file adapter that polls from a folder) and the Integration Server as well as between the Integration Server and the receiver adapter (for example, a JMS adapter that sends a message out to an external system).
  • In SAP NetWeaver PI 7.1, the Messaging System uses 4 queues for each adapter type and these are responsible for receiving and sending messages. To separate the message transfer, each adapter (for example, JMS, SOAP, JDBC, and so on) has its own set of queues. One queue for receiving synchronous messages (request queue), one queue for sending synchronous messages (call queue), one queue for receiving asynchronous messages (receive queue), and one queue for sending asynchronous messages (send queue). The name of the queue always states the adapter type and the queue name (for example, JMS_http://sap.com/xi/XI/SystemReceive for the JMS receiver asynchronous queues).
  • A configurable number of consumer threads are assigned on each queue. These threads work on the queue in parallel, meaning that the Messaging Queues are not strictly FirstIn-FirstOut. Five threads are assigned by default to each queue and thus five messages can be processed in parallel. But, as will be discussed later, the parallel execution of requests to the backend depends heavily on the adapter being used since not every adapter can work in parallel by default.
  • SAP NetWeaver PI 7.1 introduced a new queue: The dispatcher queue. The dispatcher queue is used to realize prioritization on the AAE. Every message in the PI system is first assigned to the dispatcher queue before it is assigned to the adapter-specific queues.

Viewed from the perspective of a message that enters the PI system using a J2EE Engine adapter (for example File) and leaves the PI system using a J2EE Engine adapter (for example, JDBC) asynchronously, the steps are as follows:
1) Enter the sender adapter
2) Put into the dispatcher queue of the messaging system
3) Forwarded to the File send queue of the messaging system
4) Retrieved from the send queue by a consumer thread
5) Sent from the messaging system to the pipeline of the ABAP Integration Engine (if no Integrated Configuration (AAE) is used
6) Processed by the pipeline steps of the Integration Engine
7) Sent to the messaging system by the Integration Engine
8) Put into the dispatcher queue of the messaging system
9) Put into the JDBC receive queue of the messaging system
10) Retrieved from the receive queue
11) Sent to the receiver adapter
12) Sent to the final receiver.

All the analysis is based on the information provided in the Audit Log. With SAP NetWeaver PI 7.1 the audit log is not persisted for successful messages in the database by default to avoid performance overhead. Therefore, the audit log is only available in the cache for a limited period of time (based on the overall message volume).

Leave a Reply

Your email address will not be published. Required fields are marked *

Instagram