RSA7 — Delta Queue Monitor for BW Extraction
RSA7 is the delta queue monitor run in the source system, showing per DataSource how many records and LUWs are waiting to be picked up by the next BW delta request, along with a status light for the last transfer. It proves whether data ever reached the queue before assuming a BW-side load, transformation, or process chain is at fault.
This page covers RSA7, the delta queue monitor used to diagnose missing or stuck delta data in BW extraction scenarios. It focuses on where RSA7 sits relative to LBWQ, LBWE, and the qRFC layer, and on the failure patterns that get misdiagnosed as BW-side problems when the real fault is upstream in the source system.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,209 words
Purpose
RSA7 is the delta queue monitor, run in the extraction source system, that shows the current content of the delta queue for every DataSource enabled for delta extraction. It displays, per DataSource, how many records and logical units of work (LUWs) are sitting in the queue waiting to be picked up by the next delta request from BW, plus a status light indicating whether the last delta transfer completed cleanly. The structural fact that explains most confusion: RSA7 shows queue content, not extraction logic. A DataSource can be correctly configured and full of source data, yet show nothing in RSA7 because nothing has written a delta record into the queue yet. For logistics extraction structures that step happens in LBWQ, fed by a job started through LBWE, and only lands in RSA7 afterward.
When it is used
Reached for whenever delta data appears missing or stuck in a BW target and the load itself in the BW-side monitor shows nothing obviously wrong, or shows zero records extracted for a period when business activity clearly happened. Used before deciding whether to run a repair full load, since a repair changes history and should not be the first move. Sits between the source-system extraction layer (LBWE/LBWQ for logistics, generic delta pointers, or ODP queues) and the BW request that consumes it. Consultants check RSA7 as a mid-incident triage step: confirm whether the queue actually holds the expected volume before assuming the DataSource, transformation, or process chain is broken. If RSA7 is empty when it should not be, the problem is upstream of BW entirely and no amount of retriggering the BW load will fix it.
How to use it in practice
- Call RSA7 in the source client that owns the DataSource, not the BW system, unless it is BW-on-itself extraction.
- Locate the DataSource row and read the status light plus the record and LUW counts.
- Double-click the row to open the queue detail list and see individual LUWs, their timestamps, and whether any are marked repeat.
- Compare the queue's oldest entry timestamp against the last successful delta load timestamp in the BW request monitor.
- If the queue is unexpectedly empty, check LBWE/LBWQ for logistics extraction or the relevant delta pointer setup before touching RSA7 itself.
- Do not delete or manually confirm queue entries from RSA7 as a first response; treat that as a last-resort, documented action.
Key data objects
- ROOSPRMSC - source-system-dependent control table for a DataSource, storing the delta process type and whether delta is active; RSA7 reads this to decide which DataSources to list and how to interpret their queue.
- TRFCQOUT / TRFCQIN - the underlying qRFC outbound and inbound queue tables where the actual delta LUWs physically reside before being dequeued to BW; the record and LUW counts shown in RSA7 come from this layer.
- ARFCSSTATE - qRFC status table recording whether a given LUW has executed, is retrying, or is stuck; relevant when an RSA7 entry shows a persistent repeat or error status that will not clear on its own.
How to prove it in the data
Open the RSA7 detail popup for the affected DataSource and note the technical queue name it displays, then check SMQ1 in the same source client filtering on that queue name; look at the count of LUWs and their status and timestamps (running, stopped, error). Cross-check against the corresponding BW-side request in RSMO for the same time window. If SMQ1 shows old, un-dequeued LUWs while RSMO shows the last request as completed and confirmed, the fault sits in the RFC connection or the qRFC scheduler, not in the DataSource definition or the transformation.
ECC vs S/4HANA
RSA7 exists unchanged as a GUI transaction on S/4HANA and BW/4HANA; classic delta queues for logistics and generic extraction still route through it exactly as before. For DataSources built on the ODP framework, including CDS-based extraction and some real-time replication scenarios, the delta queue concept is handled by the ODP layer and monitored separately, so an absent entry in RSA7 for an ODP-based source does not indicate a broken delta; that case is checked in the ODP-specific monitor instead. No Fiori app replaces RSA7; it remains SAP GUI only.
Common pitfalls and how to diagnose them
- Growing unconfirmed backlog: record and LUW counts climb steadily over several days without matching successful loads appearing in RSMO. Usually means the BW-side process chain stopped running or is failing before confirming the extraction. Fix by finding and rerunning the missed delta step in BW, not by clearing the queue.
- Reflex fix of deleting or reinitializing the queue: clearing RSA7 to make a stuck queue look healthy discards unconfirmed source records permanently. The correct sequence is to find why confirmation is not happening, either a failed request in RSMO or a dead RFC destination, fix that, then let the next scheduled delta run normally.
- Persistent repeat status: a single entry flagged repeat means the last delta request errored in BW and the same data will be resent on the next run; this is expected once. If it persists across several consecutive delta runs, the earlier failed request was never properly handled in the BW request monitor, which is blocking confirmation and should be resolved there, not in RSA7.
- Empty queue for logistics DataSources: an empty RSA7 for a LO Cockpit-based DataSource despite known transactional activity in the source usually means the LBWQ-to-RSA7 transfer job has not run, or the extraction structure was never activated in LBWE. This is checked in LBWQ and LBWE, not fixed inside RSA7.
- Shared queue across multiple BW targets: when more than one BW or BW/4HANA system extracts from the same source client, RSA7 aggregates by DataSource but confirmation is target-specific. A nonzero total does not mean every target is behind; check the target system column, not just the aggregate count, before escalating.
Whose problem this is
Functional BW/extraction consultant owns first-level triage: reading queue counts, the repeat status, and matching timestamps against the BW request monitor. Basis gets pulled in when the underlying RFC destination, qRFC scheduler, or background dispatcher is suspect, typically when LUWs are stuck in SMQ1/SMQ2 with no processing happening at all. A good handover states the DataSource, source system, the RSA7 status light, the oldest unconfirmed LUW timestamp, and whether the RFC connection tested cleanly.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/rsa7ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.