RFC Variants

Synchronous RFC

1. CALL FUNCTION func DESTINATION dest parameter_list .

Synchronous RFC (sRFC) performs a function call directly and waits for the reply from the called function module. The data is not written to the database before the call. When using synchronous RFC, the called system must therefore be available. The call is only made once. If the called system is not available or problems occur, the call fails (service property: At Most Once).

Asynchronous RFC

2. CALL FUNCTION func STARTING NEW TASK task [DESTINATION {dest|{IN GROUP {group|DEFAULT}}}] parameter_list [{PERFORMING subr}|{CALLING meth} ON END OF TASK]. Despite its name, asynchronous RFC (aRFC) does not actually entail asynchronous function calls in the strict sense of the word. Although the function check returns to the calling program directly after the call, the data is not actually written to the database. The call can therefore only take place on a directly available system.

If the called system is not available, the call fails. Like the sRFC, the aRFC also only has service property At Most Once.

Background RFC

3. CALL FUNCTION func IN BACKGROUND UNIT parameter_list.

Unlike the aRFC, the background RFC (bgRFC) can be termed a "genuine" asynchronous communication method, which performs the function module called in the RFC server exactly one time (service property: Exactly Once). Exactly Once). The remote system need not be available at the time when the RFC client program is executing a bgRFC. The bgRFC 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.

bgRFC is always used if a function is executed as a Unit. Within a given unit, all calls:

1. executed in the order in which they are called

2. executed in the same program context in the target system

3. are executed in a single transaction: they are either committed or rolled back as a unit.

Using bgRFC is always recommended if you want to maintain the transactional sequence of the calls in a unit. bgRFC can be either transactional (type T) or queued (type Q). When using type Q, units belonging to multiple calls are also sent and processed in exactly the sequence in which they were written to the database.

Transactional RFC

4. CALL FUNCTION func IN BACKGROUND TASK [DESTINATION dest] parameter_list [AS SEPARATE UNIT].

Transactional RFC is the predecessor of bgRFC for transactional RFC calls. It has the same service properties as bgRFC. tRFC can still be used in exactly the same way as bgRFC. However, it is not possible to use the two methods in parallel.

Queued RFC

queued RFC (qRFC) is the predecessor of bgRFC type Q. qRFC also allows you to fix the processing sequence. The technology behind qRFC is based on tRFC. The only difference is that function module TRFC_SET_QUEUE_NAME is executed before the actual tRFC call. This function module makes it possible to serialize using queues.