You are here: Home > Documentation > Development Guide > Transactional RFC (tRFC)

Transactional RFC (tRFC)

Rfc Connector supports both sending outbound and receiving inbound tRFC calls. tRFC is an extension to the RFC protocol which guarantees that a function module call is executed exactly once at the receiving side.

More information about tRFC can be found in the SAP Library.

Note: tRFC is currently not supported with SOAPSession.

Limitations of tRFC

Since tRFC is executed asynchronously, tRFC modules cannot return data to the caller (similar to CALL FUNCTION '...' IN UPDATE TASK). Therefore tRFC modules only support IMPORTING and TABLES parameters. EXPORTING and CHANGING parameters will be ignored by Rfc Connector when sending outbound tRFC calls, and will cause syntax errors in SAP if used for inbound calls.

Sending outbound tRFC calls with NWRfcSession / RfcSession

To send an outbound tRFC call with Rfc Connector, the following steps are necessary:

  1. Obtain a function module prototype through ImportCall(), by importing it from XML or by manually constructing it.
  2. Obtain a Transaction ID (TID) by calling session.CreateTransID().
  3. Call the function module with Session.CallTRFCFunction(), using the TID from step 2.
  4. If the call fails, CallTRFCFunction can be called again later. As long as the same TID is used, the function module will be executed no more often than once in the target system.
  5. After successfully calling CallTRFCFunction(), call ConfirmTransID() to allow the target system to clean up its internal storage.

Note: You can use transaction SM58 to list recent transactions. Transactions for which ConfirmTransID() has been called will be deleted from this view (so for debugging purposes you might want to skip that call).

Receiving inbound tRFC calls with NWRfcServer / RfcServer

NWRfcServer and RfcServer can receive both regular and transactional RFC calls. To receive tRFC calls, the following steps are necessary:

  1. Implement a regular RFC server by registering the function prototype and subscribing to the IncomingCall and Logon event(s).
  2. Subscribe to the TransactionCheck event and implement a function which stores and checks the received transaction IDs. Implementations of this event are expected to keep track of the state of each transaction and return the appropriate result. Subscribing to this event and returning the appropriate result is required for tRFC. Servers which run more than one listener thread are also expected to implement appropriate locking on their behalf.
  3. Subscribe to the TransactionCommit event if your persistent storage supports transactional features (e.g. if your storage is a database, issue COMMIT WORK in response to this event). Subscribing to this event is optional.
  4. Subscribe to the TransactionRollback event if your persistent storage supports transactional features (e.g. if your storage is a database, issue ROLLBACK WORK in response to this event). Subscribing to this event is optional.
  5. Subscribe to the TransactionConfirm event to clean up your transaction state-tracking datastore. For example, if you use a database table to keep track of ongoing transactions, you can use this event to delete rows relating to the given TID. Subscribing to this event is optional.