RSA3 — Extractor Checker for BW DataSources
RSA3 is the extractor checker run in the source system. It calls the DataSource's extraction logic directly and shows the records it returns, completely bypassing BW transformations, DTPs, and the delta queue's normal consumption path except when the test itself is run in delta mode, in which case it behaves like a real load and can move the delta pointer.
RSA3 tests a DataSource's extraction output in isolation from BW, which makes it the first stop when deciding whether a failed or empty load is a source-side or BW-side problem. This page covers how it is actually used in triage, what it reads, and the pitfalls that trip up consultants who treat a clean RSA3 run as proof the whole load will work.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,160 words
Purpose
RSA3 executes a DataSource's extraction function module inside the source system and displays whatever records it returns, without sending anything to BW. The structural fact that explains most confusion: RSA3 has no knowledge of BW at all. It does not run start routines, transformations, DTP filters, or target activation. A clean, full result set in RSA3 only proves the extractor itself can produce records from the underlying source tables or view under the selection given; it says nothing about whether those records will survive transformation rules, routines, or target-side checks once loaded through RSA1 or RSPC. Consultants who forget this treat RSA3 as an end-to-end test and are then surprised when the same DataSource fails or produces different data once actually loaded into BW.
When it is used
RSA3 is reached for early in triage, before opening the BW load monitor, whenever a load is missing records, returning zero rows, or producing data that looks wrong at the target. Running RSA3 with the same selection used by the failing load isolates whether the problem originates at the source (wrong table content, broken generic extraction, extractor logic) or downstream in BW (transformation, routine, filter, or target definition). It is also used during initial DataSource setup to confirm a newly activated or newly enhanced extractor returns the expected fields and volume before wiring it into a transformation and DTP. It is not used to load BW targets, monitor deltas, or manage the extraction queue; those are RSA1, RSA7, and LBWQ respectively.
How to use it in practice
- Open RSA3 in the source system, not the BW system, since it operates locally against the extractor.
- Enter the DataSource technical name and choose the extraction mode to test (full, delta, or delta init) matching what production actually uses.
- Raise or lower the number of data records field before executing; the default limit truncates output and is easy to mistake for the extractor returning too little data.
- Execute and review the returned records and field list against what the target expects.
- Use the debugger option if the extraction is a user exit or generic view-based extraction returning unexpected values.
- For delta-capable DataSources, check afterward whether the delta pointer has moved before assuming it is safe to repeat the test.
Key data objects
- ROOSOURCE - DataSource header definition; extraction mode, generic delta settings, and which function module RSA3 calls.
- ROOSFIELD - field list and technical attributes of the DataSource; determines the columns shown in the RSA3 result grid.
- Delta queue content (viewable through RSA7) - for delta-capable DataSources, RSA3 run in delta mode reads and can consume entries here exactly as a production delta load would.
- Extraction queue or update queue tables behind LBWQ - for logistics cockpit DataSources, this is the actual record source RSA3 pulls from in delta mode.
How to prove it in the data
To confirm RSA3 and a production load disagree, run RSA3 in full mode with the identical selection criteria used by the DTP or InfoPackage and note the record count and key field values. Separately check the delta queue in RSA7 for the same DataSource to see queued record counts before and after the RSA3 test. If counts diverge from what the BW load monitor (RSMO) shows for the same request, the discrepancy sits in the transformation or routine layer, not in extraction.
ECC vs S/4HANA
RSA3 still exists and behaves the same way on S/4HANA for classic DataSources such as LO cockpit extractors and generic extractors defined against tables or views. It is not meaningful for extraction paths built on the operational data provisioning framework or on CDS-based extraction, where testing is done through the extraction context in the source rather than through RSA3's function-module call. There is no Fiori app replacing RSA3; it remains a classic SAP GUI transaction.
Common pitfalls and how to diagnose them
- False confidence from a clean test: a successful RSA3 run only validates the extractor, not the transformation, start routine, or target. Do not close a ticket on RSA3 output alone; reproduce the same selection through an actual DTP test run before declaring the DataSource healthy.
- Delta pointer displacement: running RSA3 in delta mode against a live DataSource behaves like a real delta load and advances the delta pointer or consumes queue entries. Doing this against a production source system without coordination creates a gap that the next scheduled production delta will never pick up. Test deltas only in a non-production source system, or accept that a production delta test must be immediately reconciled with a repair full load.
- Record limit masking data: the default row limit on the RSA3 selection screen truncates output silently. An analyst reading zero or few rows and concluding the extractor is broken, when the limit was simply too low, is a recurring mistake. Raise the limit before drawing conclusions.
- Authorization and short dumps: RSA3 executes under the calling user's authorizations against the underlying source tables. A missing authorization produces an empty result or a dump that looks identical to a genuine no-data condition; check the return message and system log before assuming the extractor logic itself is at fault.
- Generic extraction selection mismatch: for view- or table-based generic DataSources, selection criteria entered in RSA3 do not always push down to the source the same way the production DTP selection does, especially with OR conditions or complex ranges. A different result count between RSA3 and the actual load can be a selection translation issue rather than an extractor bug.
Whose problem this is
RSA3 is a functional BW consultant's diagnostic tool, run against a source system that is typically owned by another functional team (SD, MM, FI). A good handover before running a delta test in production states the DataSource name, the mode tested, and explicit confirmation of whether the delta pointer or queue was touched, so the source-side team can assess load impact.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tcodes/rsa3ERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.