Short text

Transactional RFC

Description
As of release 3.0, you can execute function modules asynchronously in another SAP
system or in an external program. The function modules are not called immediately,
but when the next COMMIT WORK is executed. Until this time, the calls are collected
in an internal table. The calls for each destination thus constitute a Logical Unit
of Work ( LUW)).

When a COMMIT WORK statement occurs, the stored calls are executed by the next free
work process in the order in which they were called. If there are updates before
COMMIT WORK, the asynchronously called function modules are not executed until all
the update function modules have been successfully processed.

The asynchronous tRFC, which is like a transaction, guarantees that either all
database operations are executed or, if a function module terminates, all rolled
back. If an LUW is executed without errors, it cannot be executed again (it is
executed exactly once). In some cases, it may be necessary to program the roll back
of an LUW, (for example, because a table is locked). The function module
RESTART_OF_BACKGROUNDTASK is used for this. It executes a rollback and the LUW is
executed again at a later time. A transaction ID is assigned to each LUW. You only
need to know this, if, for example, you want to wait for the function module IN
BACKGROUND TASK to be executed.
The function module ID_OF_BACKGROUNDTASK returns the ID of the LUW. It must be
called after the first CALL... IN BACKGROUNDTASK and before COMMIT WORK. You can
use the function module STATUS_OF_BACKGROUNDTASK and the ID to find out later
whether the LUW ran successfully. Normally, the LUW is executed immediately after
COMMIT WORK in the specified target system. If it is to be started at a specific
time, you can set a time with the function module START_OF_BACKGROUNDTASK. This
function module must also be called within the LUW, that is, after the first
CALL... IN BACKGROUNDTASK and before COMMIT WORK.

Technical Implementation
All calls are recorded in tables ARFCSSTATE and ARFCSDATA. Each LUW is identified
by a unique ID. At the COMMIT WORK, the calls stored under this ID are executed on
the relevant target system. 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 database operations started by the preceding calls are rolled back and an
appropriate error message is written to the file ARFCSSTATE. You can analyze this
error message with transaction SM58.
If an LUW runs successfully in the target system, the function module
ARFC_DEST_CONFIRM is called and confirms the successful execution in the target
system. Finally, the entries in ARFCSSTATE and ARFCSDATA are deleted.
If the target system cannot be reached, for example, because the connection is not
active, the report RSARFCSE is scheduled as a background job with the ID as a
parameter, and is called at regular intervals. You can display the standard values
for this by choosing 'Info -> System Setting' in transaction SM58. If you want to
use a separate setting for each destination, you can specify this with the tRFC
options in transaction SM59. Alternatively, you can use the enhancement SABP0003
(maintain with transaction CMOD) to override this setting by destination, user
name, and so on. If no connection is made during the relevant time period, the
entry in ARFCSSTATE is deleted after a time which you can also specify in the
enhancement. The deletion is done in the background in report RSARFCDL.

Further notes
Debugging
Call the relevant transaction in debugging mode, choose "Goto -> Settings" and set
the selection field "In background task:..." If you do this, the LUW is not
executed immediately, and you can therefore use transaction SM58 to execute it in
debugging mode.

RFC API
You can also execute programs asynchronously in 'C'-implemented function modules
(connection type TCP/IP in transaction SM59). Implementation of the function
modules occurs as usual in connection with the RFC API. This contains the function
modules ARFC_DEST_SHIP and ARFC_DEST_CONFIRM, which call the appropriate functions.

Restrictions:

The Microsoft Windows API does not yet support asynchronous calls.
The once-only execution must be guaranteed by the implementation of the function
modules.