SAP RFC Types: sRFC, aRFC, tRFC, qRFC and bgRFC
SAP RFC variants solve different execution guarantees: synchronous RFC waits for the remote result; asynchronous RFC starts work without the same blocking response pattern; tRFC provides transactional exactly-once style delivery through persisted LUWs; qRFC adds queue-based serialization for ordered processing; bgRFC is the newer background RFC framework for reliable transactional or queued units with scheduler-controlled processing and improved administration.
Practitioner technical guide to SAP RFC Types: sRFC, aRFC, tRFC, qRFC and bgRFC, with architecture context, a worked example, decision rules, production pitfalls, S/4HANA implications, ownership, and the standard SAP objects used to prove behavior.
Reviewed by an ERPClimb SAP consultant on 20 Sept 2026· 794 words
What it is
RFC is not one delivery model. A normal synchronous remote call couples caller and target at call time and returns results/errors directly. aRFC creates asynchronous tasks and is often used for parallel processing, but application design still owns aggregation and failure handling. tRFC stores transactional units so failed communication can be retried without the caller manually resending business payloads. qRFC builds on transactional RFC with inbound/outbound queues to preserve required sequence. bgRFC provides a newer framework for reliable units, destinations, supervisors and scheduling, supporting transactional and queued behavior with more modern administration than classic tRFC/qRFC in suitable scenarios.
When to use it
Use synchronous RFC when the caller needs an immediate result and can tolerate the target being online. Use aRFC for bounded parallel work where each task is independent and the caller controls task completion. Use tRFC when reliable asynchronous delivery matters but processing order does not. Use qRFC when order between messages is part of business correctness. Use bgRFC for new reliable background-RFC designs where the platform/release/application supports it. Do not select a variant solely for speed; delivery guarantees and recovery behavior drive the choice.
How it fits the stack
SM59 destinations define technical connectivity. tRFC units are monitored through classic transactional-RFC tools; qRFC adds inbound/outbound queue monitors such as SMQ1/SMQ2. bgRFC has its own configuration and monitoring. IDoc/ALE can use tRFC or qRFC beneath the IDoc layer, which means an IDoc problem may originate either in queue/communication or later application processing. BTP Integration Suite provides different messaging capabilities and can replace some custom RFC coupling in cloud-centered architectures.
A worked example
A warehouse system sends stock movements that must reach S/4HANA in exact sequence for each warehouse number. Plain sRFC would fail immediately during downtime and require external retry logic. tRFC could retry reliably but would not guarantee the business order across all units. qRFC with a queue derived from warehouse key serializes processing while retaining retry semantics. For a new custom ABAP background interface with supported bgRFC architecture, bgRFC may provide the cleaner long-term framework.
How to choose
- Need immediate request/response: use synchronous RFC.
- Need parallel independent tasks within ABAP: consider aRFC and explicit completion handling.
- Need reliable asynchronous execution without ordering: tRFC or bgRFC transactional units can fit.
- Need business-order preservation: qRFC or queued bgRFC.
- For cloud integration, compare RFC with messaging/API patterns before creating tight system-to-system coupling.
Common pitfalls
- Calling aRFC 'reliable asynchronous messaging' without designing what happens if the remote task fails.
- Using tRFC when business order matters and then diagnosing out-of-sequence application failures later.
- Putting unrelated business objects in one qRFC queue and creating unnecessary serialization/backlog.
- Deleting SYSFAIL/blocked queues to clear monitors instead of fixing the first failing unit.
- Choosing classic tRFC/qRFC for new custom architecture without considering bgRFC or BTP messaging.
ECC, S/4HANA and clean core
All of these RFC concepts can be encountered in S/4HANA private/on-premise landscapes, especially through legacy interfaces and IDocs. bgRFC is the strategic ABAP background RFC framework for applicable new designs, while BTP-based integration often favors APIs, Event Mesh/JMS and managed retries instead of direct RFC coupling. Clean-core rules still require that the called application interface be released/supported, regardless of RFC transport.
Whose problem this is
Basis owns destination and RFC runtime infrastructure; integration/ABAP teams own unit/queue design, idempotency and error recovery; functional owners define whether message ordering is business-critical. Operations teams need runbooks for blocked queues and failed transactional units.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-technical-topics/sap-rfc-types-srfc-arfc-trfc-qrfc-bgrfcERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.