Purpose

The purpose of this page is to illustrate how the tRFC framework actually functions. It's main purpose is not as a troubleshooting resource but as a knowledge resource; that being said, the more one understands of a process, the better one can troubleshoot it when things go wrong.

Overview

Transactional RFCs (tRFCs) are a type of abstracted/logical RFC call. They are not a physical RFC call like synchronous or asynchronous RFCs; instead, they consist of several tRFC framework function module calls and tables.This is to ensure that multiple function modules called via the tRFC framework are executed as a group successfully or not at all, in the same order they were called (i.e. transactionally).

Note that each section on this page is incremental. I will be verbose in the first examples, and build incrementally on top of previous examples. Before reading later sections, It's best to read and understand earlier sections as basic information will be omitted from the later sections for brevity.

Key tRFC Concepts

To call a tRFC, the following syntax is used:

CALL FUNCTION <func_name> IN BACKGROUND TASK
    [AS SEPARATE UNIT]
    [DESTINATION <dest>]
    <parameter_list>.

To close (and execute) a tRFC LUW, call COMMIT WORK

tRFC calls are...

• Not executed when they are first called inside of an ABAP program.
• Bundled and executed inside Logical Units of Work (LUWs).
• Guaranteed to be executed in the same order they were called within the LUW
• Guaranteed to succeed or fail collectively within the LUW 

tRFC LUWs...

• Are composed of one or more FM calls using the IN BACKGROUND TASK syntax.
• Are closed/registered (and possibly executed) when a COMMIT WORK statement is encountered.
• Are executed using calls, some synchronous and some asynchronous, to tRFC framework function modules.
• Are not guaranteed to be executed in the same order they were closed/registered. (To guarantee the execution order of separate LUWs, qRFCs must be used.)

Relationship between tRFC calls and tRFC LUWs:

The following function modules are apart of the tRFC framework:

<Function Module> (<Program>)

• ARFC_RUN_NOWAIT (SAPLARFC) - Used by the Client Step to trigger the tRFC LUW. Provides the LUW ID to the framework task.
• RFC_PING (SAPLSRFC) - Called by the Framework Step to check the availability of the chosen destination/receiver system.
• ARFC_DEST_SHIP (SAPLERFC) - Called by the Framework Step to tell the Server Step the LUW ID, what function modules to execute, and in what order. Also provides any required parameters to execute each FM.
• ARFC_DEST_CONFIRM (SAPLARFC) - Called by the Framework Step to complete the tRFC LUW on the Server Side/receiving system. Clears entries from the ARFCRSTATE table in the receiving system.

The following tables are apart of the tRFC framework:

• ARFCSSTATE (aRFC Send State) - Tracks the status of outgoing tRFC LUWs and the FM calls in each LUW. Tracks the order in which to call each FM via the ARFCLUWCNT field.
• ARFCSDATA (aRFC Send Data) - Contains the information required (e.g. input parameters) to execute the FMs called via tRFC so they may be called anytime at a later date
• ARFCRSTATE (aRFC Receive State) - Tracks the status of incoming tRFC LUWs

tRFC LUWs Get their own ID. It's composed of four fields ARFCIPID, ARFCPID, ARFCTIME, and ARFCTIDCNT . This ID is visible in the ARFCSSTATE table (among others) and identifies which LUWs each FM call belongs to.

For example, the following two entries belong to the same tRFC LUW as they share the same values for ARFCIPID, ARFCPID, ARFCTIME, and ARFCTIDCNT (Note the ARFCLUWCNT field, which tracks the order in which each FM is called)

tRFC LUWs in the sending/client system...

• Exist in the sender system (i.e. the system that executed the code containing the CALL FUNCTION ... IN BACKGROUND TASK and COMMIT WORK statements )
• Are recorded in the ARFCSSTATE table (one record per FM).
• Are not actually executed on this system (unless the receiving system/destination is the same system).

tRFC LUWs in the receiving/server system...

• Exist in the receiving system.
• Are recorded in the ARFCRSTATE table (only one record per LUW; note this is different than ARFCSSTATE!)
• Are actually executed on this system.

To monitor tRFCs in the sending/client system, you can use:

• Transaction SM58

• SE16 > ARFCSSTATE

(Note the value of the ARFCSTATE field does not precisely match the Status Text column in SM58.In this case SENDED = Transaction executing)

To monitor tRFCs in the receiving/server system, you can use SE16 > ARFCRSTATE:

(Note how there is only one entry in ARFCRSTATE for each tRFC LUW, compared to ARFCSSTATE, which contains one entry for each FM called in a LUW)
(It is often unnecessary to examine the ARFCRSTATE table when investigating tRFC problems)

One Call - One LUW - Destination NONE

Program

ST12 Trace Records

• 2-1 - The step generated by the session that actually executed the called FM (tRFC Server step)
• 2-2 - The step generated by the main program (tRFC Client step)
• 2-3 - The tRFC framework step

STAT/STAD Records

The following STAD records were generated from this call:

The generated STAD records are as follows (only the relevant sections have been included):

Important points regarding the STAD records

• The client call to Z_CPI_WORK_WAIT is made on a dummy connection and is not a real RFC call.
• Connection Id - 00000000000000000000000000000000
• Destination - a_rfc

• RFC type - synchronous

• The server call record for Z_CPI_WORK_WAIT is also recorded under a dummy connection, but with a slightly different RFC type

  • Connection Id - 00000000000000000000000000000000

  • Destination - a_rfc

  • RFC type - bgRFC replay (synchronous) 

  • (on older kernel versions, RFC type can be listed as tRFC (synchronous) )

• ARFC_RUN_NOWAIT and ARFC_DEST_SHIP will always have a runtime larger than that of the called FM(s) (in this case, Z_CPI_WORK_WAIT ). Only when the runtime of ARFC_RUN_NOWAIT and A_RFC_DESTSHIP is significantly higher than the target FM(s) should you be suspicious of the tRFC framework, but the much more likely explanation is a network, gateway, or RFC resource issue, and not the actual framework itself.
• Note the total response time of the RFC tasks is >10 seconds, but this is not the true response time, as the framework task spends 4.682 seconds rolled out, waiting for the server task.

ST05 Trace Entries

Unfortunately I couldn't think of an adequate way to visualize and show each step using the formatting provided by the wiki; instead, please read sheet 1 Call - Destination NONE in the following annotated Excel file:

And follow along using the following timeline:

Timeline

Note:

• Each vertical bar represents an ABAP session.
• Vertical scale is not proportional to time spent/required
• WPs do not communicate to each other directly during RFC calls, but through the gateway. Therefore, anytime there is an arrow representing RFC communication, remember that the gateway is involved, receiving, handling, and sending requests between the sessions/WPs.

Two Calls - One LUW - Destination NONE

Program

STAT/STAD Records

The generated STAD records are as follows (most convenient to open in a new tab):

Important points regarding the STAD records

• No additional tasks are needed when we increase the number of calls in one LUW; i.e. the framework task ships both Z_CPI_WORK_WAIT calls to a single tRFC Server Task which executes both called FMs.
• ARFC_DEST_SHIP has a runtime close to the total runtime of the called FMs as we would expect.
• (One of the calls to Z_CPI_WORK_WAIT has a recorded runtime of 0 ms which is not correct; you can see the actual runtime in the ST05 performance traces)

ST05 Trace Entries

Please refer to sheet 2 Calls - 1 LUW - Dest NONE in the annotated Excel file:

Timeline

Note that ARFCSSTATE is not updated between each execution of Z_CPI_WORK_WAIT, thus the server task attempts to execute all FMs in a tRFC, and only once all FMs execute successfully are the entries in ARFCSSTATE updated by the framework task.  If one FM in a tRFC LUW fails, the entire LUW is put into an error state.

.

Two Calls - Two LUWs - Destination NONE

(One call per LUW)

Program

STAT/STAD Records

The generated STAD records are as follows (most convenient to open in a new tab):

Important points regarding the STAD records

• Another framework step is needed here as two LUWs were created (we called Z_CPI_WORK_WAIT twice followed by COMMIT WORK each time)
• The Transaction ID is equal for all steps, despite there being multiple LUWs. (Thus, dialog Transactions and LUWs ID are not directly related.)

ST05 Trace Entries

Please refer to sheet 2 Calls - 2 LUWs - Dest NONE in the annotated Excel file:

Timeline

One Call - One LUW - Destination <Other System>

Program

The test program is being executed on Y59, and the target system is Y57; therefore:

• Y59 is the sending system
• Y57 is the receiving system

STAT/STAD Records

Sending/Client System:

Receiving/Server System:

The generated STAD records are as follows (most convenient to open in a new tab):

Important points regarding the STAD records

• The Dialog Transaction ID is the same across systems/application servers
• The Connection ID is the same in the client calls of the Framework Task and the server calls of the Server Task

ST05 Trace Entries

Please refer to sheet 1 Call Dest <other system> in the annotated Excel file:

Timeline

We can see the framework task still resides on the sending system, and only the server tasks is carreid out on the receiving system.

Note that two gateways are now involved in communication, the GW in the app server of the sending system and the GW of the app server in the receiving system.

System Availability

Another key concept of the tRFC is that the destination does not need to be available at the time of calling the FM/registering the LUW.

If the framework task could not complete the tRFC LUW, the information needed to execute the LUW is still contained in the ARFCSSTATE & ARFCSDATA tables and can be executed at a  later time.

See the System Availability section of the following help page for more information on this behavior:
https://help.sap.com/SAPHELP_NWPI71/helpdata/en/22/042578488911d189490000e829fbbd/content.htm

The following note contains additional information on how to influence this behavior:
SAP Note 1902003 - Many ARFC* jobs in SM37 and many "Error when opening an RFC connection" in SM58 at the same time

Additional Notes

SAP Note 1483845 - Using the report RSARFCEX (to execute LUWs not yet executed; e.g. in error state)

Supplementary Files