In Release 3.0, you can execute function modules asynchronously in a different R/3 System. When you call function modules in this way, they are not executed immediately. Instead, they are stored in an internal table and processed together after the next COMMIT WORK. 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 occurred. If there are updates before COMMIT WORK, the asynchronously called function modules are not executed until the all the update function modules have been successfully processed.
Related: Create and Maintain RFC Destinations
Because the RFC is like a transaction, database operations are either all executed or, if a function modules terminates, all rolled back. If an LUW runs successfully, you cannot execute it again. In some cases, it may be necessary to program the roll back of an LUW, (for example, because a table is locked). To do this, you call the function module RESTART_OF_BACKGROUNDTASK which performs a rollback and ensures that the LUW is executed again later.
The function module ID_OF_BACKGROUNDTASK returns the ID of the LUW. You call this module 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 whether the LUW ran successfully. Normally, the LUW is executed immediately after COMMIT WORK in the specified target system. However, you want it to start at a particular time, you can set a start time with the function module START_OF_BACKGROUNDTASK which must also be called within the LUW, i.e. after the first CALL... IN BACKGROUNDTASK and before COMMIT WORK.
All the calls are stored in the tables ARFCSSTATE and ARFCSDATA and each LUW is identified by a unique ID. When a COMMIT WORK occurs, the calls attached to this ID are executed in 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 the 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 Transaktion 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 because the connection is not active (for example), the report RSARFCSE with the ID as a parameter is scheduled as a background job and called at regular intervals. You can display the standard values for this by selecting ich Info -> System setting in Transaction SM58. If you want 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, etc. If no connection is made, the entry in ARFCSSTATE is deleted after a time which you can also specify in the enhancement. To perform the deletion, you schedule the report RSARFCDL as a background job.
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 use Transaction SM58 to execute it in debugging mode.
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.
• The Windows API does not yet support asynchronous calls.
qRFC Monitor (Outbound Queue)
In Release 3.0 you can execute function modules asynchronously in another R/3 System or in an external program. The function modules are not called immediately, but when the next COMMIT WORK is executed. Until this time point the calls are collected in an internal table. They form one Logical Unit of Work for each destination ( LUW).
With COMMIT WORK all calls are processed in an available work process in the sequence they were called in. If update records were also used before the COMMIT WORK, the asynchronous function modules are not executed until the update function modules can be processed without errors.
The transactional asynchronous tRFC guarantees that all database operations are fully executed or, if one of the function modules responds with a termination, they are fully rejected (rollback). If an LUW is executed without errors, it cannot be executed again. In some cases 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 BACKGROUND TASK.
The function module ID_OF_BACKGROUNDTASK returns the ID of the LUW. It must be called after the 1. CALL... IN BACKGROUNDTASK and before COMMIT WORK. With the function module STATUS_OF_BACKGROUNDTASK and the ID you can check whether the LUW can be executed error free at a later time. Usually the LUW is executed 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 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.
All calls are contained in tables ARFCSSTATE and ARFCSDATA. Each LUW is identifed a globally unique ID. When a COMMIT WORK is executed, all the calls with this ID are executed in the target system. The system function module ARFC_DEST_SHIP transports the data to the target system and the function module ARFC_EXECUTE executes the function module calls. If an error or exception occurs in one of the calls, all of the database operations made in the previous calls are reset. (ROLLBACK) and an error message is written to file ARFCSSTATE. This error message can be evaluated in Transaction SM58.
If an LUW could be successfully executed in the target system, the function module ARFC_DEST_CONFIRM is called that confirms the successful execution in the target system. Then the affected entries in ARFCSSTATE and ARFCSDATA are deleted.
If the target system could not be reached, because, for example, the connection is not active, the report RSARFCSE is scheduled in the background with the ID as the parameter and it is called at regualr intervals The standard values can be displayed in 'Info -> System settings' in SM58. If you want to use your own settings for each destination, you can specify these in the TRFC options in Transaction SM59. If no connection can be made in the time scheduled, the entry in ARFCSSTATE will be deleted after a length of time that you specify. The deletion is done in the background in report RSARFCDL.
Call the transaction in the debugger and choose 'Goto -> settings' and select the field 'In Background Task:...'. The LUW will not be sent immediately.
It is also possible to execute function modules implemented in 'C' asynchronously. (Connection type TCP/IP in SM59). The function modules are implemented in connection with the RFC-API. The function modules ARFC_DEST_SHIP and ARFC_DEST_CONFIRM are contained here and call the relevant functions.
• The Windows API does not yet support asynchronous calls.
• The once-only execution must be guaranteed by the implementation of the function module.