PI Messaging Queues: Registration & Prioritization

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.