Skip to Content
avatar image
Former Member

A few questions on the SAP PI Messaging System when AAE has been used

Hi Gurus,

We are using SAP PI 7.4 Dual Stack system and ICO has been used for all the integration scenarios, which means we are using just the advance adapter engine in JAVA stack . The ABAP integration engine has not been used.

Let's take an example. Say SAP sends an IDOC to PI and PI forwards the message to a third party system after mapping via a REST receiver adapter.

This is the process steps as in my understanding in PI:

1. Message has been pushed to the IDOC_AAE sender adapter;
2. Message has been processed by the module processor;
3. Message has been put to Messaging system and been persistent in DB;
4. Message has been put into the dispatcher queue;
5. Message has been picked up from dispatcher queue and put to the IDOC_AAE send queue(asynchronous sender);
6. Determine the receiver via the definition in ICO;
7. Determine the receiver interface via the definition in ICO;
8. Execute mapping program and get the target message;
9. Message has been put to the REST Receiver adapter from the IDOC_AAE send queue(only sender adapter queue will be used in AAE);

If my understanding is correct, i have the these bellowing questions:
1. About the Message Prioritization.
When this prioritization occurs? Normally we just have one thread for dispatcher queue. it means all messages will be queue up in that queue. we know that the definition of Message Priority is based on interface level, rather than adapter level and we know that by defaul, HIGH stands for 75% of resource, NORMAL(or no configuration) stands for 20% of resource and LOW stands for 5% of resource. Then what does this 'resource' mean here? The number of threads of the adapter specifiy queues? I do not think so. Because the threads belong to certain adpater specific queues and the max number of threads per these queues has already been configured in XPI Service: Core. On the other hand, if the messages have been queued up regardless of its interface, how can it cut the line according to the priority defined?

For example: message type: IDOC_A has been defined as HIGH prority and message type: IDOC_B has been defined as LOW prority. we have 1 IDOC_A message sent out right after 100 IDOC_B has been sent to PI.
step 1, they will be put into the dispatcher queue with IDOC_A message in the last place. Since there is only thread, IDOC_A will be put to the IDOC_AAE queue after all 100 IDOC_B be put into IDOC_AAE queue.
step 2, by default there are maximium 5 threads for IDOC_AAE queues. if the target system is a bit slow, all of the 5 queues can be used at this moment.
Then obviously IDOC_A should be the last one in one of these 5 queues. Since in AAE, there is only sender queue used, i cannot see any possibility that it can cut the line from its HIGH prority until it has been put to the REST receiver adapter.

Then the question is:
what does this 'resource' mean here? is it inside the adapter specific queue? when it will be consumed in PI or when the defined priority will be taken into consideration?

2. About 'wait time in the dispatcher queue' in the performance monitor
let's take the example as above.

An IDOC has been sent to PI AAE and been forwarded to a third party system via REST receiver adapter.
For scenario like that, we will get two records in the performance monitor. One is for the outbound IDOC message and the other is for the inbound REST message.
what confuse me is, for both messages, you will find a figure for 'MS:Message_Wait_in_Disp_Queue' which very strange.

For IDOC message, it does make sense. Because it is coming from SAP and it has been put in the dispatcher queue before being picked up to IDOC_AAE queue. whereas for the inbound REST message after the mapping, i cannot understand why it has a figure for 'wait time in the dispatcher queue' here. It should have nothing to do with the dispatcher queue.

So my questions are:

Has the message after the mapping ever been put to a dispatcher queue in PI? If yes, is it another dispatcher queue or still the same one for the incoming message from sender system? if it is the same one, how can the Messaging System know that it is an incoming message from sender system or it is a message after mapping? How can they be sequenced in the queue?


Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Best Answer
    Aug 02, 2017 at 07:13 PM

    You have to remember that queues in Java are regular queues. They don't follow FIFO or EOIO. See details below.

    Queues in the Messaging System
    The queues in the Messaging System behave different then the qRFC queues in ABAP. The ABAP queues are strictly First In First Out (FIFO) queues and are only processed by one Dialog work process at a time. The Messaging System queues have a configurable amount of so called consumer threads that process messages from the queue. The default number of consumer threads is 5 per adapter (JDBC, File, JMS, …), per direction (inbound and outbound) and Quality of Service (asynchronous (EO, EOIO) and synchronous). Hence in case a message is taking very long other messages that arrived later can finish processing earlier. Therefore Messaging System queues are not strictly FIFO.

    1) When does prioritization happen?

    When moving messages from Dispatcher Queue -> Adapter Send Queue.

    From the performance doc see step 3:

    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 (based on Interface priority)
    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) Forwarded to the JDBC receive queue of the messaging system (based on Interface priority)
    10) Retrieved from the receive queue (based on the maxReceivers)
    11) Sent to the receiver adapter
    12) Sent to the final receiver.

    2) Why do I see "Wait Time" in Dispatcher Queue

    Multiple entries in performance monitor are usually because of a message split.

    If your question is about wait time in Dispatcher Queue. This is usually when the Dispatcher Queue is unable to find a Adapter Send Queue to send to. This could be because of different reasons:

    • All threads for the adapter send queue are in use
    • You have setup maximum threads for Receiver System or Receiver Interface
    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Harsh Chawla

      good finding. so the only main task inside the adapter specific queue is mapping for non-bpm scenarios. I think this topic can be closed at the moment.


  • Aug 02, 2017 at 12:26 PM

    Hi Stephen,

    In regards to your first question - I believe what will happen here is that IDOC_A will be sent using one of the IDoc send queue threads at the next available point when one of the IDOC_B transmissions has completed. By default you have 5 threads available which means that the system will process 5 messages at any single point in time. Once a single IDOC_B has been sent successfully then the system would have the opportunity to prioritize IDOC_A ahead of any remaining IDOC_B messages and you should observe 1 IDOC_A message being transmitted while 4 other IDOC_B messages are being transmitted. As for the second question the only time I have observed a second entry for the receiving interface is if I have some type of acknowledgement enabled. I don't believe anything would be placed in the dispatcher queue on the receiving side because at that point the system has already dispatched it, unless it is something such as an acknowledgement and the system is treating it like a new message.


    Ryan Crosby

    Add comment
    10|10000 characters needed characters exceeded

    • HI Stephen,

      Yes, as Harsh has already mentioned the naming choice in a data structures sense is poor as any true queue would be FIFO in observation. As far as a second message any acknowledgement or message split would begin processing through the normal sequence of steps and also need to be dispatched before it can be handled the messaging framework.


      Ryan Crosby