RFC’s in SAP

 A remote function call (RFC) is the call of a function module that runs in a different system to the
calling program.
 CALL FUNCTION...DESTINATION {RFCDES table stores the destination)
 Transaction code SM59 is used to set up the destination. There are two predefined destinations
that do not have to be entered using transaction SM59:
o Destination "NONE"
 Has the effect that the function module is started on the same application
server as the calling program, however through the RFC interface and in its
own RFC context. This destination is possible for all types of call.

o Destination "BACK"

 Can be used in a function module that is called remotely, and links back to the
caller. You can only specify this in function modules that have been called
synchronously. Destination "BACK" can be used to call each remote-capable
function module of the calling system in all three execution types. For a
synchronous callback, the relevant function group is loaded into the internal
session of the calling program, if it is not yet available there. The existint RFC
connection is used for this callback.
 As well as the destinations created in transaction SM59 and the two predefined
destinations, you can also specify destinations directly, in the form
"hostname_sysid_sysnr". Here, "hostname" refers to the name of the
application server, "sysid" is the name of an SAP system, and "sysnr" is the
system number, as is displayed using transaction SM51
 Always PASS BY VALUE in case of RFC
 Exceptions:
o COMMUNICATION_FAILURE = 1 (connection cannot be made to the partner system)
o SYSTEM_FAILURE = 2 (runtime error during execution of the remotely-called function)
 Automatic authorization check is performed if a system is deemed to be non-trustworthy. Rating
of systems in done using transaction SMT1
 Data transfer
All RFC types are transferred by means of CPI-C or TCP/IP. They represent a kind of
Gateway Communication.
 RFC Context
Every remote call of a function module that is made using the RFC interface defines a
separate context in the target system. The function group of the function module is
loaded into an internal session of the context, and is retained. What this means is that, if
repeated calls of function modules belonging to the same destination and the same
function group are made, the global data of this function group can be accessed
collectively. A connection and its context is retained until it is explicitly closed, or until
the calling program is finished. To close a connection explicitly, the function
module RFC_CONNECTION_CLOSE can be used

 RFC Restrictions:-
a) For each call that is made using synchronous RFC, a database commit is performed. For
this reason, a synchronous RFC must not be used between Open SQL statements that
open or close a database cursor.

b) In a function module that is called remotely, you must not use statements that close the
current context and therefore the connection. An example of this is the statement
LEAVE PROGRAM, or SUBMIT without the addition RETURN.

c) In the case of a synchronous RFC, dynpros and selection screens that are called in a
remotely-called function module are displayed in the calling system if the calling
program is executed in dialog processing, and if the user defined in the destination has
dialog authorization. The screen data is transmitted by the RFC interface to the calling
system. In this particular case, you can display lists that are written in a remotely-called
function module by using LEAVE TO LIST-PROCESSING.

d) As only pass by value is used for the RFC, when exceptions do occur, you can never
access interim results when a synchronous RFC is made.

e) Information messages are warnings are handled in the same way as status messages.
Types of RFCs:
1. Synchronous (CALL FUNCTION - DESTINATION)

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.
If the addition DESTINATION is specified, the calling program waits until the remotely-
called function has finished
CALL FUNCTION func DESTINATION dest
parameter_list.

2. Asynchronous (CALL FUNCTION - STARTING NEW TASK)

CALL FUNCTION func STARTING NEW TASK task
[DESTINATION {dest|{IN GROUP {group|DEFAULT}}}]
parameter_list
[{PERFORMING subr}|{CALLING meth} ON END OF TASK].

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.

a. Transactional RFC (CALL FUNCTION - IN BACKGROUND TASK)

- Transactional RFC (tRFC, previously known as asynchronous RFC) is
an asynchronous communication method that 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. The calling dialog program can proceed without waiting to see
whether 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
· are executed in the same program context in the target system
· run as a single transaction: they are committed or rolled back as a unit.

- With the addition IN BACKGROUND TASK, the remotely-called function is

marked for execution and is started using the statement COMMIT WORK
 - 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.

CALL FUNCTION func IN BACKGROUND TASK

[DESTINATION dest]
parameter_list
[AS SEPARATE UNIT].

b. Queued RFC
- 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.

Synchronous Communication:

Synchronous communication uses a single function call. Prerequisite for this is that at the time the call is
made (or the message is sent), the receiving system is also active and can accept the call and further
process it if necessary.

Advantage: Synchronous communication can be implemented in function calls that require the
immediate return of data to the sender system.

Example: You create a purchase order with account assignment in the sender system, and you want to
perform a budget check in central accounting before you save the purchase order.

Disadvantage: You need to ensure that both systems are active and can be contacted. If they are not,
this can lead to serious disruption of processes. In particular, problems can arise if the receiving system
is not available for long periods of time due to maintenance (for example, for a system upgrade).
Asynchronous Communication:

For asynchronous communication, the receiving system does not necessarily have to be available at the
time a function call is dispatched from the sender system. The receiving system can receive and process
the call at a later time. If the receiving system is not available, the function call remains in the outbound
queue of the sending system, from where the call is repeated at regular intervals until it can be
processed by the receiving system.

Advantage: The receiving system does not have to be available at the time the function call is made. If
the system is unavailable for a long period of time, for example, for an upgrade, it can still process the
data that has been sent in the interim at a later time, and processes in the sending system remain
unharmed

Example: You are sending a purchase order to a vendor system. The sending system cannot influence
the availability of the receiving system. If the receiving system is not available, the purchase order can
be sent repeatedly until the vendor system is available again.

Disadvantage: Processes that require an immediate response to the sender system cannot be executed
using this method.

In asynchronous communication, you usually have the option to send data (for example, business
documents or changes to master data) in packages or individually (immediately). Note that the Send
Immediately option in asynchronous communication should not be confused with the
method synchronous communication). The advantage of sending data in packages is that system
resources are employed more efficiently, because each function call occupies one work process in the
system.
 Example: You want to distribute 100 material master changes to other systems. If you send the
changes in a package (with 100 pieces) you only require one work process. If you sent the same
100 material master changes individually, you would need 100 work processes in the system.

When using asynchronous communication, you should therefore always carefully consider the
availability of your system resources and the necessity of immediate data transfer.