RFC

[Former Member]

Hi,

what is the difference between Synchronous and asynchrnous RFC and what is transactional RFC?

Thanks

[former_member404244]

hI,

HAVE a look at the below links..

http://help.sap.com/saphelp_nw04/helpdata/en/6f/1bd5b6a85b11d6b28500508b5d5211/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/22/04280f488911d189490000e829fbbd/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/22/0424ba488911d189490000e829fbbd/content.htm

Regards,

Nagaraj

[Former Member]

Hi,

RFC:

RFCs are requests that an SAP component sends to invoke functions on remote systems, or calls that remote systems initiate to invoke functions on an SAP component.A process that can accept RFCs from SAP components. This allows SAP components to access functions in external systems. In SAP BC terminology, the process is called a Listener. Listeners are one or more threads on SAP Business Connector that wait for incoming requests from SAP components. Listeners are named and register with an SAP gateway to indicate that they are ready to accept requests. Listeners can accept RFC or tRFC requests.

Transactional RFC (tRFC) and Queued RFC (qRFC). tRFC is used mainly to transfer ALE Intermediate Documents (IDocs).

Transactional RFC:

If an error occurs during a synchronous remote function call, the system cannot tell at what point the error occurred (most crucially, whether the function module was actually processed in R/3 before the operation failed). Restarting a failed call is therefore a dangerous thing to do, since you risk duplicating a completed function call.

To alleviate this problem, you can use transactional RFC, which guarantees that each function call you issue will only be executed once, even if you submit it repeatedly to the R/3 System. The system implements this safeguard by assigning a unique transaction ID (TID) to each transaction that you submit. When you attempt to process the transaction, the system checks whether that TID has already been processed. If it has, the transaction is ignored.

Queued RFC:

When you use transactional RFC, you cannot guarantee the order in which the function calls will be processed in the system (it is quite possible that one call might overtake another). For cases where you need to specify a particular processing order, you can use queued RFC, which is an extension of transactional RFC. In qRFC, you place each function call in a logical queue. A function call cannot be executed until all of its predecessors in the queue have been processed. Queued RFC calls are processed asynchronously.

and check this doc.

Synchronous RFC

The first version of RFC is synchronous RFC (sRFC). This type of RFC executes the function call based on synchronous communication, which means that the systems involved must both be available at the time the call is made.

Transactional RFC (tRFC)

Transactional RFC (tRFC, also originally known as asynchronous RFC) is an asynchronous communication method that executes the called function module in the RFC server only once. 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

· run as a single transaction: they are either committed or rolled back as a unit.

Implementation of tRFC is recommended if you want to guarantee that the transactional order of the calls is preserved.

Disadvantages of tRFC

· tRFC processes all LUWs independent 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. Therefore, there is no guarantee that the transactions are executed in the sequence dictated by the application. The only guarantee is that all LUWs are transferred sooner or later.

rewards points if it is useful

[gopi_narendra]

A Asynchronous updating. In this mode, the called transaction does not wait for any updates it produces to be completed. It simply passes the updates to the SAP update service. Asynchronous processing therefore usually results in faster execution of your data transfer program.

S Synchronous updating. In this mode, the called transaction waits for any updates that it produces to be completed. Execution is slower than with asynchronous updating because called transactions wait for updating to be completed. However, the called transaction is able to return any update error message that occurs to your program. It is much easier for you to analyze and recover from errors

Regards

Gopi