RFC

In SAP, RFC (Remote Function Call) is a fundamental technology that enables communication and data exchange between different SAP systems, or between SAP systems and external non-SAP systems.¹ It's essentially SAP's proprietary protocol for remote procedure calls.²

Think of it as a way for one program (the "client") to execute a function module or method that resides in another system (the "server") as if it were a local call, without needing to know the complexities of network programming.

Key aspects of RFC:

• Function Modules: In ABAP, functions designed to be called remotely are known as "remote-enabled function modules."³ These are created in transaction SE37 and have a specific attribute set.⁴
• RFC Destinations (SM59): From a Basis perspective, the configuration of RFC communication is managed via transaction SM59 (Configuration of RFC Connections). Here, you define "RFC Destinations" which store all the necessary technical details (target system's IP address/hostname, system number, client, user credentials for logon, security settings, etc.) for establishing a connection to a remote system.
• Gateway: RFC communication typically flows through the SAP Gateway, which acts as an interface between the SAP system and the external network.⁵
• Data Conversion: The RFC interface automatically handles the conversion of data parameters between the different systems, including character set conversions and hardware-dependent conversions (e.g., integer, floating point).⁶
• Security: RFC connections can be secured using various mechanisms, including SNC (Secure Network Communications) for encryption and authentication.⁷

---

Types of RFC in SAP Basis

There are several types of RFC, each designed for different communication requirements and guaranteeing different levels of reliability and order:⁸

1. Synchronous RFC (sRFC):

   • Behavior: The calling program waits for the remote function to complete and return its result before it continues its own processing.⁹
   • Reliability: The remote system must be available at the time of the call. If the connection fails or the remote system is down, the calling program will halt, and the call will fail.
   • Use Cases: Real-time communication where an immediate response is required, and the calling program cannot proceed without the result.¹⁰ Examples: checking stock availability, immediate credit checks.
   • Analogy: A phone call where you wait for the other person to answer and respond before hanging up.

2. Asynchronous RFC (aRFC):

   • Behavior: The calling program initiates the remote function call and immediately continues its own processing without waiting for the remote function to complete.¹¹ The remote function runs in a separate process or session.
   • Reliability: The remote system must be available to accept the request at the time of the call. If the remote system is unavailable, the call is lost. There's no guarantee of processing or order if multiple calls are made.
   • Use Cases: When the calling program needs to trigger a process in a remote system but doesn't immediately need the result, or when parallel processing is desired. The calling program can optionally define a "callback" routine to process results later.¹²
   • Analogy: Sending a text message and immediately doing something else, not necessarily waiting for a reply.

3. Transactional RFC (tRFC):

   • Behavior: This is a genuine asynchronous communication method that guarantees the execution of the called function module exactly once in the remote system, even if network problems occur or the remote system is temporarily unavailable.
   • Reliability:
     • Guaranteed Execution: Calls are stored in the source system's database with a unique Transaction ID (TID) until they are successfully executed in the target.¹³
     • "Exactly Once" Semantics: Even if the call is sent multiple times due to network retries, it will only be processed once on the target.
     • Order (within a LUW): All RFCs belonging to a single Logical Unit of Work (LUW) are executed in the order in which they are called and in the same program context.
     • Target Availability: The target system does not need to be available at the time the call is made. The tRFC scheduler (RSARFCSE or equivalent) repeatedly tries to send the calls until successful.¹⁴
   • Use Cases: Critical data transfers where data integrity and "exactly once" processing are paramount, regardless of target system availability. Common for ALE/IDoc processing.
   • Monitoring: Monitored via transaction SM58 (tRFC Monitor).
   • Analogy: Sending a registered letter – you know it will eventually reach its destination and be delivered once, even if it takes a few tries.

4. Queued RFC (qRFC):

   • Behavior: An extension of tRFC that provides additional serialization and guarantees that multiple Logical Units of Work (LUWs) are processed in a predefined, application-specific order.¹⁵
   • Reliability: Guarantees both "exactly once" processing and sequential processing by using inbound and outbound queues.¹⁶ An LUW is only transferred if all its predecessors in the queue have been successfully processed.
   • Use Cases: Scenarios where the sequence of processing is critical, often found in supply chain management (SCM) interfaces (e.g., CIF queues between ECC and APO) or other complex integration scenarios.¹⁷
   • Monitoring: Monitored via transaction SMQ1 (Outbound Queue) and SMQ2 (Inbound Queue).¹⁸
   • Analogy: A queue at a bank – transactions are processed one by one in the order they arrived.

5. Background RFC (bgRFC):

   • Behavior: This is the modern successor to tRFC and qRFC, introduced to address performance and functionality limitations of its predecessors.¹⁹ It offers significant improvements in scalability, performance, and monitoring.
   • Types: bgRFC supports both transactional (tRFC-like) and queued (qRFC-like) processing, referred to as bgRFC Type 1 (Transactional) and bgRFC Type 2 (Queued).
   • Reliability: Provides "exactly once" semantics and guaranteed order for Type 2.²⁰
   • Key Improvements:
     • Scalability: Better parallel processing and resource management.
     • Resource Consumption: Reduced database footprint for queues.
     • Monitoring: Enhanced monitoring capabilities.
     • Error Handling: More robust error handling.
   • Use Cases: Recommended for new implementations or when migrating from older tRFC/qRFC scenarios to leverage the performance benefits. Used heavily in modern SAP applications like S/4HANA.
   • Monitoring: Monitored via transaction SBGRFCMON (bgRFC Monitor).²¹

In Summary for SAP Basis:

As an SAP Basis administrator, understanding RFCs is crucial for:

• Configuring Connectivity: Setting up and troubleshooting communication between various SAP systems (e.g., ECC, BW, CRM, S/4HANA) and external systems.
• Monitoring Performance: Identifying bottlenecks in inter-system communication.
• Troubleshooting Issues: Analyzing RFC logs (SM59 test connection, SM58, SMQ1/SMQ2, SBGRFCMON) to diagnose connectivity problems, stuck queues, or communication errors.
• Security: Ensuring RFC connections are properly secured to prevent unauthorized access.²²