qRFC With Send Queue: Overview (SAP Library

qRFC With Send Queue: Overview

This topic assumes that the processing sequence of the transactions is defined in the application program and that more than one queue can be used for one transaction.

Characteristics

The characteristics of qRFC with send queue are:

Queued RFC with send queue enforces a serialization on the side of the send system. The target system has no information about the serialization in the send system. This allows communication with any R/3 target system as of Release 3.0.

qRFC with send queue is an enhancement of tRFC. It transfers an LUW (transaction) only if it has no predecessors (in reference to the sequence defined in different application programs) in the participating queues. In addition, after executing a qRFC transaction, the system tries to start all waiting qRFC transactions automatically according to the sequence.

For queue administration, the system needs a queue name and a queue counter for each qRFC transaction. Each tRFC call to be serialized is assigned to a queue name that can be determined by the application. The application passes the queue name with the call of function module TRFC_SET_QUEUE_NAME. This function module is called immediately before each tRFC call to be serialized. See also Programming Serialization.
A queue name is a text of up to 24 bytes length. You can choose any text, but you must not use * (asterisk).

You should start queue names with your application initials to prevent different applications from using the same names unintentionally (for example, SFA_… or APO_…).

There is no queue configuration, since this is a logical queue. There are no separate tables for the individual queues. For an R/3 system, there is only one table for the send queues. All entries for queues of all participating LUWs are stored in the queue table TRFCQOUT.
If the tRFC calls to be serialized are distributed to several destinations, the system bundles them per destination and processes them independent of one another. This results in sub LUWs within one LUW, as known from the old tRFC. In this case, there is no guarantee that the sequence of the sub LUWs is kept; the only guarantee is that all sub LUWs are processed sooner or later. In contrast to the old tRFC, each sub LUW receives its own transaction ID for easier queue handling.
The sequence of the tRFC calls to be serialized with or without the option AS SEPARATE UNIT within one LUW is guaranteed, even if the calls are assigned to different queues.
When sending the COMMIT WORK, the system determines a counter that acts as criterion for the sequence of LUW processing in a queue. For two LUWs that are interdependent from the application's point of view, a COMMIT WORK for the second LUW can be executed only after the COMMIT WORK for the first LUW has been terminated.
"Mixed mode" is supported: One LUW can contain normal tRFC calls as well as tRFC calls to be serialized, with ot without the addition AS SEPARATE UNIT. The sequence of the tRFC calls is guaranteed.

The "normal" tRFC calls within an LUW in "mixed mode" and the tRFC calls to be serialized that share the same destination form a sub LUW in reference to their assignment. If within one LUW no qRFC call was defined for a certain destination, the "normal" tRFC calls form a sub LUW by themselves.

In the old tRFC, all calls with different destinations are assigned to a common transaction ID, but internally to different sub LUWs. For the new tRFC, however, each bundle of tRFC/qRFC calls with the same destination receives its own transaction ID for better queue handling. For compatibility reasons, an application must first of all call function module TRFC_QUEUE_INITIALIZE if it uses "mixed mode" within an LUW and if the first call is a tRFC call. See also Using "Mixed Mode".

The "normal separate" tRFC calls (with addition AS SEPARATE UNIT) within an LUW in "mixed mode" are treated as before (individual transaction ID).

The "separate" tRFC calls to be serialized are processed depending on the queue, but independent of the actual LUW.

A side effect and advantage of qRFC with send queue compared to the old tRFC is the minimum load the serialization bears on send and target systems (due to low parallelizing). However, choosing queue names carelessly (using too many names) can neutralize this advantage.
This is a classical dilemma: Better performance due to more serialization versus faster processing due to more parallelizing. Therefore, each application must carefully weigh up how to define queue names usefully and how to assign them to the individual function calls.

Which Problems Can Occur?

Note the following general serialization problems:

If, for example, due to network/communication problems the first LUW in a queue cannot be executed, not only this queue keeps pending, but also all other LUWs that are interdependent with this queue. The resulting "jam" could cause a database problem.
However, as soon as the communication problem is solved, all transactions and thus all queues can be processed automatically one after the other.