Description
Release 3.0 allows function modules to be executed asynchronously inanother R/3 System or an external program. Function module calls do nottake place immediately, but at the next COMMITWORK. Until this occurs, the calls are collected in an internaltable. They form a logical unit of work(LUW) for each destination.
When the COMMIT WORK is executed, all calls in a newly-released workprocess, are processed in the order in which they were made. If updatereports were also transmitted before the COMMIT WORK, theasynchronously transmitted function modules are executed only when theycan be updated without error.
The transactional asynchronous tRFC guarantees that all databaseoperations are carried out in full, or, if a function module shouldreact with a termination, are completely rejected (Rollback). If a LUWwas executed without error, it cannot be executed again (exactly once).In certain cases, it can become necessary to roll back a LUWapplication programmed; e.g. because a table is currently blocked. Thefunction module RESTART_OF_BACKGROUNDTASK is called for this. Itcarries out a rollback the LUW is executed again at a later time. Atransaction ID is assigned to each LUW. You only need to know this, if,for example, you want to wait for the function module IN BACKGROUNDTASK to be executed.
The function module ID_OF_BACKGROUNDTASK delivers the LUW ID. Itshould be called after the first CALL... INBACKGROUNDTASK and beforethe COMMIT WORK. The function module STATUS_OF_BACKGROUNDTASKand the ID can be used later on to check whether the LUW has beencarried out without error. In general the LUW is executed in thespecified target system immediately after COMMIT WORK. If, however, thestart is at a specific point in time, a start time can be set using thefunction module START_OF_BACKGROUNDTASK. This function moduletoo, should be called within the LUW, i.e. after the first CALL... INBACKGROUNDTASK and before COMMIT WORK.

Technical Realization
All calls are recorded in the tables ARFCSSTATE and ARFCSDATA. Each LUWis characterized by a globally unique ID. When the COMMIT WORK isexecuted, the calls recorded under this ID are executed in thecorresponding target system. The system function module ARFC_DEST_SHIPtransports the data to the target system and the function moduleARFC_EXECUTE executes the recorded function calls. If an error orexception occurs in relation to one of the calls, all the transmitteddatabase operations from the previous calls are canceled (ROLLBACK) anda corresponding error message is written in the file ARFCSSTATE. Thiserror message can be evaluated using the transaction SM58.
If a LUW was successfully executed in the target system, the functionmodule ARFC_DEST_CONFIRM is called, which confirms successful executionin the target system. Lastly, the corresponding entries in ARFCSSTATEand ARFCSDATA are deleted.
If the target system could not be reached, e.g. because the connectionis not active at the moment, the report RSARFCSE is scheduled in thebatch with the ID as parameters and called at regular intervals. Youcan display the standard values coming into effect with 'Info -> Systemsetting' in SM58. If you want to use a different setting for eachdestination, you can make this known using the tRFC options intransaction SM59. Furthermore, you can override this settingindividually by destination, username etc. via the extension SABP0003(maintain using transaction CMOD). If no connection is achieved in theplanned time, the entry in the ARFCSSTATE is deleted after a certaintime (which may be specified by you in the extension). Deleting takesplace through batch scheduling of the report RSARFCDL.

Further_hints

Debugging
Call the transaction concerned in the debugger and set the selectionfield to 'In Background Task:...' in 'Goto -> Settings'. This stops theLUW from being sent immediately and allows you the possibility ofexecuting the LUW in the debugger using SM58.

RFC API
It is also possible to execute function modules implemented in 'C'asynchronously (connection type TCP/IP in SM59). The implementation ofthe function module takes place as usual in connection with the RFCAPI. The function modules ARFC_DEST_SHIP and ARFC_DEST_CONFIRM arecontained there and call the corresponding functions.
Restrictions:

• Windows API does not yet support asynchronous calls.


• The one-off execution has to be guaranteed by the implementation of the
function module.