Transactional Integrity of tRFCs
You can execute function modules in background tasks in another SAP system or an external program. When you call function modules in this way, they are not executed at once, but wait until a COMMIT WORK is triggered.
Transactional RFCs receive there name from the fact that the associated remote function call mechanism guarantees transactional integrity for all calls made with the IN BACKGROUND TASKsuffix. As with database updates, LUWs (logical units of work) are created for calls that are scheduled to run in background tasks. All tRFCs with a single destination that occur between one COMMIT WORK and the next belong to a single LUW. Within a given LUW, all calls:
· execute in the order they were called
· run in the same program context in the target system
· run as a single transaction: they are either committed or rolled back as a unit.
LUWs are identified by transaction IDs that are unique world-wide. The transaction ID can be determined from an ABAP program by calling function module ID_OF_BACKGROUNDTASK. (You must call this function after the first asynchronous CALL, and before the related COMMIT WORK.)
Because the RFC is like a transaction, database operations are either all executed or, if a function module 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.
Normally, the LUW is executed immediately after COMMIT WORK in the specified target system. However, you can also define a certain time at which you want the execution to be made. To do this, call the function module START_OF_BACKGROUNDTASK from within the affected LUW after the first CALL... IN BACKGROUND TASK and before COMMIT WORK.
Checking the Status of Transactional Calls
All transactional RFCs are stored in the tables ARFCSSTATE and ARFCSDATA. Here, each LUW is identified by a unique ID. When a COMMIT WORK is made, the calls belonging to 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 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.
There are two methods for checking on the status of a transaction ID:
· From an ABAP program
The function module ID_OF_BACKGROUNDTASK returns the ID of the LUW. You call this module after the first CALL... IN BACKGROUND TASK and before COMMIT WORK.
CALL FUNCTION ‘ID_OF_BACKGROUNDTASK’ IMPORTING TASK-ID = TID.
Once you have identified the ID of the LUW, you can use the function module STATUS_OF_BACKGROUNDTASK to determine the status of the transactional RFC.
CALL FUNCTION ‘STATUS_OF_BACKGROUNDTASK’
EXPORTING TID |
= TASK-ID |
IMPORTING ERRORTAB |
= ERTAB |
EXCEPTIONS COMMUNICTATION |
= 01 |
(Connection not available: will try again later) |
|
RECORDED |
= 02 |
(ARFC is scheduled) |
|
ROLLBACK |
= 03 |
(Rollback triggered in target system) |
|
· Online
Call transaction SM58 (Tools → Administration → Monitoring → Transactional RFC). This tool lists only those transactonal RFCs that could not be carried out successfully or that had to be planned as batch jobs. The list includes the LUW ID and an error message. Error messages displayed in SM58 are taken from the target system. To display the text of the message, double-click on the message.
Transaction SM58 also lets you control your transactional RFC at various stages. If the call ends abnormally during the sending process, you may need to use the Rollback LUW function to manually rollback the LUW before attempting a resend. If the target system was unavailable, you can use the Backgr.job function to display the batch job created for your call. Execute funct. module lets you restart the call after the occurrence of a temporary error (such as a syntax error).
If a LUW runs successfully in the target system, the function module ARFC_DEST_CONFIRM is triggered and confirms the successful execution in the target system. Finally, the entries in the Tables ARFCSSTATE and ARFCSDATA are deleted.
RFC API
You can also execute programs asynchronously in 'C'-implemented function modules (connection type TCP/IP in transaction SM59, see Destination Types). 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.