Scribd
Upload
12 views2 pages

RFC+notes (2)

The document outlines different types of Remote Function Calls (RFC) in SAP: synchronous RFC (sRFC), asynchronous RFC (aRFC), transactional RFC (tRFC), queued RFC (qRFC), and background RFC (bgRFC). sRFC requires both systems to be available during the call, while aRFC allows for non-blocking calls but still requires the called system to be available. tRFC and qRFC provide asynchronous communication with tRFC storing calls for later execution and qRFC ensuring the order of transactions, with bgRFC offering enhanced performance and functionality.

Uploaded by

greeshmakuderu2
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
12 views2 pages

RFC+notes (2)

The document outlines different types of Remote Function Calls (RFC) in SAP: synchronous RFC (sRFC), asynchronous RFC (aRFC), transactional RFC (tRFC), queued RFC (qRFC), and background RFC (bgRFC). sRFC requires both systems to be available during the call, while aRFC allows for non-blocking calls but still requires the called system to be available. tRFC and qRFC provide asynchronous communication with tRFC storing calls for later execution and qRFC ensuring the order of transactions, with bgRFC offering enhanced performance and functionality.

Uploaded by

greeshmakuderu2
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 2

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.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy