Description
In Release 3.0, you can execute function modules asynchronously in adifferent SAP system. When you call function modules in this way, theyare not executed immediately. Instead, they are stored in an internaltable and processed together after the next COMMITWORK. The calls for each destination thus constitute a LogicalUnit of Work (LUW)).
When a COMMIT WORK statement occurs, the stored calls are executed bythe next free work process in the order in which they occurred. If thereare updates before COMMIT WORK, the asynchronously called functionmodules are not executed until the all the update function modules havebeen successfully processed.
Because the RFC is like a transaction, database operations are eitherall executed or, if a function modules terminates, all rolled back. Ifan LUW runs successfully, you cannot execute it again. In some cases, itmay be necessary to program the roll back of an LUW, (for example,because a table is locked). To do this, you call the function moduleRESTART_OF_BACKGROUNDTASK which performs a rollback and ensuresthat the LUW is executed again later.
The function module ID_OF_BACKGROUNDTASK returns the ID of theLUW. You call this module after the first CALL... IN BACKGROUNDTASK andbefore COMMIT WORK. You can use the function moduleSTATUS_OF_BACKGROUNDTASK and the ID to find out whether the LUWran successfully. Normally, the LUW is executed immediately after COMMITWORK in the specified target system. However, you want it to start at aparticular time, you can set a start time with the function moduleSTART_OF_BACKGROUNDTASK which must also be called within the LUW,i.e. after the first CALL... IN BACKGROUNDTASK and before COMMIT WORK.

Technical implementation
All the calls are stored in the tables ARFCSSTATE and ARFCSDATA and eachLUW is identified by a unique ID. When a COMMIT WORK occurs, the callsattached to this ID are executed in the relevant target system. Thesystem function module ARFC_DEST_SHIP transports the data to the targetsystem and the function module ARFC_EXECUTE executes the stored functioncalls. If an error or an exception occurs during one of the calls, allthe database operations started by the preceding calls are rolled backand an appropriate error message is written to the file ARFCSSTATE. Youcan analyze this error message with Transaktion SM58.
If an LUW runs successfully in the target system, the function moduleARFC_DEST_CONFIRM is called and confirms the successful execution in thetarget system. Finally, the entries in ARFCSSTATE and ARFCSDATA aredeleted.
If the target system cannot be reached because the connection is notactive (for example), the report RSARFCSE with the ID as a parameter isscheduled as a background job and called at regular intervals. You candisplay the standard values for this by selecting ich Info -> Systemsetting in Transaction SM58. If you want a separate setting for eachdestination, you can specify this with the TRFC options in TransactionSM59. Alternatively, you can use the enhancement SABP0003 (maintain withTransaction CMOD) to override this setting by destination, user name,etc. If no connection is made, the entry in ARFCSSTATE is deleted aftera time which you can also specify in the enhancement. To perform thedeletion, you schedule the report RSARFCDL as a background job.

Further_hints

Debugging
Call the relevant transaction in debugging mode, select Goto ->Settings and set the selection field In background task:... .If you do this, the LUW is not executed at once and you can useTransaction SM58 to execute it in debugging mode.

RFC API
You can also execute programs asynchronously in 'C'-implemented functionmodules (connection type TCP/IP in Transaction SM59). Implementation ofthe function modules occurs as usual in connection with the RFC API.This contains the function modules ARFC_DEST_SHIP and ARFC_DEST_CONFIRMwhich call the appropriate functions.
Restrictions:

• The Windows API does not yet support asynchronous calls.


• Executing once must be guaranteed by the implementation of the function
module.