SAP RFC Types: Synchronous, Asynchronous, Transactional, and Queued RFC

Remote Function Call (RFC) communication lets an SAP system invoke a remote-enabled function module in another SAP system or from an external application through an RFC-capable interface. The right communication type depends on whether the caller must wait for a response, whether the business operation must be retried, and whether several requests must be processed in sequence.

BAPIs commonly use RFC-enabled function modules as their technical transport. The BAPI defines a business-facing contract, while the RFC type controls how the call is delivered and processed. For background integration, identify both the business interface and the required delivery behavior before configuring the connection.

What Is a BAPI in SAP? explains the relationship between BAPIs, function modules, and business objects. For the broader mechanism, see Remote Function Call in SAP.

01Choose the RFC type by delivery requirement

Start with the business consequence of delay or failure. If the caller needs an immediate result, use synchronous RFC. If the caller can continue while the remote request runs, use asynchronous RFC. If the request represents a business unit that must be delivered once for processing, use transactional RFC. If several units must preserve a defined sequence, use queued RFC.

The communication type does not replace authorization, monitoring, application logging, or interface-level error handling. It defines transport and execution behavior; the called function still determines the business result.

02Synchronous RFC waits for the business result

Synchronous RFC is appropriate when the caller cannot continue until the remote function returns. A user-facing application might request customer data, validate material information, or check an availability result before allowing the next step.

The caller remains dependent on the remote system, network path, dialog availability, and execution time. A long-running synchronous call can therefore increase response time and hold resources on both sides. Keep the called operation bounded and return a clear application result.

Use sRFC when all of the following are true:

• The caller needs the response immediately.
• The remote operation is short enough for the calling context.
• A failure should be visible directly to the caller.
• The operation does not require durable retry processing after the caller disconnects.

For operational work, record the remote destination, function module, caller, start time, end time, and returned message. These details make a timeout easier to distinguish from an application error.

03Asynchronous RFC separates submission from completion

Asynchronous RFC allows the caller to start remote processing and continue its own work. The caller does not wait for the remote function to finish in the same interaction, which makes aRFC useful for parallel calls and tasks that do not need to block an online transaction.

A common pattern is to distribute independent read operations across several systems or to submit enrichment tasks while the main process continues. The design must still define how the application receives completion information and how it handles a failed or incomplete task.

Use aRFC when:

• Remote calls are independent and can run in parallel.
• The initial transaction can continue without the final result.
• The application has a callback, status, or monitoring mechanism.
• The workload benefits from decoupling without requiring tRFC-style transactional delivery.

Asynchronous execution does not automatically guarantee durable delivery. If a request must survive a caller restart and be retried as a transactional unit, evaluate tRFC or qRFC instead.

04Transactional RFC protects independent business units

Transactional RFC packages a remote call into a transactional unit, commonly called an LUW in SAP integration terminology. The unit is registered for delivery and can be processed later, allowing the sender to continue after the request has been recorded.

The main use case is an independent business transaction that must reach the target reliably and should not be processed repeatedly as a new business event. tRFC is useful for decoupled updates where strict ordering between separate units is not required.

Typical examples include:

• Sending an independent master-data update to another SAP system.
• Forwarding a completed business event for later processing.
• Replicating a posting where the sender should not remain blocked by the receiver.
• Retrying a temporary communication failure through transactional handling.

Treat the transactional unit as the recovery boundary. Monitor failed units, investigate the application or connection cause, and reprocess them only after confirming the effect on the target. A retry strategy must account for the business function's idempotency and for duplicate-looking requests that may have reached the receiver before the sender recorded the failure.

05Queued RFC preserves processing order

Queued RFC extends transactional delivery with serialization. Requests enter a queue and are processed in the order defined for that queue. This makes qRFC suitable when later updates depend on earlier updates, such as a sequence of master-data or document changes.

Queue design is part of the application architecture. A queue that is too broad can serialize unrelated work and reduce throughput. A queue that is too narrow can allow dependent changes to arrive out of order. Define the queue name, sender, receiver, business object scope, and ordering rule together.

Use qRFC when:

• The order of changes affects the business result.
• Several updates belong to the same logical sequence.
• Temporary target downtime should delay processing without losing the sequence.
• Operations need a visible backlog that can be investigated and restarted.

When a queue is stopped, inspect the first blocked entry before restarting later entries. Resolve the oldest cause first because subsequent entries may depend on it. Review both the queue status and the target application's response before repeating a request.

06Background RFC handles decoupled background work

Background RFC is designed for background processing and provides a framework for submitting work independently of the initiating dialog process. It is useful when an integration should be decoupled from interactive execution and should be managed through background processing controls.

Select the bgRFC unit behavior according to the integration's delivery and ordering needs. A design that requires independent units has different throughput characteristics from one that serializes related units. Document the unit boundary, restart behavior, monitoring owner, and retention approach before moving the interface into production.

For all background types, define an operational status model. At minimum, distinguish submitted, running, completed, failed, and waiting states. Store a correlation identifier that connects the sender's business document to the remote processing record.

07Match common SAP RFC use cases to a communication type

The following decision pattern is practical for interface design:

1. Need an immediate answer? Choose sRFC when the caller must display or act on the response before continuing.
2. Can the caller continue independently? Choose aRFC when parallel or deferred execution is sufficient.
3. Must the request be retained and retried as a business unit? Choose tRFC.
4. Must related requests be processed in sequence? Choose qRFC.
5. Does the workload belong in managed background processing? Evaluate bgRFC.

The choice should also consider volume, response time, restart behavior, duplicate prevention, queue ownership, and the target system's maintenance windows. A communication type that works for a low-volume online lookup may be unsuitable for a high-volume replication interface.

For naming conventions and how function modules, BAPIs, and business objects relate, see SAP RFC, BAPI, Naming, and BOR Concepts. Keep the technical name, destination, communication type, and business purpose together in the interface documentation.

08Troubleshoot RFC failures by processing stage

Separate failures into connection, authorization, execution, delivery, and business-result stages. This prevents a target application error from being treated as a network problem.

• Connection: Check destination reachability, host and service details, gateway availability, and timeout behavior.
• Authorization: Confirm the technical user can execute the remote-enabled function and perform the business operation.
• Execution: Check the called function's parameters, data prerequisites, locks, and runtime messages.
• Delivery: For tRFC, qRFC, or bgRFC, inspect the unit or queue status and determine whether the request is waiting, failed, or already processed.
• Business result: Read the returned messages and verify the target document or update directly before retrying.

For a structured incident workflow, use Common SAP RFC and BAPI Error Patterns. During recovery, preserve the original request identifier and timestamps so that operations can correlate retries with the first attempt.

09Build an RFC interface runbook

A production runbook should identify the calling system, receiving system, RFC destination, function module or BAPI, communication type, technical user, queue or unit naming rule, and monitoring transaction or application. Include the expected response time for synchronous calls and the expected completion window for background calls.

Document the retry rule explicitly. State which failures are safe to retry, how duplicate processing is detected, who owns blocked queues, and when an application owner must approve reprocessing. For qRFC, include the queue serialization key and the dependency represented by that key.

Test the full lifecycle rather than only a successful call: target availability, temporary network failure, authorization failure, invalid business data, duplicate submission, queue blockage, restart, and reconciliation. A reliable integration is one that can be diagnosed and recovered without guessing what happened to the original request.