The qRFC Communication Model

qRFC Properties and Possible Uses

All types of applications are instructed to communicate with other applications. This communication may take place within an SAP system, with another SAP system, or with an application from a remote external system. An interface that can be used for dealing with this task is the Remote Function Call (RFC).  RFCs can be used to start applications in remote systems, and to execute particular functions.

Whereas the first version of the RFC, the synchronous RFC, (sRFC) required both systems involved to be active in order to produce a synchronous communication, the subsequent generations of RFC had a greater range of features at their disposal (such as serialization, guarantee for one-time-only execution, and that the receiver system does not have to be available). These features were further enhanced through the queued RFC with inbound/outbound queue.  

Communication between applications within an SAP system and also with a remote system can basically be achieved using the Remote Function Call (RFC). Here, the following scenarios are possible:

·         Communication between two independent SAP systems

·         Communication between a calling SAP system and an external receiving system

·         Communication between a calling external system and an SAP receiving system

The following communication model shows what these communication scenarios may look like in reality. The actual sending process is still done by the tRFC (transactional Remote Function Call). Inbound and outbound queues are added to the tRFC, leaving us with a qRFC (queued Remote Function Call). The sender system is also called the client system, while the target system corresponds to the server system.

In practice, the following three scenarios for data transfer exist:


Scenario 1: tRFC

This scenario is appropriate is the data being sent is independent of each other. A calling application (or client) in system 1 uses a tRFC connection to a called application (or server) in system 2. In this scenario, data is transferred by tRFC, meaning that each function module sent to the target system is guaranteed to be executed one time only. You cannot define the sequence in which the function modules are executed, nor the time of execution. If an error occurs during the transfer, a batch job is scheduled, which sends the function module again after 15 minutes.

Scenario 2: qRFC with outbound queue

In this scenario, the sender system uses an outbound queue, to serialize the data that is being sent. This means that function modules which depend on each other (such as update and then change) are put into the outbound queue of the sender system, and are guaranteed to be sent to the target system one after each other and one time only. The called system (server) has no knowledge of the outbound queue in the sender system (client), meaning that in this scenario, every SAP system can also communicate with a non-SAP system. (Note: the programming code of the server system must not be changed. However, it must be tRFC-capable.)

Scenario 3: qRFC with inbound queue (and outbound queue)

In this scenario, as well as an outbound queue in the sender system (client), there is also an inbound queue in the target system (server). If a qRFC with inbound queue exists, this always means that an outbound queue exists in the sender system. This guarantees the sequence and efficiently controls the resources in the client system and server system.  The inbound queue only processes as many function modules as the system resources in the target system (server) at that time allow. This prevents a server being blocked by a client. A scenario with inbound queue in the server system is not possible, since the outbound queue is needed in the client system, in order to guarantee the sequence and to prevent individual applications from blocking all work processes in the client system.

Properties of the Three Communication Types 

To help you decide which communication type you should use in your system landscape for your requirements, the advantages of the three communication types are listed below:


       1.      tRFC: for independent function modules only

       2.      qRFC with outbound queue: guarantees that independent function modules are sent one after each other and one time only (serialization). Suitable for communication with non-SAP servers.

       3.      qRFC with inbound queue: in addition to the outbound queue in the client system, an inbound queue makes sure that only as many function modules are processed in the target system (server) as the current resources allow. Client and server system must be SAP systems. One work process is used for each inbound queue.


For more detailed information, refer to the qRFC documentation under:

The qRFC Communication Model

Queued Remote Function Call (qRFC)

 To view the entire qRFC directory tree, choose Synchronize from the upper left part of the screen. You can then navigate through the entire qRFC documentation.

Using Asynchronous RFCs