Description
In Release 3.0 you can execute function modules asynchronously inanother SAP system or in an external program. The function modules arenot called immediately, but when the next COMMITWORK is executed. Until this time point the calls are collected inan internal table. They form one Logical Unit of Work for eachdestination (

LUW).
With COMMIT WORK all calls are processed in an available work process inthe sequence they were called in. If update records were also usedbefore the COMMIT WORK, the asynchronous function modules are notexecuted until the update function modules can be processed withouterrors.
The transactional asynchronous tRFC guarantees that all databaseoperations are fully executed or, if one of the function modulesresponds with a termination, they are fully rejected (rollback). If anLUW is executed without errors, it cannot be executed again. In somecases it may be necessary, to rollback an LUW in an application program,for example, because a table is locked. The function moduleRESTART_OF_BACKGROUNDTASK is used for this.
It executes a rollback and the LUW is executed again at a later time.Each LUW is assigned a Transaction ID. You only have to know the ID, if,for example, you want to execute the function module in a BACKGROUNDTASK.
The function module ID_OF_BACKGROUNDTASK returns the ID of theLUW. It must be called after the 1. CALL... IN BACKGROUNDTASK and beforeCOMMIT WORK. With the function module STATUS_OF_BACKGROUNDTASKand the ID you can check whether the LUW can be executed error free at alater time. Usually the LUW is executed immediately after COMMIT WORK inthe target system specified. 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 is also in the LUW,and is called after 1.CALL... IN BACKGROUNDTASK and before COMMIT WORK.

Technical Implementation
All calls are contained in tables ARFCSSTATE and ARFCSDATA. Each LUW isidentifed a globally unique ID. When a COMMIT WORK is executed, all thecalls with this ID are executed in the target system. The systemfunction module ARFC_DEST_SHIP transports the data to the target systemand the function module ARFC_EXECUTE executes the function module calls.If an error or exception occurs in one of the calls, all of the databaseoperations made in the previous calls are reset. (ROLLBACK) and an errormessage is written to file ARFCSSTATE. This error message can beevaluated in Transaction SM58.
If an LUW could be successfully executed in the target system, thefunction module ARFC_DEST_CONFIRM is called that confirms thesuccessful execution in the target system. Then the affected entries inARFCSSTATE and ARFCSDATA are deleted.
If the target system could not be reached, because, for example, theconnection is not active, the report RSARFCSE is scheduled in thebackground with the ID as the parameter and it is called at regualrintervals The standard values can be displayed in 'Info -> Systemsettings' in SM58. If you want to use your own settings for eachdestination, you can specify these in the TRFC options in TransactionSM59. If no connection can be made in the time scheduled, the entry inARFCSSTATE will be deleted after a length of time that you specify. Thedeletion is done in the background in report RSARFCDL.

Further_hints

Debugging
Call the transaction in the debugger and choose 'Goto -> settings' andselect the field 'In Background Task:...'. The LUW will not be sentimmediately.

RFC API
It is also possible to execute function modules implemented in 'C'asynchronously. (Connection type TCP/IP in SM59). The function modulesare implemented in connection with the RFC-API. The function modulesARFC_DEST_SHIP and ARFC_DEST_CONFIRM are contained here and call therelevant functions.
Restrictions:

• The Windows API does not yet support asynchronous calls.


• The once-only execution must be guaranteed by the implementation of the
function module.