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 module RESTART_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 ofthe LUW. It must be called after the 1. CALL... IN BACKGROUNDTASK andbefore COMMIT WORK. With the function moduleSTATUS_OF_BACKGROUNDTASK and the ID you can check whether theLUW can be executed error free at a later time. Usually the LUW isexecuted immediately after COMMIT WORK in the target system specified.If it is to be started at a specific time, you can set a time with thefunction module START_OF_BACKGROUNDTASK.
This function module is also in the LUW, and is called after 1. CALL...IN BACKGROUNDTASK and efore 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 an 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 inRFCSSTATE 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 regularintervals 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 TransactionM59. 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 modules.
|