Transactional RFC

Hi all

I want to learn Transactional Remote Function Call. Please provide me some material for the same, I could not find on SDN.

Any help shall be helpful




hi dinesh

<b>Transactional RFC </b>

1 This type of RFC was renamed from asynchronous to transactional RFC, because asynchronous RFC has another meaning in R/3 Systems.

2 The called function module is executed exactly once in the RFC server system. Each function call is seen as a transaction in the target system.

3 Transactional RFCs use the suffix IN BACKGROUND TASK. The remote system need not be available at the time when the RFC client program is executing a tRFC.

4 The tRFC component stores the called RFC function together with the corresponding data in the R/3 database, including a unique transaction identifier (TID).

5 If a call is sent, and the receiving system is down, the call remains in the local queue until a later time.

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

7 The system logs the remote call request in the database tables ARFCSSTATE and ARFCSDATA with all of its parameter values. You can display the log file using transaction SM58.

8 When the calling program reaches a COMMIT WORK, the remote call is forwarded to the requested system for execution.

9 Transactional RFC requests are transferred, with parameter data in byte-stream form, using TCP/IP or X400.

10 LUW's are identified by transaction ID's that are unique world-wide. The transaction ID can be determined from an ABAP program by calling function module ID_OF_BACKGROUNDTASK. (You must call this function after the first asynchronous CALL, and before the related COMMIT WORK.)

11 The system function module ARFC_DEST_SHIP transports the data to the target system and the function module ARFC_EXECUTE executes the stored function calls. If an error or an exception occurs during one of the calls, all the database operations started by the preceding calls are rolled back and an appropriate error message is written to the file ARFCSSTATE.

12 Once you have identified the ID of the LUW, you can use the function module STATUS_OF_BACKGROUNDTASK to determine the status of the transactional RFC.

13 Call transaction SM58 (Tools _ Administration _ Monitoring _ Transactional RFC). This tool lists only those transactonal RFCs that could not be carried out successfully or that had to be planned as batch jobs. The list includes the LUW ID and an error message. Error messages displayed in SM58 are taken from the target system. To display the text of the message, double-click on the message.

14 If a LUW runs successfully in the target system, the function module ARFC_DEST_CONFIRM is triggered and confirms the successful execution in the target system. Finally, the entries in the Tables ARFCSSTATE and ARFCSDATA are deleted.


1 These can reduce performance significantly in both the send and the target


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




parameter_list. The field ‘dest’ can be either a literal or a variable. Logical destinations are defined in the RFCDES table via transaction SM59 or via the menu path: Tools ->Administration,Administration->Network->RFC destinations.





<b>plz dont forget to reward points if useful</b>

0 View this answer in context