Skip to Content
Author's profile photo Former Member

XI Asynchronous Message Processing: Understanding XI Queues -Part I

In a typical XI landscape, both XML and non-XML messages are exchanged between XI

and other systems in the landscape. Even within XI, XML messages float between

various application components. Integration Engine provides the runtime environment

for processing of these messages. Now the way this message is delivered by sender

system and further processed by Integration Engine is determined with the attribute

Quality of Service

. Supported QoS types are-

Synchronous Message Processing:

BE (Best Effort)

Asynchronous Message Processing:

EO (Exactly Once)

EOIO (Exactly Once In Order)

In this first blog, we’ll discuss these two types of message processing and later

role of RFC queues in asynchronous processing.

One of the major difference between synchronous (BE) and asynchronous (EO, EOIO)

message processing is in asynchronous processing, messages are persisted and

scheduled for processing. So what’s the big deal? After all, I’m sure you must have

read/heard this sentence n number of times. Trust me, it’s very interesting and

rewarding to understand how this ‘scheduling’ is achieved by Integration Engine.

Actually it uses qRFC for this. And to appreciate this mechanism, lets take a

closer look and understand the difference between synchronous and asynchronous


Synchronous Communication

In synchronous communication, there’s nothing like scheduling. Sender application

executes a ‘single’ Function call, receiver system immediately processes this

function call dispatching the response to sender and then it performs implicit

database commit.


However this communication is based on assumption that receiver system is available

when function call is made. If this is not the case, the communication is seriously


Asynchronous Communication

Here receiver system is not necessarily required to be active at the time of

function call. Instead, the call is placed in outbound queue of the sender system

and then this call is repeated at regular intervals until receiver system processes

the call.


So conclusion: Queues play central role in asynchronous communication.
Further in asynchronous communication, the calls can be executed either by tRFC

(Transactional RFC) or qRFC (Queue RFC). In tRFC, RFC calls are stored in database

along with corresponding data under a unique transaction id (TID). However in tRFC,

LUW (Logical Unit of Work) are executed independently of each other and the

sequence specified by sending application is not maintained. And this particular

requirement leads to qRFC communication wherein all LUWs are processed in the same

sequence as determined by sending application.

Ok. So lets get back to Integration Engine and find out how it asynchronously

processes XI messages. As stated above Integration Engine implements asynchronous

message processing by using qRFC (which itself is extension of tRFC).

XI Queues

So as you can make out, XI messages for inbound processing are placed in inbound

queues of Integration Engine and placing them in outbound queues carries out

outbound processing. As a part of Integration Engine configuration, we register XI

queues. By registering queues used by the Integration Engine, we intimate qRFC the

technical names of these queues. Before we proceed further, lets take a look at

different queues used by IE.





So the limit for four-digit number is 4 and Integration Server will generate 4

inbound queues as –




Receiver System = RCV_SYS

Encrypted name =H___

Total 10 queues starting from XBTOH___0000 to XBTOH____0009 will be created.


Apart from this there are other few parameters and consideration that affect the

behaviour of queues and hence your XI system. However they are more relevant from

tuning perspective and it is worth discussing it all in next blog of this series.

Stay tuned.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Nice blog..I learnt something new...
      keep blogging..


      Author's profile photo Former Member
      Former Member
      Explained really well,Makes the serializing concept in XI quite clear..
      Keep Bloggin..

      Author's profile photo Former Member
      Former Member

      interesting weblog, but you wrote:

      EOIO (Exactly Once In Order)
      In EOIO communication, sender application has specified the sequence and so as to maintain this sequence, Integration Server uses the application name provided by sender to determine sender (XBQS), receiver (XBQR) and inbound (XBQI) queues.
      So if ,
               Queue name as specified by application: POFREIGHT
               Inbound Queue Name : XBQIPOFREIGHT

      Where is that queue name coming from? You wrote specified by application!? How to do that? Is there a special idoc field available???


      Author's profile photo Former Member
      Former Member
      Hi Christian,

      As far as I've checked this issue (we have also to implement EOIO) you have nothing to do. You have just to Set an Queue-Name within the Adapter.

      And: this name need not start with XB...

      In my example, the interface belongs to data-transmission with "Ferroflex", therefore I've just set
      Quality of service: EOIO
      Queue-Name: Ferroflex.

      When monitoring this interface within TA SXMB_MONI, i can see that XI itself created the Queue XBQOG___FERROFLEX.

      Hope it helps and hope it works on my system as expected 🙂


      Author's profile photo Aarthi Vijayaraghavan
      Aarthi Vijayaraghavan
      a nice blog. but sitll i feel little difficult to understand the concept.
      Will a queue be created for every sender and receiver?
      Then what we need to do in configuration.
      What is the purpose of XBT_1x and XBT_9x queues.
      Author's profile photo Pradeep Sudhagani
      Pradeep Sudhagani
      Is there a way to tune Synchronous Calls??

      How to increase the number of parallel Sync Calls??(eg., Sync Sender SOAP request messages)

      Author's profile photo Former Member
      Former Member
      Excellent blog Youvraj. can you please let us know the links for other parts of it?


      Author's profile photo Former Member
      Former Member
      Very nice blog. Could you please give us the link to part 2 if there's any?
      Author's profile photo Former Member
      Former Member
      its very nice blog.provide other links
      Author's profile photo Sheetal Deshmukh
      Sheetal Deshmukh
      Hi , this is really very helpful blog to understand pi wueue concepts
      Author's profile photo Former Member
      Former Member
      thnx for your efforts.
      it's very helpful.
      Author's profile photo HariKumar Vemuri
      HariKumar Vemuri

      thnx for ur efforts...this blog helped me to understand queue's better... 🙂

      Author's profile photo Harish Allachervu
      Harish Allachervu

      very informative blog regarding the XML message ids processing thanks for sharing buddy..... 😐