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
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.
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.
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 –
EO_OUTBOUND_PARALLEL = 10
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.
New NetWeaver Information at SAP.com
Very Helpfull