📡 What is SAP RFC and Why Does It Need a Queue?
Today we are explain What is SAP RFC and Why Does It Need a Queue.visualize two SAP systems -one is your main ECC system sitting in Mumbai, and the other is a warehouse management system (WMS) in Pune. Every time a goods receipt is posted in SAP, that information needs to travel automatically to the WMS so the warehouse knows what stock has arrived. The person posting the goods receipt should not have to manually send a message or re-enter data in the WMS. SAP should do it automatically, reliably, and without losing the message even if the WMS happens to be temporarily offline. This is exactly the problem that RFC solves. RFC stands for Remote Function Call. It is SAP's built-in technique for one system to call a function in another system -automatically, over the network, as if the remote function were sitting right there locally. And RFC Queue Processing is how SAP makes sure those remote calls arrive in the right order and are never lost, even when systems are down or slow.This tutorial or document breaks down the process step by step, using simple language and real-world examples to help you master the skill.
System-to-System Communication
RFC lets SAP systems talk to each other automatically -ECC to WMS, ECC to CRM, ECC to S/4HANA, SAP to non-SAP. No manual data entry, no file transfers needed.
Guaranteed Delivery
Unlike a simple network call that can be lost if the network fails, RFC queues store messages until they are successfully delivered -even if the target system is down for hours.
Guaranteed Order
qRFC ensures messages arrive in exactly the sequence they were sent. A goods receipt cannot arrive before the purchase order it is matched against -sequence is protected.
🔌 The Four Types of RFC -Which One Does What
In SAP provides four Main different types of RFC, each designed for a different purpose. The most important thing to understand is that they are not replaceable -you choose the right type based on two questions: (1) Do I need the calling program to wait for the result? and (2) Do I need the calls to be processed in a specific sequence? The answers to these two questions point you to the right RFC type every time.
The Quick Decision Rule: If you need your calling program to wait for the result → use synchronous RFC (sRFC). If you need reliable delivery but no specific order → use tRFC. If you need reliable delivery AND specific order → use qRFC. If you are on S/4HANA and building new interfaces → use bgRFC. Most of the day-to-day monitoring and troubleshooting you will do involves tRFC and qRFC -they power ALE/EDI, IDoc processing, and most system-to-system integrations in SAP ECC environments.
📬 How SAP RFC Queues Work -Step by Step
The best way to understand how an RFC queue works is to follow a single transaction from the moment it is posted in SAP all the way to the moment it successfully arrives in the destination system. Let us use a real example: a goods receipt posted in SAP ECC that needs to be sent to a separate Warehouse Management System (WMS) at Pooja Industries.
Source System
SMQS · ARFCSDATA
RFC Destination
SMQR · ARFCIPCK
Target System
tRFC Monitor
Outbound Queues
Inbound Queues
How a Single qRFC Call Travels -Six Stages Explained
The ABAP program in the source SAP system calls a function module using CALL FUNCTION with the DESTINATION and IN BACKGROUND TASK parameters. For qRFC, it also specifies a queue name using CALL FUNCTION ... ON COMMIT QUEUE 'Pooja_WMS_001'. At this stage, the call data is NOT yet sent to the target system. It is stored in the local SAP database tables TRFCQOUT (outbound queue table) and ARFCSDATA (RFC call data). This is the key to reliability -the call is persisted to disk before anything else happens. Even if the SAP application server crashes right now, the call will not be lost.
The ABAP program executes a COMMIT WORK statement -this is what actually triggers the queue to start processing. Before COMMIT WORK, the call sits in the database but goes nowhere. After COMMIT WORK, SAP's queue scheduler picks it up. This is important to understand because it means an RFC call is always tied to a database transaction. If the program does a ROLLBACK WORK instead of COMMIT WORK, the queued RFC call is also rolled back and never sent. This ensures that RFC messages are only sent when the underlying business transaction they represent has actually been committed to the database.
ABAP: COMMIT WORK. (triggers queue scheduler) · Without COMMIT WORK → qRFC call stays in DB but is never dispatchedSAP's queue dispatcher process reads the outbound queue (visible in SMQS) and attempts to open a connection to the destination system using the RFC destination defined in SM59. If the connection succeeds, the call data is transmitted to the target system. The sequence within the named queue is strictly maintained -if there are three calls in queuePooja_WMS_001 and the first one has not yet been confirmed as successfully executed, the second and third calls wait. They do not jump ahead under any situation. This is the sequence guarantee that distinguishes qRFC from tRFC.
Monitor outbound queue: SMQS · RFC destination config: SM59 · Active connections: SM54When the message arrives at the target SAP system, it lands in the inbound queue (visible in SMQR on the target system). The target system also processes inbound queue entries in strict sequence within each named queue. A background process on the target system picks up each incoming call and executes the specified function module. Once the function module completes successfully and the target system commits the result, it sends a confirmation back to the source system. The source system removes the entry from the outbound queue table. Both sides of the queue handshake are complete.
Monitor inbound queue: SMQR (on TARGET system) · DB table: ARFCIPCK (inbound queue data) · Check processing: SM21 system logThis is where the queue model really shows its value. If the WMS system is offline for maintenance, the outbound queue entry stays in SMQS with status "waiting." SAP automatically retries the connection at configured intervals -typically every few minutes. The calls do not pile up randomly. They wait in the queue in sequence and resume exactly where they left off the moment the WMS comes back online. The goods receipt data is not lost. The warehouse does not miss the notification. The person who posted the goods receipt in MIGO sees nothing unusual -from their perspective, the transaction posted successfully.
SMQS shows status: WAITING · SM59 test connection → fails while WMS is down · Auto-retry configured in SMQS settingsIf the WMS receives the message, the connection succeeds, but the function module on the WMS side throws a runtime error or business exception -the call goes into error status. In SM58 (for tRFC) or SMQR (for qRFC inbound), the entry shows status ERROR. Critically, for qRFC, ALL subsequent calls in that same queue are now blocked. Nothing else in queuePooja_WMS_001 can process until this failed call is either fixed and retried successfully or manually deleted. This blocking behaviour is intentional -it prevents later messages from being processed before earlier ones, which would create data inconsistency in the target system.
SM58: failed tRFC entries · SMQR: blocked qRFC inbound · SMQS: blocked qRFC outbound · Fix: correct root cause → retry in SM58/SMQRWhy Queue Blocking is a Feature, Not a Bug: When a qRFC queue blocks because one call failed, it feels like an emergency -suddenly dozens of messages are piling up waiting. But the blocking is doing exactly what it should. Imagine the failed call was a purchase order and the next queued calls are goods receipts for items on that purchase order. If the goods receipts processed before the PO was fixed, the WMS would have no matching document to post them against and would throw errors on every single one. The queue block ensures the base document arrives before the documents that depend on it. Always fix the root cause before retrying -never just delete a failed entry to unblock the queue.
🔎 SM58 -Your Daily RFC Monitoring Dashboard
SM58 is the transaction you open first when someone says "the RFC is not working" or "the data is not reaching the other system." It shows all transactional RFC entries from the current system -pending calls, running calls, successfully executed calls, and most importantly, failed calls that need your attention. Think of SM58 as the inbox for your RFC outbound messages. Just like you check your email inbox for unread or failed messages, you check SM58 for RFC entries that have not been delivered successfully.
The most important column in SM58 is the Status column. Every entry falls into one of four states, and the state tells you immediately what action is needed -or whether no action is needed at all.
| Status | What it Means | Is Action Needed? | What to Do |
|---|---|---|---|
| RUNNING | The RFC call is currently being executed on the target system -the function module is actively running right now | No -this is normal | Wait. If it stays in RUNNING status for more than 10–15 minutes, the target system may be hung. Check SM50/SM66 on the target system for long-running work processes. |
| EXECUTED | The call completed successfully. The function module ran on the target system and committed without errors. | No -success | No action needed. These entries are automatically cleaned up by background jobs (typically after 2–7 days depending on your system settings in SM59). |
| CPICERR / SYSFAIL | The call could not reach the target system -connection error (CPICERR) or the target system rejected the call at the system level (SYSFAIL) | Yes -investigate the connection | Go to SM59, test the RFC destination connection. Fix the connection problem (system down, wrong host/port, wrong logon credentials). Then retry the entry in SM58. |
| ERROR | The call reached the target system and the function module started, but it threw a runtime error or returned an error code. The function did not complete successfully. | Yes -fix the root cause | Double-click the entry to see the full error message. The error is on the target system -check SM21 on the target, check the ABAP dump in ST22 on the target, or check the function module logic. Fix the root cause, then retry from SM58. |
The SM58 Troubleshooting Workflow -Step by Step
Systematic Approach -RFC Entry in Error Status in SM58
Go to SM58. The default view shows all entries. Filter for Status = ERROR or CPICERR to focus only on entries needing attention. Look at the Target System column -this tells you which destination system the failed call was trying to reach. Look at the Function Module column -this tells you which function was being called. Look at the Timestamp -this tells you when the failure started. An entry from 3 days ago that nobody noticed is a much bigger concern than one from 5 minutes ago that just happened.
SM58 → filter Status = ERROR · Columns: Target System, Function Module, Timestamp, Error Message (tooltip)Double-click the failed entry to open the detail screen. The error message here is critical. Different error messages point to different root causes. "No logon data" or "Authorisation error" → the RFC user on the target system has a password problem or missing authorisation. "System not available" → SM59 connection is broken -target system is down or network has a problem. "Function module not found" → the function module name is wrong or not activated on the target. "Short dump" → ABAP runtime error on the target system -check ST22 on the target.
SM58 → double-click entry → read error message → determine which layer: network/auth/programGo to SM59 on the source system. Find the RFC destination that matches the target system shown in SM58. Click "Connection Test." If the test fails -"Host or IP address cannot be resolved" or "Connection refused" -the network or the target system is the problem. If the test succeeds but you still have ERROR entries, the problem is not the connection -it is the function module execution on the target side. A successful SM59 connection test tells you the two systems can talk; it does not tell you the function module runs without errors.
SM59 → select destination → Connection Test (Ctrl+F8) · Also check: User and password in Logon tab are correct and not expiredIf the SM59 connection test passes but the RFC still fails, log on to the target system. Check SM21 (system log) around the timestamp of the failed RFC entry -look for red error entries related to the function module or the RFC user. Check ST22 (ABAP dump analysis) for any short dumps from the RFC user or during the function module execution time. These two transactions on the target system will almost always show you exactly what went wrong during function module execution -a missing authorisation, a missing table entry, a data conversion error, or a program logic error.
TARGET system: SM21 (system log) · ST22 (ABAP dumps) · SM50 (check active processes if RUNNING is stuck)Fix whatever the error message or target system logs revealed. Reset the RFC user password if it expired. Grant the missing authorisation if SU53 on the target shows an auth failure. Fix the ABAP program if ST22 shows a logic error. Start the target system if it was down. After fixing the root cause, go back to SM58 on the source system, select the failed entries, and click Execute (Retry). The entries will attempt to run again. If the fix was correct, they will move from ERROR status to EXECUTED status. If they fail again, you have not fully resolved the root cause.
SM58 → select error entries → Execute (retry) · After retry: Status should change to EXECUTED · If still ERROR: root cause not fully resolvedNever Delete a Failed SM58 Entry Without Understanding It: It is tempting to just delete a failed RFC entry to clear the error from SM58. But deleting an entry means the business data it contained -the goods receipt notification, the financial posting, the master data change -is permanently lost. The target system will never receive it. This creates data inconsistency between your two systems that is very hard to find and fix later. Always fix the root cause and retry first. Only delete an entry if you have confirmed that the data was already sent by another mechanism or is genuinely no longer needed.
🗂️ SMQR and SMQS -Managing the qRFC Queues
While SM58 handles tRFC monitoring, qRFC has its own pair of monitoring transactions: SMQR (inbound queue receiver on the target system) and SMQS (outbound queue scheduler on the source system). Together these two transactions give you complete visibility into the state of every named queue in your SAP landscape -how many entries are waiting, which entries are in error, and which queues are blocked.
| Transaction | Which System | What It Shows | When to Use | Key Action |
|---|---|---|---|---|
| SMQS | SOURCE system (the sender) |
Outbound queue entries -calls waiting to be sent to the target system. Shows queue name, number of waiting entries, status, and target destination. | When data is not arriving at the target system and you want to confirm the source system has the entries and is trying to send them | View queue entries, check error status, manually trigger queue processing, or pause a queue for maintenance |
| SMQR | TARGET system (the receiver) |
Inbound queue entries -calls that have been received from a source system and are waiting to be processed by the function module on the target side | When the source system shows the outbound queue as empty (already sent) but the target system has not processed the data yet -the entry is stuck in the inbound queue | View inbound queue status, check error entries, manually trigger inbound processing, register new queue names for processing |
| SM58 | SOURCE system (the sender) |
tRFC entries specifically -both pending and failed. Shows function module, destination, TID (Transaction ID), status, and error message for failed calls | When a tRFC (not qRFC) call has failed and needs to be investigated and retried. Also shows qRFC entries that have failed at the send stage | View error details, retry failed entries, delete entries after confirming data has been handled by other means |
Common qRFC Queue States and What They Mean
| Queue Status | What Is Happening | Is This Normal? | What to Do |
|---|---|---|---|
| READY | The queue has entries waiting to be processed. The queue scheduler is picking them up and processing them in order. | Yes -this is normal during active processing. A queue should move from READY to empty as entries are processed. | Nothing needed. Monitor to confirm entries reduce over time. |
| RUNNING | An entry in the queue is currently being executed. The function module is actively running on the target system right now. | Yes -normal during processing. A queue entry should complete within seconds to a few minutes normally. | If RUNNING for more than 10–15 minutes, check SM50/SM66 on the target system for a hung work process. |
| WAITINGFOR | This queue is waiting for another queue to finish first. Used when queue dependencies are explicitly configured -queue B will not start until queue A completes. | Yes -normal if queue dependencies are designed this way. Becomes a problem only if the queue it is waiting for is stuck in ERROR. | Check the queue this one is waiting for. If that queue is in ERROR, fix the error first -this queue will then automatically resume. |
| SYSFAIL | The target system is unavailable -connection to the destination RFC system failed completely. All entries in this queue are blocked. | No -needs attention. The target system is either down, the network has a problem, or SM59 credentials have changed. | Check SM59 connection test. Investigate why the target system is unreachable. Once connectivity is restored, the queue resumes automatically. |
| ERROR | One entry in the queue failed during function module execution on the target side. ALL subsequent entries in this queue are now blocked -nothing further processes until this is resolved. | No -requires immediate attention. The longer this stays in ERROR, the more entries pile up behind it. | Open the error entry, read the error message, fix the root cause on the target system, retry the failed entry. Only after successful retry do subsequent queue entries process. |
The SMQR Registration Trap -A Classic Beginner Mistake: In SMQR on the target system, inbound queues must be registered before they will be processed. If a new queue name is used by the source system for the first time -say, a new integration sends data using queue namePooja_NEW_INTF -and that queue name has never been registered in SMQR on the target system, the inbound entries will arrive and simply sit unprocessed forever. Nobody gets an error. The data just waits silently. Always check SMQR registration when setting up a new qRFC integration. This silent failure is one of the hardest to diagnose because SM58 on the source shows the calls as sent successfully -the problem is on the target side in SMQR.
🔧 Common RFC Queue Errors -Causes and Fixes
These are the RFC errors that appear most frequently in real SAP production systems. Each one has a specific root cause and a specific fix. Recognising them quickly -from the error message text alone -is what makes you the person the team calls when the RFC queue is broken at 2am.
What it means: The source system cannot reach the target system at all. The TCP/IP connection to the RFC destination host and port failed. This is a network or system availability problem -not a program problem.
Root CausesThe target SAP system is stopped or being restarted. The host name in SM59 is wrong. The port number in SM59 is wrong. A firewall rule is blocking the connection. The network path between the two systems is down.
How to FixGo to SM59 on the source system, find the RFC destination, and click Connection Test. If it fails, verify the host name and system number with the Basis team. Ping the target host from the OS level. Check if the target SAP instance is running using transaction SM21 or by logging on directly. Once the connection is restored, retry the failed entries in SM58 -they will execute automatically.
What it means: The source system reached the target system successfully, but the logon failed. The RFC user account -the special background user used for RFC connections -either has an expired password, the wrong password in SM59, or the user is locked.
Root CausesRFC user password expired in the target system (most common cause). Wrong password stored in the SM59 RFC destination on the source system. RFC user account is locked due to too many failed login attempts. RFC user was deleted or set to non-dialogable type incorrectly.
How to FixLog on to the target system as an administrator. Open SU01 for the RFC user (usually something like RFC_USER or RDICUSR). Reset the password and unlock the account if locked. Go back to SM59 on the source system, open the RFC destination, go to the Logon and Security tab, update the password to match the new one, and click Connection Test. Once the test passes, retry the failed SM58 entries.
What it means: The RFC call reached the target system and the function module started executing, but the ABAP program crashed with a runtime error (short dump). The function module did not complete and the data was not processed.
Root CausesThe called function module has a program error -an unexpected data format, a missing table entry that was expected, a data conversion error, a type mismatch in the parameter passed from the source. The function module was changed recently and has a bug. A customising entry the function module depends on is missing in the target system (e.g., the target is a newly set-up system that is missing configuration).
How to FixGo to ST22 on the target system and find the dump that occurred at the timestamp of the failed RFC call. Read the full dump -it shows exactly which line of which function module caused the crash and what the data values were at that point. Fix the program bug (developer task) or add the missing configuration entry. After the fix, retry from SM58 on the source system.
What it means: One entry in a qRFC queue failed (for any of the reasons above) and now ALL subsequent entries in that same queue are blocked with status "on hold." This is not a bug -it is qRFC's sequence guarantee working correctly. But it means a growing backlog is building up behind the failed entry.
Why This HappensqRFC's fundamental design rule: if entry N fails, entries N+1, N+2, N+3… cannot be processed until entry N succeeds. This prevents later messages from being processed before earlier ones -which would create data inconsistency in the target system. A failed goods receipt notification cannot be skipped because the next three messages after it are stock transfers that depend on the receipt being acknowledged.
How to FixFind and fix the root cause of the first failed entry -do not delete it, do not skip it. Fix the connection, the authorisation, or the program error that caused it to fail. Then retry that specific failed entry in SMQR or SM58. Once it executes successfully, all the "on hold" entries behind it will automatically start processing in order. The backlog clears itself.
The RFC Troubleshooting Sequence to Memorise: When any RFC error appears, always check in this order: (1) SM59 connection test -can the two systems talk? (2) SU01 on target -is the RFC user unlocked and password valid? (3) SM58 / SMQR error message -which layer is failing? (4) ST22 on target -is there an ABAP dump? (5) SM21 on target -any system-level errors at the time of failure? This sequence works for 95% of all RFC errors you will ever encounter in a real SAP production environment.
💻 What the ABAP Looks Like -Reading Queue Code
You do not need to write ABAP to work with RFC queues, but you do need to recognise the patterns when you see them -in a debugging session, in a code review, or when an ABAP developer shows you what is generating the stuck SM58 entries. Here are the three patterns you will see most often in real SAP integrations.
Pattern 1 -Standard tRFC Call
"═══════════════════════════════════════════════════════ " tRFC -Guaranteed delivery, no specific order " SAP generates a unique TID automatically "═══════════════════════════════════════════════════════ DATA: lv_destination TYPE rfcdest VALUE 'WMS_PRD', lv_gr_number TYPE mblnr, lv_gr_year TYPE mjahr. "IN BACKGROUND TASK = this is a tRFC call "SAP stores the call in ARFCSDATA table before sending CALL FUNCTION 'Z_WMS_NOTIFY_GOODS_RECEIPT' IN BACKGROUND TASK DESTINATION lv_destination EXPORTING iv_mblnr = lv_gr_number "GR document number iv_mjahr = lv_gr_year "GR fiscal year iv_werks = '1000'. "Plant "COMMIT WORK triggers the actual RFC send "Without COMMIT WORK, nothing is sent! COMMIT WORK. "After COMMIT WORK: entry appears in SM58 "Status: CPICERR (connection failed) or EXECUTED (success) "Check SM58 if WMS does not receive the notification
Pattern 2 -qRFC Call with Named Queue
"═══════════════════════════════════════════════════════ " qRFC -Guaranteed delivery AND guaranteed sequence " All calls with same queue name process in strict order "═══════════════════════════════════════════════════════ DATA: lv_destination TYPE rfcdest VALUE 'WMS_PRD', lv_queue_name TYPE qrfc_qnam, lv_po_number TYPE ebeln. "Build a queue name -often includes the document key "so related documents always go into the same queue lv_queue_name = 'Pooja_WMS_' && lv_po_number. "Result: e.g., 'Pooja_WMS_4500001234' "IN BACKGROUND TASK = tRFC base "ON COMMIT QUEUE = adds qRFC ordering on top of tRFC CALL FUNCTION 'Z_WMS_SEND_PURCHASE_ORDER' IN BACKGROUND TASK DESTINATION lv_destination ON COMMIT QUEUE lv_queue_name "← this makes it qRFC EXPORTING iv_ebeln = lv_po_number. "PO number "When the GR comes later, it uses the SAME queue name "This guarantees: PO arrives BEFORE GR in the WMS CALL FUNCTION 'Z_WMS_SEND_GOODS_RECEIPT' IN BACKGROUND TASK DESTINATION lv_destination ON COMMIT QUEUE lv_queue_name "← same queue = ordered EXPORTING iv_ebeln = lv_po_number. COMMIT WORK. "Monitor outbound queue: SMQS → queuePooja_WMS_4500001234 "Monitor inbound queue: SMQR on WMS system (same queue name)
Pattern 3 -Checking the RFC Destination Before Calling
"═══════════════════════════════════════════════════════ " Good practice: check the RFC destination exists " before attempting to call it -avoids confusing errors "═══════════════════════════════════════════════════════ DATA: ls_rfcdes TYPE rfcdes, lv_dest TYPE rfcdest VALUE 'WMS_PRD'. "Read the RFC destination from the RFCDES config table SELECT SINGLE * INTO ls_rfcdes FROM rfcdes WHERE rfcdest = lv_dest. IF sy-subrc <> 0. "Destination not configured in SM59 -log and skip MESSAGE w001(zrfc) WITH lv_dest. "RFC destination &1 not found" RETURN. ENDIF. "Only call if destination exists and is active IF ls_rfcdes-rfctype = '3'. "Type 3 = ABAP system connection CALL FUNCTION 'Z_WMS_NOTIFY_GOODS_RECEIPT' IN BACKGROUND TASK DESTINATION lv_dest EXPORTING iv_mblnr = lv_gr_number. COMMIT WORK. ENDIF. "RFCDES table = what you see in SM59 "rfctype '3' = ABAP connection · 'H' = HTTP · 'T' = TCP/IP
The One Line Every RFC Developer Must Remember: COMMIT WORK is what actually sends the RFC call. The CALL FUNCTION IN BACKGROUND TASK just stores the call in the database. If a program stores fifty tRFC calls but never executes COMMIT WORK -because it does a ROLLBACK WORK instead, or because the program terminates abnormally -none of those fifty calls are ever sent. When debugging "why is the RFC not being sent", the first question to ask is always: "Is COMMIT WORK being reached in the program?" Check with the ABAP debugger -put a breakpoint on the COMMIT WORK line and verify it actually executes.
🏭 Real Scenario -Pooja Industries: The WMS Queue That Went Silent
Pooja Industries Ltd runs SAP ECC 6.0 as their main system and a third-party Warehouse Management System (WMS) as their stock management system in the Pune factory. Every goods receipt posted in SAP via MIGO automatically triggers a qRFC call to the WMS system so the warehouse team knows what stock has arrived. On a Tuesday morning the warehouse team calls: "We have not received any SAP stock notifications since yesterday at 3pm. We have 47 pending goods receipts in SAP that the warehouse has not been told about."
Pooja Industries -47 Blocked qRFC Messages, WMS Queue Silent for 18 Hours
The Basis consultant, Suresh Mehta, opens SMQS on the SAP ECC system. He filters for the destination WMS_PRD. He sees the queuePooja_WMS_1000 with 47 entries -status SYSFAIL. The queue stopped processing at yesterday 3:07pm. All 47 goods receipt notifications are sitting there waiting. SMQS shows the last error: "RFC_ERROR_COMMUNICATION -Partner not reached." The WMS system is unreachable from SAP's perspective.
SMQS → filter destination: WMS_PRD → queuePooja_WMS_1000 → status SYSFAIL → 47 entries waitingSuresh goes to SM59, opens the destination WMS_PRD, and clicks Connection Test. Result: "Connection to partner WMS_PRD broken -host wms.arjunindustries.in port 3300 not reachable." He pings the WMS host from the SAP application server's OS level -the host responds. So the network is fine. The WMS host is up. But port 3300 is not answering. He calls the WMS team: they confirm the WMS application was restarted at 3pm yesterday for a patch -but the SAP RFC listener service on the WMS was not restarted along with it. The WMS is running, but it is not listening for incoming SAP RFC connections.
SM59 → WMS_PRD → Connection Test → fails · OS level: ping wms.arjunindustries.in → success · WMS team: RFC listener service stoppedThe WMS team restarts their SAP Gateway/RFC listener service. Suresh runs the SM59 connection test again: "Connection to WMS_PRD established successfully." The connection is now working. But the 47 queued entries are still sitting in SMQS with SYSFAIL status. They do not automatically retry themselves now that the connection is back -qRFC queues in SYSFAIL status must be manually triggered or will wait for the next automatic retry cycle (usually every 1–5 minutes depending on configuration).
WMS team: restart RFC listener service · SM59 → WMS_PRD → Connection Test → SUCCESS · SMQS: 47 entries still in SYSFAIL (waiting for retry trigger)Suresh selects the blocked queue in SMQS and clicks the Activate Queue button to trigger immediate reprocessing. The queue scheduler picks up all 47 entries and starts sending them to the WMS in the exact order they were originally queued -the first goods receipt from yesterday 3:05pm processes first, then 3:12pm, then 3:18pm, and so on through to this morning's entries. The WMS processes each notification in sequence. Within 3 minutes all 47 entries show status EXECUTED. The warehouse team confirms they are now receiving all the stock notifications and the backlog is clear.
SMQS → select queuePooja_WMS_1000 → Activate → queue processes 47 entries in order → all EXECUTED in 3 minutesSuresh documents the incident: 47 goods receipt notifications blocked for 18 hours because the WMS RFC listener was not included in the restart checklist for WMS patches. The root cause fix has nothing to do with SAP -it is a change to the WMS team's patch procedure. The WMS team updates their standard maintenance checklist to include "Restart RFC listener service" as a mandatory step before marking a patch as complete. Suresh sets up a daily SM58/SMQS monitoring alert in the SAP system landscape management tool so future queue blockages are detected within 15 minutes instead of 18 hours.
Root cause: WMS patch checklist missing RFC listener restart · Fix: WMS procedure update · Prevention: SM58/SMQS daily monitoring alert configuredWhat This Scenario Demonstrates: Three things worth noting. First -the 47 notifications were NOT lost. They sat safely in the queue and delivered in perfect order once the connection was restored. This is exactly why qRFC exists. Second -the fix required no ABAP changes, no system restart, no data re-entry. Once the connection was fixed and the queue was triggered, everything recovered automatically. Third -the real problem was a monitoring gap. 18 hours is too long to go without noticing a blocked queue in a production system. SM58/SMQS monitoring alerts should be part of every SAP Basis team's daily checklist, not an afterthought.
🎯 RFC Queue Processing -Interview Questions and Answers
These are the questions you will be asked in SAP Basis, integration, and senior functional consultant interviews when RFC comes up. The answers below use specific T-codes and real technical details -the kind that show an interviewer you have actually worked with RFC queues in production, not just read about them.
| Question | Strong Answer |
|---|---|
| What is the difference between tRFC and qRFC? | Both guarantee exactly-once delivery -the function is executed exactly once even if the call is retried multiple times. The difference is ordering. tRFC provides no sequence guarantee -calls may arrive at the destination in any order. qRFC guarantees that calls within the same named queue are processed strictly in the sequence they were placed. Use tRFC when order does not matter; use qRFC when sequence is critical -for example when a purchase order must arrive before the goods receipt that references it. In qRFC, if one call fails, all subsequent calls in the same queue are blocked until the failed call is resolved. |
| What does SM58 show and when do you use it? | SM58 shows all transactional RFC entries -tRFC and qRFC -from the current source system. Each entry shows the target destination, the function module called, the timestamp, the status (running, executed, CPICERR, error), and the error message for failed entries. You use SM58 when data is not reaching the target system. The first step is always to check SM58 for error entries. From SM58 you can drill into the error detail, test the SM59 RFC destination, and retry failed entries after fixing the root cause. Never delete a failed SM58 entry without understanding what data it contains -deleting it means the business data is permanently lost. |
| What happens when a qRFC queue entry fails? | When one entry in a qRFC queue fails, all subsequent entries in that same named queue are put on hold -they cannot be processed until the failed entry is resolved. This blocking behaviour is intentional: it prevents later messages from being processed before earlier ones, which would create data inconsistency in the target system. For example, if a purchase order notification fails, the goods receipts that reference it are held back -they should not arrive in the target before the PO they depend on. To resolve it: fix the root cause of the failed entry (connection problem, authorisation issue, ABAP error), retry the failed entry in SMQR or SM58, and all held entries then process automatically in order. |
| What are SMQR and SMQS and which system do you check each on? | SMQS is the outbound queue monitor -you check it on the SOURCE system to see messages waiting to be sent to the target. SMQR is the inbound queue receiver -you check it on the TARGET system to see messages that have arrived and are waiting to be processed. When data is not arriving on the target side: first check SMQS on the source to confirm the entries are being sent. If SMQS shows the entries have been dispatched, check SMQR on the target to see if they arrived but are stuck waiting for processing. One important detail: in SMQR on the target, inbound queues must be registered before they will be processed. A new queue name that is not registered will sit unprocessed indefinitely with no error -a silent failure. |
| Walk me through how you would troubleshoot an RFC connection failure. | In this sequence: (1) SM58 on source -confirm the entries are in CPICERR or ERROR status and note the target destination. (2) SM59 on source -test the RFC destination connection. If it fails, check whether the target system is running, verify the host name and port number, check network connectivity from OS level (ping/telnet). (3) SU01 on target -if SM59 test fails with logon error, check whether the RFC user password has expired or the user is locked. Reset password and update SM59 Logon tab. (4) SM21 on target -check system log for connection-level errors. (5) ST22 on target -if connection succeeds but ERROR still appears, check for ABAP short dumps. (6) After fixing root cause, retry the failed entries in SM58. |
| What is bgRFC and how is it different from qRFC? | bgRFC (Background RFC) is the strategic successor to tRFC and qRFC, designed specifically for S/4HANA. It has two modes -Unordered (like tRFC, guaranteed delivery but no sequence) and Ordered (like qRFC, guaranteed delivery AND sequence). The key differences from qRFC: bgRFC has better performance and scalability on high-volume systems, uses a unified monitor (SBGRFCMON instead of separate SM58/SMQR/SMQS), and has improved error handling and retry logic. SAP recommends using bgRFC for all new integration development on S/4HANA. For existing ECC systems running qRFC-based integrations like ALE/IDocs, there is no need to migrate -qRFC still works and is fully supported. |
The Interview Answer That Shows Real Experience: Every candidate who has studied RFC can explain the difference between tRFC and qRFC from a textbook. The answer that stands out names real T-codes (SMQS, SMQR, SM58, SM59, ST22), explains the SMQR registration requirement that trips up many first-time implementations, and describes the COMMIT WORK requirement that causes "why is the RFC not sending" questions. If you can also describe the Pooja Industries-style scenario -a blocked queue that silently piled up for 18 hours and recovered perfectly once the connection was fixed -you demonstrate understanding of how the system behaves in real production conditions.
📋 SAP RFC Queue Processing -Complete Reference
| Item | Type | What It Is | When You Use It |
|---|---|---|---|
| RFC | Concept | Remote Function Call -SAP's mechanism for one system to call a function module in another system over a network connection | Any cross-system integration in SAP -ECC to WMS, ECC to CRM, SAP to non-SAP systems |
| aRFC | RFC Type | Asynchronous RFC -fire and forget, no delivery guarantee, no ordering, fastest type | When you need parallel processing and can tolerate occasional message loss -monitoring notifications, non-critical updates |
| tRFC | RFC Type | Transactional RFC -guaranteed exactly-once delivery, persisted to ARFCSDATA table, no ordering guarantee | When you need reliable delivery but do not care about sequence -posting individual documents to subsidiary systems |
| qRFC | RFC Type | Queued RFC -everything tRFC does PLUS guaranteed sequence within a named queue. One failure blocks all subsequent entries in that queue. | When order matters -PO must arrive before GR, goods issue before stock transfer, any interdependent message sequence |
| bgRFC | RFC Type | Background RFC -the S/4HANA successor to tRFC and qRFC, with Unordered (NoQueue) and Ordered (Queue) modes | All new integration development on S/4HANA systems. SAP's strategic recommendation for new builds. |
| SM58 | T-Code | Transactional RFC Monitor -shows all tRFC and qRFC entries, their status, error messages, and allows retry of failed entries | First transaction to check when data is not reaching the target system. Daily monitoring essential in production environments. |
| SMQS | T-Code | qRFC Outbound Queue Scheduler -shows outbound queues on the SOURCE system, queue status, number of waiting entries, and scheduler settings | When qRFC data is not leaving the source system. Activate blocked queues after fixing connection problems. |
| SMQR | T-Code | qRFC Inbound Queue Receiver -shows inbound queues on the TARGET system, register new queue names, monitor inbound processing status | When data has arrived at the target but is not being processed. Also used to register new queue names for a new integration. |
| SM59 | T-Code | RFC Destinations -define and test connections to remote systems. Contains host, port, system number, logon user, and password for each destination. | Setting up new RFC connections and testing existing ones. Always test after changing logon credentials or network settings. |
| SBGRFCMON | T-Code | bgRFC Monitor -unified monitoring transaction for background RFC on S/4HANA. Replaces SM58/SMQR/SMQS in the modern landscape. | S/4HANA environments using bgRFC-based integrations -ALE, middleware, API-based communication |
| ARFCSDATA | Table | tRFC call data -stores the actual parameters of tRFC/qRFC calls before they are sent. SM58 reads this table. | Detailed investigation of failed tRFC entries -see exactly what data was in the call that failed |
| TRFCQOUT | Table | qRFC outbound queue entries -one row per queued RFC call on the sending side, with queue name, sequence number, and status | Debugging blocked outbound queues when SMQS display is not enough detail |
| ARFCIPCK | Table | qRFC inbound queue data -stores calls received on the target side waiting for processing in SMQR | Debugging stuck inbound queue entries when SMQR display does not show enough context |
| RFCDES | Table | RFC Destination definitions -contains all RFC connections configured in SM59 with their type, host, port, and logon data | ABAP programs check this table to verify whether an RFC destination exists before attempting a call |
| TID | Concept | Transaction ID -a unique identifier SAP generates for each tRFC call. Used to guarantee exactly-once execution even when the call is retried. | Understanding tRFC duplicate prevention. If the same TID arrives twice at the target, the second arrival is ignored. |
| Queue Name | Concept | A named string that groups related qRFC calls together and ensures they are processed in sequence. Related documents should share the same queue name. | qRFC design -use a key that links related messages (e.g., PO number) as the queue name suffix to ensure sequencing |
| COMMIT WORK | ABAP Statement | The ABAP statement that actually triggers sending of tRFC/qRFC calls. Without COMMIT WORK, calls stored in the database are never dispatched. | Debugging "RFC not being sent" issues -always verify COMMIT WORK is being reached in the program |
| SM21 | T-Code | System Log -records all system-level events including RFC connection attempts, authorisation failures, and work process errors | Check on the TARGET system when RFC calls arrive but the function module fails -look for errors at the RFC arrival timestamp |
| ST22 | T-Code | ABAP Dump Analysis -shows all ABAP runtime errors. When an RFC call causes a short dump on the target, ST22 shows the exact error and the code line. | When SM58 shows ERROR status and the connection test passes -the problem is in the function module execution on the target |
| SU53 | T-Code | Display last failed authorisation check -shows which authorisation object the RFC user is missing on the target system | When RFC fails with "authorisation error" -check SU53 on the target for the RFC user to find the missing permission |
📘 Related SAP Tutorials
SAP Real Scenarios -End-to-End
Complete business process walkthroughs across P2P, O2C, R2R, and PP -with T-codes, tables, and ABAP examples at every step.
Read TutorialSAP Note vs KBA vs HotNews
The real difference between a SAP Note, a KBA, and a HotNews -with real examples, SNOTE walkthrough, and search tips for the Launchpad.
Read TutorialSAP All Tables List
Complete reference to 100+ SAP database tables across all modules with key fields, descriptions, and primary keys.
Read Tutorial