RSA1 — RSA1 Data Warehousing Workbench

RSA1 opens the Data Warehousing Workbench, a tree-based cockpit that gives access to every BW metadata object type: InfoObjects, DataSources, InfoSources, transformations, DTPs, InfoProviders (InfoCube, DSO, ADSO, CompositeProvider), Open Hub destinations, source systems and the transport connection. It does not store data itself; it is the maintenance UI over a large set of metadata tables and generated data tables. The structural fact that explains most confusion is that RSA1 is a shell, not a single object editor: the same DataSource or InfoProvider can be reached from several tabs, edited, saved, and left in a 'modified but not activated' state. A save in RSA1 is not the same event as an activation, and loads or transformations built on top of a modified-but-inactive object will fail or behave inconsistently until that object is explicitly activated.

RSA1 is reached whenever a data flow is being built, extended or repaired: adding a field to an extraction, creating a new InfoProvider, wiring a transformation between a DataSource and a target, or checking whether a DataSource has been replicated from its source system. It sits upstream of the day-to-day monitoring and testing tools. A consultant uses RSA1 to design and connect objects, then switches to RSA3 to test extraction at the source, RSMO to watch a specific request load, or RSPC to sequence and schedule the finished chain. Fiori apps exist for analytics consumption and for some administration tasks, but building the data flow itself is still done in RSA1 (or in the BW modeling tools in Eclipse on BW/4HANA), not in a Fiori app.

To prove an object is stuck in a modified, unactivated state, run SE16 on the relevant metadata header table (RSDCUBE for a classic InfoCube, or the equivalent ADSO/DSO header table) filtered on the technical object name, and inspect the object version field: a value of A means active, M means modified but not activated, D means delivered-only. If the object a DTP points to shows M instead of A, the DTP is running against a stale active version regardless of what the RSA1 tree displays. To confirm a DataSource is out of sync with its source, check ROOSOURCE for the same object version pattern against the source system logical name, and compare the field list there with what the transformation currently maps.

In S/4HANA with embedded BW, RSA1 still exists and is used the same way for administration of embedded analytics data flows. In a standalone BW/4HANA system, RSA1 remains available but the strategic tool for modeling is the Eclipse-based BW modeling tools, and classic InfoCubes are no longer supported as a target object; ADSO and CompositeProvider take their place. There is no single Fiori app that replaces the full RSA1 workbench; monitoring and some administration tasks have Fiori equivalents, but data flow construction is still done through RSA1 or the Eclipse tooling.

Data flow design, transformation logic and InfoProvider modeling are functional BW consultant work. ABAP involvement is needed only when a custom extractor, start routine or expert routine requires code changes. Basis is needed when DataSource replication fails due to the RFC connection to the source system. A clean handover states the technical object names involved, the source system logical name, and the current activation status (object version) of each object in the chain.

RSA3 tests extraction at the source before it is trusted inside a BW transformation, and is the first place to check when a DataSource built in RSA1 returns no records. RSD1 handles InfoObject maintenance that RSA1 references but does not itself edit in depth. RSMO monitors the request-level outcome of a DTP created in RSA1. RSPC sequences and schedules the DTPs and activation steps built in RSA1 into a process chain. RSRT is useful once the data flow is loaded, to isolate whether a reporting issue is a query problem rather than a data flow problem.