RSA6 — Maintain DataSources in the Source System

RSA6 shows the active version of every DataSource generated in the source system: its extract structure, which fields are marked for selection, which are hidden from the extractor, inversion settings for reversal-relevant fields, and any customer append structure used to add fields beyond what SAP delivered. It is a source-system transaction, not a BW transaction, even when the source and BW live in the same client on an embedded S/4HANA setup. The one structural fact that explains most confusion: what a BW consultant sees in the DataSource repository inside RSA1 is a replicated copy of what exists in RSA6, not the live object. Editing field settings in RSA6 changes the source-system definition only; the BW side keeps its old picture until that DataSource is explicitly replicated.

A consultant opens RSA6 when a DataSource is not extracting a field that should be available, when a newly added custom field via an append structure needs to be marked for selection or hidden, or when troubleshooting why a delta-relevant field behaves oddly during extraction. It sits upstream of RSA3 (extraction test) and RSA7 (delta queue monitor) in the diagnostic chain: RSA6 confirms what the extractor is structurally capable of sending, RSA3 confirms what it actually sends for given selections, RSA7 confirms what has queued for delta. It is reached instead of RSA1 whenever the question is about the source-system definition itself rather than the BW-side model, and instead of LBWE whenever the DataSource in question is not one of the LO cockpit application-specific extractors.

Pull ROOSFIELD filtered on the DataSource name and check the selection and hide indicators for the field in question; a field flagged as hidden or not selected there will never leave the extractor regardless of what the BW transformation expects. Cross-check ROOSOURCE for the same DataSource to confirm the extract structure name matches what RSA3 reports it is using. If the field was added through a customer append, confirm the append structure actually contains a value by running RSA3 with a small selection and inspecting the raw output before assuming the BW side is at fault.

RSA6 still exists on S/4HANA and behaves the same way for DataSources built on classic extraction (LO cockpit extractors, generic extractors on tables or views). It has no Fiori equivalent because it is a back-office metadata transaction, not an end-user process. Extraction built on the newer CDS-view-based DataSources for embedded analytics scenarios bypasses RSA6 entirely, since those DataSources are generated directly from the CDS annotation rather than maintained as a classic extract structure, so RSA6 is only relevant when the classic extractor path is in play.

Ownership is technical BW or extraction-focused functional consultant, with ABAP involvement whenever an append field needs to be populated through a user exit or enhancement spot. A clean handover states the DataSource name, the exact field affected, whether the DataSource is delta-enabled and whether it has already been initialized, and whether the fix requires only a field attribute change or an ABAP enhancement.

RSA5 is the natural predecessor, since it activates a DataSource from business content before it ever appears in RSA6. RSA3 is the natural next step to confirm a field-attribute change actually produces data. RSA7 matters whenever the DataSource is delta-enabled, since a structural change there can desynchronize the delta queue from the new extract structure. LBWE is relevant specifically for logistics application extractors, where field selection is partly driven from the LO cockpit rather than RSA6 alone. RSA1 is where the replicated result must be checked after any RSA6 change.