Remote Function Call (RFC) in SAP ABAP Tutorial

By : Jessica Blake Jessica Blake
Hours Updated

⚡ Smart Summary

Remote Function Call (RFC) is the SAP communication mechanism that lets an ABAP program invoke a function module running on another SAP or external system. It abstracts the network plumbing, converts data formats, and surfaces failures back to the caller cleanly.

  • 📡 Core Mechanism: CALL FUNCTION…DESTINATION invokes a function module on a logical destination defined in SM59.
  • 🔁 Four Variants: Synchronous, Asynchronous, Transactional, and Queued RFC each guarantee a different delivery contract.
  • 🌐 Connection Types: SM59 supports Type 3 (ABAP-to-ABAP), Type I (same-database peers), and Type T (external programs).
  • 🛠️ Build Path: Set the function module to Remote-enabled in SE37, code it, and define the destination in SM59 on the caller.
  • 🤖 AI Angle: AI assistants generate ABAP RFC stubs from natural-language specs and parse SM58 errors into actionable fixes.
Read More

Functions of the RFC Interface

What is RFC in SAP?

RFC stands for Remote Function Call. It is the mechanism that allows business applications to communicate and exchange information — in pre-defined formats — with other systems. RFC is the most common way one SAP system talks to another, and it is also the bridge that connects SAP systems to non-SAP applications.

RFC offers two interfaces:

  1. A calling interface for ABAP programs.
  2. A calling interface for non-SAP programs.

Any ABAP program can invoke a remote function using the CALL FUNCTION…DESTINATION statement. The DESTINATION parameter tells the SAP system that the called function runs on a different system from the caller.

Syntax

CALL FUNCTION 'remotefunction'
  DESTINATION dest
  EXPORTING  f1 = ...
  IMPORTING  f2 = ...
  TABLES     t1 = ...
  EXCEPTIONS ...

Logical destinations are defined via transaction SM59 and stored in table RFCDES.

Functions of the RFC Interface

Functions of the RFC Interface

The RFC runtime is responsible for three things on every call:

  • Converting all parameter data into the representation expected by the remote system.
  • Calling the communication routines needed to talk to the remote system.
  • Handling communication errors and surfacing them to the caller through the EXCEPTIONS parameter of CALL FUNCTION.

RFC communication between SAP systems

RFC is the SAP protocol that handles communication between systems and simplifies the related programming. It is the process of calling a function module that resides on a different machine from the caller program. RFCs can technically be used to call a function module on the same machine, but they are most often used when the calling and called programs run on separate machines. The RFC interface system is used to set up RFC connections between different SAP systems, as well as between SAP and external (non-SAP) systems.

Must-Know Details About RFC

  • SAP uses the CPIC protocol (Common Programming Interface for Communication) to transfer data between systems. CPIC is SAP-specific. RFC is a communications interface built on top of CPI-C, but with more functions and a friendlier surface for application programmers.
  • The RFC library functions support the C programming language and Visual Basic on Windows platforms.
  • RFC connections work across the entire system. An RFC connection defined in client 000 can also be used from client 100 without any difference.
  • RFC is the protocol for calling specialised subroutines (function modules) over the network. Function modules are comparable to C functions or Pascal procedures: they expose a defined interface through which data, tables, and return codes are exchanged. Function modules are managed inside the SAP system in a dedicated library, the Function Builder.
  • The Function Builder (transaction SE37) gives application programmers an environment for writing, documenting, and testing function modules that can be called locally as well as remotely. The system automatically generates the additional code (the RFC stub) needed for remote calls.
  • RFC connections are maintained using transaction SM59. SAP also ships an RFC-SDK (Software Development Kit) that uses extensive C libraries so external programs can connect to the SAP system.
  • The only difference between a remote call to another server and a local call is the DESTINATION parameter, which specifies the target server on which the program should execute.

Advantages of RFC

RFC reduces programming effort by removing the need to re-implement modules and methods at the remote end. The RFC layer takes care of:

  • Converting the data into a format the remote (target) system can understand.
  • Calling the routines needed to set up communication with the remote system.
  • Handling errors that arise during communication.
  • Providing reliable transactional semantics when transactional or queued variants are used.

RELATED ARTICLES

Types of RFC

Types of RFC

SAP supports four RFC variants. Each one offers a different trade-off between latency, reliability, and ordering guarantees.

1. Synchronous RFC (sRFC)

Synchronous RFC requires both the client and the server to be available at the time of the call. It is the most common type and is used whenever the caller needs the result immediately after execution.

sRFC is a means of communication between systems where acknowledgments are expected. The source system’s resources wait on the target system and ensure that the message arrives with an ACK. The data exchanged is consistent and reliable.

The drawback is that if the target system is unavailable, the source-system resources wait until it comes back, which can push source-system processes into Sleep/RFC/CPIC mode at the target system and block resources.

Used for:

  • Real-time communication between systems.
  • Communication between the SAP Web Application Server and the SAP GUI.

2. Asynchronous RFC (aRFC)

Asynchronous RFC is communication between systems where no acknowledgment is required — comparable to dropping a postcard in the post. Both systems do not need to be available at the time of execution, and the result is not immediately returned to the calling system.

The source-system resource does not wait for the target system; it delivers the data and moves on. This makes aRFC fast but not reliable on its own — data may be lost if the target system is unavailable.

Used for:

  • Fire-and-forget communication between systems.
  • Parallel processing across systems.

3. Transactional RFC (tRFC)

Transactional RFC is a special form of asynchronous RFC. It ensures transaction-like handling of processing steps that would otherwise be autonomous.

tRFC executes the called function module on the RFC server exactly once, even if the data is sent multiple times due to network issues. The remote system does not need to be available at the moment the RFC client runs the call. The tRFC component stores the called function and its data in the SAP database under a unique Transaction ID (TID). If the target system is unavailable, the data is written into RFC tables (visible in transaction SM58) and later picked up by the scheduler report RSARFCSE, which runs every 60 seconds.

Used for:

  • Extending asynchronous RFC with at-most-once delivery.
  • Reliable communication between systems where exactly-once execution matters.

4. Queued RFC (qRFC)

Queued RFC extends tRFC by guaranteeing that individual steps are processed in the sequence specified by the calling application. To ensure that multiple LUWs (Logical Units of Work / transactions) are processed in the intended order, tRFC can be serialised using inbound and outbound queues — which is where the name “queued RFC” comes from.

Used for:

  • Extending Transactional RFC with strict ordering.
  • Scenarios where a defined processing sequence is mandatory.
  • Cases where several transactions must be processed in a pre-defined order.

RFC Type Comparison

Type Caller Waits? Reliable? Ordered? Best For
sRFC Yes Yes N/A (single call) Real-time look-ups
aRFC No No No Fire-and-forget, parallel work
tRFC No Yes (exactly-once) No Reliable async updates
qRFC No Yes (exactly-once) Yes Strictly ordered updates

Types of RFC Connections

Types of RFC Connections

SM59 supports several connection types. The three you will encounter most often are summarised below.

Type 3 — ABAP-to-ABAP

Type 3 entries specify the connection between ABAP systems. The host name or IP address is mandatory; logon information can be supplied optionally. Type 3 is applicable both for RFCs between ABAP systems and for external calls into ABAP systems.

Type I — Same-Database Peer

Type I entries specify ABAP systems that share the same database as the current system. These entries are pre-defined and cannot be modified. A typical entry name looks like ws0015_K18_24:

  • ws0015 — host name
  • K18 — system (database) name
  • 24 — TCP service name

Type T — External Program

Type T destinations connect to external programs that use the RFC API to receive RFCs. The activation type can be either Start or Registration. If it is Start, the host name and the path of the program to be started must be provided.

How to Code an RFC

The end-to-end build of an RFC has five steps. The first three are mechanical clicks in SE37 and SM59; the last two are about getting the contract right.

Step 1: In the function module attributes tab of transaction SE37, set the processing type to Remote-Enabled Module to mark the function module as RFC-capable.

SE37 Remote-Enabled Module

Step 2: Write the code for the function module in the source-code editor.

Function module source code

Step 3: Define the destination of the RFC server in the RFC client system that calls the remote function — done in transaction SM59.

SM59 destination setup

Step 4 — Declaring Parameters: All parameter fields for a remote function module must be defined as reference fields — that is, typed against ABAP Dictionary fields. Value parameters are not allowed for remote-enabled function modules.

Step 5 — Exceptions: The system raises COMMUNICATION_FAILURE and SYSTEM_FAILURE internally on transport-level errors. Application-level exceptions can be raised inside a remote function exactly as in a local one.

Debugging Remote Function Calls

  • It is not possible to debug a remote function call into a non-ABAP system in the classic way — the foreign runtime is opaque.
  • However, for ABAP-to-ABAP RFC calls, the ABAP debugger can be used to monitor the execution of the RFC function inside the remote system.
  • With remote calls, the ABAP debugger (including its UI) runs on the local system. Data values and other runtime information for the remote function are streamed back from the remote system.

Key SAP RFC Transactions

The day-to-day RFC toolbox boils down to a handful of T-codes that every ABAP developer and Basis administrator should know by reflex.

T-code Purpose
SM59 Maintain RFC destinations — host, logon, type, security.
SE37 Function Builder — create or edit remote-enabled function modules.
SM58 Monitor failed transactional RFCs and reprocess them.
SMQ1 / SMQ2 Monitor outbound (SMQ1) and inbound (SMQ2) qRFC queues.
STRUST Maintain SSL certificates used by HTTPS-protected RFC destinations.
ST22 Inspect short dumps caused by failed remote calls.

Best Practices for SAP RFC

A well-designed RFC layer keeps integrations fast, observable, and easy to evolve. The following habits are worth baking into every project.

  • Pick the right variant for the contract. Use sRFC for synchronous look-ups, tRFC for at-most-once async updates, and qRFC when ordering matters.
  • Reuse one destination per target system rather than spreading host names across many destinations — it makes credential rotation tractable.
  • Never hard-code credentials in ABAP. Use trusted system connections or secure logon tickets where possible.
  • Monitor SM58 and SMQ2 routinely. Stuck tRFC entries silently delay business processes until they are reprocessed.
  • Pass only reference-typed parameters. Value parameters break remote-enabled function modules.
  • Use STRUST to manage TLS certificates for HTTPS destinations — expired certificates are a top cause of mysterious COMMUNICATION_FAILURE dumps.

FAQs

RFC is the low-level protocol that calls any remote-enabled function module. A BAPI is a specific, SAP-certified function module that exposes a stable business object method — every BAPI is exposed through RFC, but not every RFC call hits a BAPI.

A Trusted RFC is an SM59 destination where the target system trusts the caller’s authentication, so no password is exchanged on each call. The caller’s user context is propagated. It removes hard-coded credentials at the cost of stricter setup.

SM58 displays failed or pending transactional RFC entries waiting to be reprocessed. Each row carries the Transaction ID, the called function module, the target destination, the error text, and the time of the last retry.

No. By default RFC traffic is unencrypted. SNC (Secure Network Communications) or TLS/HTTPS destinations must be configured to encrypt traffic. SNC is the standard mechanism for production landscapes.

tRFC guarantees that a call is executed exactly once but does not preserve order across calls. qRFC builds on tRFC and additionally serialises calls through inbound or outbound queues, so calls run in the exact sequence the application defined.

Yes. External programs can register against an SAP gateway using the RFC SDK (JCo for Java, NCo for .NET, or the C SDK). SAP then calls them through a Type T destination just like any ABAP function module.

AI assistants generate ABAP RFC stubs from natural-language specs, propose the right destination type for a scenario, and translate SM58 error text into a concrete fix list — speeding up day-to-day integration work for Basis and ABAP teams.

Yes. Feed an AI assistant the ST22 dump or SM58 error and it correlates COMMUNICATION_FAILURE / SYSTEM_FAILURE patterns with the most likely root causes — expired certificate, gateway down, missing authorization — and suggests the relevant T-code to inspect.

Summarize this post with: