Transactional RFC Server Programs
After having connected to an R/3 System (via RfcAccept) and after having installed the supported RFC functions, the RFC server program has to use the RFC call RfcInstallTransactionControl for working with the TIDs to check and execute the real RFC function it supports before entering in the loop with RfcDispatch.
This function installs the following four functions (e.g. C routines) to control transactional behavior:
This function will be activated if a tRFC is called from an R/3
System. The current TID is passed. The function has to store this
TID in permanent storage and return 0.
If the same function will be called again later with the same TID, it has to make sure that it will return a value <>0. If the same TID is already running by another process but is not completed, the function has to wait until the transaction finishes or to stop the RFC connection with RfcAbort.
This function will be called if all RFC functions belonging to this transaction are done and the local transaction can be completed. It should be used to locally commit the transaction if necessary (working with database).
This function is called instead of the function onCommit if there is an error occurring in the RFC library while processing the local transaction. This function can be used to roll back the local transaction (working with database).
This function will be called if the local transaction is completed. All information about this TID can be deleted.
tRFC within an R/3 System
The following parameters can be configured with transaction SM59:
The program location ‘User’ defined with this transaction (start RFC server program via currently using SAPGUI) is not available, because the tRFC component is not assigned to any SAPGUI while running.
Transaction SM58 displays the running state of a transaction if the transaction was not executed successfully already.
tRFC between tRFC component, RFC library and tRFC server program
The tRFC component, the RFC library and the tRFC server communicate with each other in two phases:
F1: Function transfer
After tRFC data is received, the RFC library will activate the tRFC server program (action: start). Using RfcDispatch in a loop, the library will call up the following functions within this function transfer phase:
As described above, the function transfer phase will be repeated by the tRFC component in the R/3 System if any CPI-C error (network errors, for example) occurs during this phase. The maximum number of tries and the time between two tries can be defined by using transaction SM59 and TRFC options.
After the RFC library informs the tRFC components in the R/3 System about a successful T3, it will immediately receive confirmation of the current transaction. The RFC library will then call up the function
After this phase, the current transaction is successfully completed on both sides.
The Sample Test Program trfcserv.c
The C-program trfcserv.c, delivered in the form of executable and source code in the RFC SDK, is an example of a tRFC server program.
For testing, the ABAP program SRFCTEST, option Transactional RFC, can be used with this server program.
The data received from the R/3 System will be written in ‘trnn... n.dat’ on the running platform. Each line in this file is one line in an internal table. Only one internal table with a line length of 72 bit is used.
To manage the TIDs, the trfcserv.c program uses the file I/O on the running platform.
For each TID there is an entry in the TID-management which contains the date and time, the TID itself, the state of this transaction (CREATED, CONFIRMED,...) and the name of the data file.
Since this program can run on different platforms, a corresponding flag (SAPonUNIX, SAPonNT,...) must be set if you want to compile and link this program in your environment.
For more details, see the source code delivered in the RFC SDK.