qRFC Monitor

 

Report: RSTRFCM1

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.

Technical Implementation

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.

Debugging

Call the transaction in the debugger and choose 'Goto -> settings' and select the field 'In Background Task:...'. The LUW will not be sent immediately.

RFC API

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.

Restrictions:

• The Windows API does not yet support asynchronous calls.

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