Communication between applications of different systems in the SAP environment includes connections between SAP systems as well as between SAP systems and non-SAP systems. Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. RFC calls a function to be executed in a remote system.
There is now a whole series of different RFC variants, each of which has different properties and is used for a specific purpose.
The first version of RFC is synchronous RFC (sRFC). This type of RFC executes the function call based on synchronous communication, meaning that the systems involved must both be available at the time the call is made.
Despite its name, aRFC is not really an asynchronous type of communication, as it does not meet the conditions for this. With sRFC, for example, the called system must be available during the call.
The main characteristics of aRFC are as follows:
Function control returns to the calling program directly after the call.
The parameters of asynchronous RFCs are not logged to the database, but sent directly to the server.
Asynchronous RFCs allow the user to carry on an interactive dialog with the remote system.
When the caller starts an aRFC, the called server must be available to accept the request.
The calling program can receive results from the asynchronous RFC.
Using aRFC is always a good idea when real-time communication is established with a remote system, where processing in the calling program should not be interrupted until the results of the called function module have been obtained (the term asynchronous is used in this sense here).
Transactional RFC (tRFC, previously known as asynchronous RFC) is a genuine asynchronous communication method that – unlike aRFC - executes the called function module just once in the RFC server. The remote system need not be available at the time when the RFC client program is executing a tRFC. The tRFC component stores the called RFC function, together with the corresponding data, in the SAP database under a unique transaction ID (TID).
If a call is sent, and the receiving system is down, the call remains in the local queue until a later time. The calling dialog program can proceed without waiting to see whether or not the remote call was successful. If the receiving system does not become active within a certain amount of time, the call is scheduled to run in batch.
tRFC is always used if a function is executed as a Logical Unit of Work (LUW). Within a LUW, all calls are
executed in the order in which they are called
executed in the same program context in the target system
are executed in a single transaction: they are either committed or rolled back as a unit.
Implementation of tRFC is recommended if you want to maintain the transactional sequence of the calls.
tRFC processes all LUWs independently of one another. Due to the amount of activated tRFC processes, this procedure can reduce performance significantly in both the send and the target systems.
In addition, the sequence of LUWs defined in the application cannot be kept. It is therefore impossible to guarantee that the transactions will be executed in the sequence dictated by the application. The only thing that can be guaranteed is that all LUWs are transferred sooner or later.
To guarantee that multiple LUWs are processed in the order specified by the application, tRFC can be serialized using queues (inbound and outbound queues). This type of RFC is called queued RFC (qRFC).
qRFC is therefore an extension of tRFC. It transfers an LUW (transaction) only if it has no predecessors (based on the sequence defined in different application programs) in the participating queues.
Implementation of qRFC is recommended if you want to guarantee that several transactions are processed in a predefined order.
bgRFC is the successor to tRFC and qRFC, with significant improvements in terms of performance and functionality.
Note
Using bgRFC instead of tRFC and qRFC is therefore urgently recommended.
The LDQ is a special case in RFC communication. Here, no data is sent actively by the system. Instead, it is stored locally until being called by an external application (such as a mobile device) according to the pull principle.
Note
All asynchronous RFC procedures (tRFC, qRFC, bgRFC, LDQ) form part of the Background Communication concept. As these procedures have certain characteristics that set them apart from “normal“ RFC, they are described in detail separately.
All RFC types are transferred by means of CPI-C or TCP/IP. They constitute a kind of gateway communication.
Caution
For information security-relevant aspects of communication with RFC, see the RFC/ICF Implementation Guide.
RFC Programming in ABAP
The RFC API