cancel
Showing results for 
Search instead for 
Did you mean: 

Transactional RFC

Former Member
0 Kudos

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

Regards

Dinesh

Accepted Solutions (1)

Accepted Solutions (1)

Vijay
Active Contributor
0 Kudos

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.

<b>DISADVANTAGES</b>

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

systems.

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.

<b>SYNTAX</b>

Eg : CALL FUNCTION ‘remotefunction’ IN BACKGROUND TASK

CALL FUNCTION func IN BACKGROUND UNIT

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>SAMPLE PROGRAM

RSTRFCT0</b>

regards

vijay

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

Answers (4)

Answers (4)

Former Member
0 Kudos
Former Member
0 Kudos

Hi Dinesh,

Data can be transferred between two SAP systems reliably and safely using a transactional RFC (tRFC).

The called function module is executed exactly once in the RFC server system. 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 database of the SAP system, including a unique transaction identifier (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.

Transactional RFCs use the suffix IN BACKGROUND TASK.

As with synchronous calls, the DESTINATION parameter defines a program context in the remote system. As a result, if you call a function repeatedly (or different functions once) at the same destination, the global data for the called functions may be accessed within the same context.

Check these links on tRFC

http://help.sap.com/saphelp_nw04/helpdata/en/22/042578488911d189490000e829fbbd/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/22/042585488911d189490000e829fbbd/content.htm

http://help.sap.com/saphelp_nw04/helpdata/en/8f/53b67ad30be445b0ccc968d69bc6ff/content.htm

Thanks,

Vinay

Former Member
0 Kudos

Hi,

the Blog: WebServices: A real world implementation experience shows you a good example how to use tRFC

/people/thomas.jung3/blog/2005/02/14/webservices-a-real-world-implementation-experience

Regards