Transactional RFC and issues

Remote Function Call (RFC) is the standard SAP interface for communication between SAP systems. RFC calls a function to be executed in a remote system.

The remote system need not be available at the time when the RFC client program is executing a tRFC. The tRFC component stores the called RFC function together with the corresponding data in the database of the SAP system, including a unique transaction identifier (TID).

If a call is sent, and the receiving system is down, the call remains in the local queue until a later time. The calling dialog program can proceed without waiting to see whether or not the remote call was successful. If the receiving system does not become active within a certain amount of time, the call is scheduled to run in batch.

Transactional RFCs use the suffix IN BACKGROUND TASK.

As with synchronous calls, the DESTINATION parameter defines a program context in the remote system. As a result, if you call a function repeatedly (or different functions once) at the same destination, the global data for the called functions may be accessed within the same context.

The system logs the remote call request in the database tables ARFCSSTATE and ARFCSDATA with all of its parameter values. You can display the log file using transaction SM58. When the calling program reaches a COMMIT WORK, the remote call is forwarded to the requested system.

All tRFCs with a single destination that occur between one COMMIT WORK and the next belong to a single logical unit of work (LUW).

Troubleshooting

The most common issues in tRFC queue:

SM58 with status as “Transaction Executing”

In SM58 transaction there are tRFC stuck in “Transaction executing” status, and it is possible to observe in transaction ST22 “RAISE_EXCEPTION” dumps at same timestamps of tRFC stuck.

Transaction executing’ is the status when the SM58 entry is triggered for execution at the target and the source system is waiting for a response from the target system. This status can occur when connecting to another R/3 system or connecting with an external program.

Generally You should check in target system to see whether there are still running processes transaction (SM66) for the relevant user (this is the user you have setup in transaction SM59 on the source system for logging on to the Target system)

If there is nothing running in the target that corresponds to these SM58 entries in the source system, is it possible that the network connectivity was lost. To check the network you can perform a LAN stability test with note 500235  to see if this is the case.

SM58 with status as “Transaction Recorded”

The Transaction Recorded means that an entry created is READY to be executed by RFC mechanism.
There are many causes that can keep an entry in Transaction Recorded status for long time, such as:

• The entry was not processed yet.
• Overload due to many entries created in parallel. (Ex. High volume of IDOCs, large BW loads).
• The landscape is not optimized for RFC processing.
• The RFC resources calculation is wrong.

What You can do in this situation:

1. Check Your target system (corresponding column in SM58) in transaction SMQS. Here it should be registered on the outbound scheduler for tRFC processing (value in the TYPE field – is R for Registered), for example:

Here we can see that destination WORKFLOW_LOCAL_100 is registered for both qRFC and tRFC processing.

2. Check scheduler status

You can also see Status text as ‘Transaction recorded’ when:

• In SMQS — goto — qRFC Resources, Resource status was showing ‘Not OK‘ (Red in color).
• In SMQS Scheduler Status: was ‘INACTIVE’ which is normal (Green).

To repair go to transaction SMQS and click menu More -> Edit -> Activate scheduler made Resource status into ‘Ok‘ (Green). And SM58 entries started getting processed.

More You about it You can read in KBA 2556837.

3. Speed up the processing tRFC

Resources are calculated based in the number of Dialog work process available and the metrics for RFC usage, adjust them following this Wiki.
Sometimes, the application keeps creating a huge number of queuesexhausting the available resources. In this case, contact the application to see if the amount of entries can be decreased or consider changing how the entries are processed.

Check the destination configuration. Identify what is the Connection Type of this destination, if this is an ABAP system, the Max.Conn and Max.Runtime can be adjusted. 

• Max.Conn – The SAP Note 1403974 has details about how to measure a proper value.
• Max.Runtime – The SAP Note 1887368 explains that the default value of 60 seconds may not be enough for huge processing.

Generally You should check in SMQS transaction this information:

and optionally increase:

4. Know issues scenarios

• Check if RFC mechanism is optimized from performance perspective, the KBA 2183108 report will perform a check in the landscape (database, tables consistency, schedulers, parameters)
  and generate an output with all further recommended actions.
• See if system is running under either in an affected SAP_BASIS version or applied a SAP Note with side effects, read KBA 2334064.
• Known issues on kernel 7.4x related to dispatcher resources calculation for RFC processing. The issue was introduced on kernel 7.45 patch level 414 and kernel 7.49 patch level 210. See SAP Note 2449295.

That’s all 😉