Ansicht
Dokumentation

OAARFCRD - Transactional RFC

Fill RESBD Structure from EBP Component Structure   Fill RESBD Structure from EBP Component Structure  
This documentation is copyright by SAP AG.

Description

Release 3.0 allows function modules to be executed asynchronously in another R/3 System or an external program. Function module calls do not take place immediately, but at the next COMMIT WORK. Until this occurs, the calls are collected in an internal table. They form a logical unit of work (LUW) for each destination.

When the COMMIT WORK is executed, all calls in a newly-released work process, are processed in the order in which they were made. If update reports were also transmitted before the COMMIT WORK, the asynchronously transmitted function modules are executed only when they can be updated without error.

The transactional asynchronous tRFC guarantees that all database operations are carried out in full, or, if a function module should react with a termination, are completely rejected (Rollback). If a LUW was executed without error, it cannot be executed again (exactly once). In certain cases, it can become necessary to roll back a LUW application programmed; e.g. because a table is currently blocked. The function module RESTART_OF_BACKGROUNDTASK is called for this. It carries out a rollback the LUW is executed again at a later time. A transaction ID is assigned to each LUW. You only need to know this, if, for example, you want to wait for the function module IN BACKGROUND TASK to be executed.
The function module ID_OF_BACKGROUNDTASK delivers the LUW ID. It should be called after the first CALL... INBACKGROUNDTASK and before the COMMIT WORK. The function module STATUS_OF_BACKGROUNDTASK and the ID can be used later on to check whether the LUW has been carried out without error. In general the LUW is executed in the specified target system immediately after COMMIT WORK. If, however, the start is at a specific point in time, a start time can be set using the function module START_OF_BACKGROUNDTASK. This function module too, should be called within the LUW, i.e. after the first CALL... IN BACKGROUNDTASK and before COMMIT WORK.

Technical Realization

All calls are recorded in the tables ARFCSSTATE and ARFCSDATA. Each LUW is characterized by a globally unique ID. When the COMMIT WORK is executed, the calls recorded under this ID are executed in the corresponding target system. The system function module ARFC_DEST_SHIP transports the data to the target system and the function module ARFC_EXECUTE executes the recorded function calls. If an error or exception occurs in relation to one of the calls, all the transmitted database operations from the previous calls are canceled (ROLLBACK) and a corresponding error message is written in the file ARFCSSTATE. This error message can be evaluated using the transaction SM58.
If a LUW was successfully executed in the target system, the function module ARFC_DEST_CONFIRM is called, which confirms successful execution in the target system. Lastly, the corresponding entries in ARFCSSTATE and ARFCSDATA are deleted.
If the target system could not be reached, e.g. because the connection is not active at the moment, the report RSARFCSE is scheduled in the batch with the ID as parameters and called at regular intervals. You can display the standard values coming into effect with 'Info -> System setting' in SM58. If you want to use a different setting for each destination, you can make this known using the tRFC options in transaction SM59. Furthermore, you can override this setting individually by destination, username etc. via the extension SABP0003 (maintain using transaction CMOD). If no connection is achieved in the planned time, the entry in the ARFCSSTATE is deleted after a certain time (which may be specified by you in the extension). Deleting takes place through batch scheduling of the report RSARFCDL.

Further notes

Debugging

Call the transaction concerned in the debugger and set the selection field to 'In Background Task:...' in 'Goto -> Settings'. This stops the LUW from being sent immediately and allows you the possibility of executing the LUW in the debugger using SM58.

RFC API

It is also possible to execute function modules implemented in 'C' asynchronously (connection type TCP/IP in SM59). The implementation of the function module takes place as usual in connection with the RFC API. The function modules ARFC_DEST_SHIP and ARFC_DEST_CONFIRM are contained there and call the corresponding functions.

Restrictions:

• Windows API does not yet support asynchronous calls.

• The one-off execution has to be guaranteed by the implementation of the function module.

CPI1466 during Backup   Fill RESBD Structure from EBP Component Structure  
This documentation is copyright by SAP AG.

Length: 4977 Date: 20240531 Time: 194146     sap01-206 ( 137 ms )