RFC Types In ABAP!

---------------------------------------------------------------------------------------------------------------------------------------------
Synchronous RFC

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.
Asynchronous RFC (aRFC)

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)

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.

Disadvantages of tRFC

• 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.

Queued RFC (qRFC)

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.

Background RFC (bgRFC)

bgRFC is the successor to tRFC and qRFC, with significant improvements in terms of performance and functionality.

---------------------------------------------------------------------------------------------------------------------------------------

Synchronous RFC

·   CALL FUNCTION-DESTINATION (synchronous RFC)
If the addition DESTINATION is specified without one of the following two additions, the calling program waits until the remotely-called function has finished.

    CALL FUNCTION func 

                DESTINATION dest 

                  parameter_list.  ( import , export, tables & exceptions ).

Asynchronous RFC

CALL FUNCTION-STARTING NEW TASK (asynchronous RFC, aRFC)
With the addition STARTING NEW TASK, the processing of the calling program is continued as soon as the remotely-called function is started, without waiting for it to end. The results can be obtained from callback routines.

CALL FUNCTION func STARTING NEW TASK task
                [DESTINATION {dest|{IN GROUP {group|DEFAULT}}}]
                parameter_list ( import , export, tables & exceptions )
                [{PERFORMING subr}|{CALLING meth} ON END OF TASK]. 

Transactional RFC
CALL FUNCTION-IN BACKGROUND TASK (transactional RFC, tRFC)
With the addition IN BACKGROUND TASK, the remotely-called function is marked for execution and is started using the statement COMMIT WORK.

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

Queued RFC
qRFC is an enhancement of tRFC. Inbound and outbound queues are added to the tRFC, leaving us with a qRFC (queued Remote Function Call)

 tRFC

This type 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. The 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.

 qRFC with outbound queue

In this type 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.

 qRFC with inbound queue (and outbound queue)

In this type  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.

-------------------------------------------------------------------------------------------------------------------------------------------------