LBWQ — Extraction Queue Maintenance for LO Cockpit Delta
LBWQ shows and manages the extraction queue used by the 'queued delta' update method in LO Cockpit extraction. Posted documents write records into a named queue (MCEX*) instead of straight into the BW delta queue. A scheduled collective run job later moves that queue content into RSA7. LBWQ is where a consultant checks whether that handoff has happened.
This page covers LBWQ, the transaction for inspecting the LO extraction queue that sits between document posting and the BW delta queue when the queued delta update method is active. It focuses on how the queue technology actually works underneath, what backlog and error entries really mean, and where the fix belongs between functional, Basis and BW roles.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,161 words
Purpose
LBWQ displays and manages the extraction queue used by the queued delta update method for LO Cockpit extractors (SD, MM, and similar logistics applications). When a document is posted, the update module writes the extraction-relevant data into a named queue (prefixed MCEX) instead of writing straight into the BW delta queue. A background collective run job, scheduled through LBWE, later reads that queue in sequence and pushes the entries into RSA7. The structural fact that explains most confusion: this queue is not its own bespoke table. It runs on the same underlying qRFC outbound queue technology as SMQ1, filtered by queue name convention. That is why an entry can be stuck for pure RFC/queue-administration reasons that have nothing to do with the extractor logic itself.
When it is used
LBWQ is reached whenever an LO extract structure is configured in LBWE for the queued delta update method rather than direct delta or unserialized V3. It gets used to check whether posted documents are actually waiting to be collected before they reach BW, particularly during initial setup testing of a new extract structure, during a cutover window, or when a downstream data load in BW is missing records that business users insist were posted. It is also used to manually trigger or verify the collective run when the scheduled background job has not fired or has failed. It is not the tool for BW-side delta monitoring (that is RSA7), for load monitoring (RSMO), or for extractor field-level testing (RSA3). There is no Fiori app replacing it; this remains a classic backend housekeeping transaction on both ECC and S/4HANA.
How to use it in practice
- Run LBWQ and review the list of queue names (MCEX* prefix) with their current entry counts.
- Drill into a specific queue name to see the individual LUWs (logical units of work) and their status, in the order they were created.
- If the backlog is large or growing, check LBWE to confirm the collective run job for that application is actually scheduled and running successfully.
- If the job exists but is stalled, run or restart the collective run (via LBWE job control) to push queue content into RSA7.
- If specific entries show an error status, escalate to SMQ1/SMQ2 level diagnosis rather than deleting entries in LBWQ, since deletion here is destructive and not reversible.
Key data objects
- ARFCSSTATE (or equivalent qRFC queue status table) - holds the status, sequencing and queue name of each LUW; this is the same infrastructure table SMQ1 reads.
- ARFCSDATA (or equivalent qRFC payload table) - holds the actual extraction payload data for each queued LUW before it is unpacked into RSA7.
- The LO extract structure setup maintained via LBWE - determines which application writes into which MCEX* queue and which update method is active; nothing is written here directly by LBWQ itself, LBWQ only reads and manages what other processes wrote.
How to prove it in the data
Compare the queue entry count shown in LBWQ for the relevant MCEX* queue against the number of records expected from recent document postings in the source application, and against what has actually landed in RSA7 for the corresponding datasource. If LBWQ shows a growing count and RSA7 is flat, the collective run job is the point of failure, not the extractor or the BW load. If LBWQ is empty but business users report missing data, look upstream at the update method configuration in LBWE, since the documents may never have been queued at all.
ECC vs S/4HANA
LBWQ behaves the same on S/4HANA wherever the queued delta update method is still in use, which happens mainly through compatibility scenarios for existing LO Cockpit extractors carried over from ECC. For new extraction requirements, SAP steers toward CDS-based extraction and the ODP framework rather than the LO Cockpit, so newly built datasources typically do not touch LBWQ at all. There is no Fiori equivalent; this remains a classic SAP GUI backend transaction on both platforms.
Common pitfalls and how to diagnose them
- Unbounded queue growth - the collective run job is not scheduled, is scheduled with too long an interval, or is failing silently; check the job log for the collective run before touching anything in LBWQ.
- Blocked queue due to one failed LUW - queues are processed FIFO per queue name, so one entry in error status blocks every entry queued after it for that same queue, even though those later entries look healthy; find and resolve the first failing LUW, not the visible pile-up.
- Mistaking LBWQ backlog for lost data - consultants sometimes see nothing in RSA7 and assume the extraction failed and needs to be re-triggered, when the data is sitting safely in LBWQ waiting on the collective run; re-triggering the extraction on top of this creates duplicates once the queue eventually processes.
- Deleting queue entries directly - this permanently discards the extraction payload for those documents with no automatic recovery; the source documents will never resend that data unless a full or delta re-init is performed afterward.
- Wrong queue name checked - an application can have multiple queue variants (numbered suffixes), and checking the wrong one gives a false impression that the queue is empty when the real backlog sits under a different name.
- High-volume overhead - many small LUWs from high posting volume can make the collective run slow or resource-heavy; if this becomes chronic, the real fix is reconsidering the update method (direct delta or unserialized V3) rather than tuning the collective run job further.
Whose problem this is
Functional (SD/MM/logistics) owns identifying which business documents are driving queue volume and the business impact of delayed BW visibility. Basis or the BW technical team owns the collective run job scheduling, RFC destination health, and qRFC infrastructure diagnosis. A good handover includes the queue name, the ID of the first failing LUW if any, the job log of the collective run, and a side-by-side entry count from LBWQ versus RSA7 for the same datasource.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/lbwqERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.