Solved: how many types of rfcs are there

Former Member · ‎04-19-2007

Hello,

Can any body explain about how many type of rfcs are there. give the difference also.

Thanks.

Former Member · ‎04-19-2007

Hi,

Check this info.

These are the types of RFC

Asynchronous RFC (aRFC)

Synchronous RFC (sRFC)

Transactional RFC (tRFC)

Queued RFC (qRFC)

Parallel RFC (pRFC)

Asynchronous RFC :

This is used when you need to increase the performance of ABAP program by having system call more than one function module in parallel than forcing the program to wait for results .

Transactional RFC

This let you group one or more function module call together o tRFC LUW and ensure that fucnction module within LUW is called once . In contrast to aRFC and sRFC the tRFC belonging to tRFC LUW are executed in order .

tRFC is always used if a function is executed as a Logical Unit of Work (LUW). Within a LUW, all calls are

1.Executed in the order in which they are called

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

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

Asynchronous remote function calls (aRFCs) are similar to transactional RFCs, in that the user does not have to wait for their completion before continuing the calling dialog. There are three characteristics, however, that distinguish asynchronous RFCs from transactional RFCs:

• When the caller starts an asynchronous RFC, the called server must be available to accept the request.

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.

• The calling program can receive results from the asynchronous RFC.

You can use asynchronous remote function calls whenever you need to establish communication with a remote system, but do not want to wait for the function’s result before continuing processing. Asynchronous RFCs can also be sent to the same system. In this case, the system opens a new session (or window). You can then switch back and for between the calling dialog and the called session

RECEIVE RESULTS FROM FUNCTION Remotefunction is used within a FORM routine to receive the results of an asynchronous remote function call. The following receiving parameters are available:

IMPORTING

TABLES

EXCEPTIONS

The addition KEEPING TASK prevents an asynchronous connection from being closed after receiving the results of the processing. The relevant remote context (roll area) is kept for re-use until the caller terminates the connection.

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.

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.

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

Therefore, Queued RFC is better than Transactional RFC.

Remote Function Call:

RFC is an SAP interface protocol. Based on CPI-C, it considerably simplifies the programming of communication processes between systems.

RFCs enable you to call and execute predefined functions in a remote system - or even in the same system.

RFCs manage the communication process, parameter transfer and error handling.

http://help.sap.com/saphelp_47x200/helpdata/en/22/042860488911d189490000e829fbbd/frameset.htm.

Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. The RFC calls a function to be executed in a remote system.

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) 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

For more information on RFC, please go through the link.

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

Have a look at this link.

http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCFESDE2/BCFESDE2.pdf

http://help.sap.com/saphelp_47x200/helpdata/en/22/042860488911d189490000e829fbbd/frameset.htm.

Rewords some points.

Rgds,

P.Nag

Former Member · ‎04-19-2007

Hi ,