Using Transactional Remote Function Calls 

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.

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. When the calling program reaches a COMMIT WORK, the remote call is forwarded to the requested system for execution.

All tRFCs with a single destination that occur between one COMMIT WORK and the next belong to a single logical unit of work (LUW). For more information on LUWs, TIDs and on checking the status of transactional calls, see Transactional Integrity of tRFCs.

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

As an example, you can use transactional RFCs for specific types of update procedures. Some complex dialogs require that several related database tables be updated during different phases within a transaction. If the update functions needed are located on a remote machine, and if it is not essential that the table changes be carried out immediately before continuing the dialog, you can use transactional RFC calls. Instead of having to wait for each separate update procedure to be completed, the user can proceed to the end of the transaction without delay. Transactional RFC processing ensures that all the planned updates are carried out when the program reaches the COMMIT WORK statement.

Function modules that are to be called transactionally, cannot have any EXPORT parameters in the definition, since an IMPORTING parameter in the calling program leads to a syntax error.

Note also that you cannot make asynchronous calls to functions that perform call-backs.

When the Remote System is Unavailable

If the remote system is unavailable, the SAP System schedules the report RSARFCSE for background processing with the relevant transaction ID as variant. This report, which forwards asynchronous calls for execution, is called repeatedly until it succeeds in connecting with the desired system.

When scheduled in batch, RSARFCSE runs automatically at set intervals (the default is every fifteen minutes, for up to 30 attempts). You can customize this interval and the length of time the program should go on trying. To do this, use the extension programs SABP0000 and SABP0003 (or see the SAP Extension Concept and CALL CUSTOMER-FUNCTION).

In transaction SM59 (menu path: Tools → Administration, Administration → Network → RFC destinations) you can select Destination →TRFC options which enables you to configure each destination. Thus you can determine the number of connection attempts up to the task and the time between repeat attempts.

If the system is not reachable within the specified amount of time, the system stops calling RSARFCSE, and the status CPICERR is written to the ARFCSDATA table. Within another specified time (the default is eight days), the corresponding entry in the ARFCSSTATE table is deleted (this limit can also be customized). (It is still possible to start such entries in transaction SM59 manually.) 

 

CALL FUNCTION - IN BACKGROUND TASK