Skip to Content

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

communication.

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.

image

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

disrupted.

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.

image

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.

image

!https://weblogs.sdn.sap.com/weblogs/images/45941/qdgm32.jpg|height=213|alt=image|width=489|src=https://weblogs.sdn.sap.com/weblogs/images/45941/qdgm32.jpg|border=0!

image

image

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

inbound queues as –

image

image

EO_OUTBOUND_PARALLEL = 10

Receiver System = RCV_SYS

Encrypted name =H___

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

image

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.

To report this post you need to login first.

13 Comments

You must be Logged on to comment or reply to a post.

  1. Christian Rau
    Hi,

    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???

    Regards,
    Christian

    (0) 
    1. Rene Pilz
      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 🙂

      Regards
      Rene

      (0) 
  2. Aarthi Vijayaraghavan
    Hi
    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.
    (0) 

Leave a Reply