In the following sample we want to build a RFC server, which supports transactional RFCs.
An ABAP program sends two strings as export parameters to .Net. These strings are merged in .Net and inserted into a SQL server table. Within a tRFC context only export parameter and tables are sent to the RFC server. A transactional RFC call cannot receive results.
The following code is based on the known example RFC-Server
The following events are fired from the client within the server program:
In the ABAP program the Function is called with the ABAP function CALL FUNCTION “Z_TRFC” IN BACKGROUND TASK for the asynchronous execution.
The ABAP statement is not executed immediately, but with the EXPORTING and/or TABLES content stored in a SAP database table. A COMMIT WORK starts the processing of the function, and on the .Net side the event TRFCCheckTID is fired. The transaction ID in our example is checked whether it can be found in our table on the SQL server. If the TID is missing, or available but not executed yet, TRFCCheckTID returns True (check was successful). After this the IncomingCall event is fired. In case of successful processing, the Commit event is fired, which confirms the execution. The Confirm event is fired to tidy up the transaction management.
With tRFC you can guarantee that the remote function is processed, even if at the time of the call the remote partner is not available or the connection was lost.
Contrary to the synchronous RFC you can combine different functions for the remote processing into a logical unit or work (SAP-LUW). Rollback on the whole unit is then possible. Furthermore tools for monitoring and administration are available with transaction SM58.
We also need a table on the SQL server (TransactionID) for our example. In this table, there are 4 flags (XCommit, XConfirm, XRollback and XExecuted), the field with the transaction ID (TID) and a field for the result (Result).