SAP Library / BW / Analytics / Cheat sheet
SAP BW / Analytics cheat sheet
15 objects in 3 groups. Each links to its full reviewed page.
T-Codes8
- RSA1RSA1 is the central BW workbench for building and maintaining the data flow: DataSources, transformations, DTPs, InfoProviders, InfoObjects, process chain links and source system connections. It is not one function but a shell over many object editors, so the most common source of confusion is an object that shows as saved in the tree but is not actually activated, leaving downstream loads working against an outdated definition.
- RSA3RSA3 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.
- RSA7RSA7 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.
- ODQMONODQMON is used to monitor Operational Delta Queue subscriptions, requests and retained delta data used by ODP-based extraction. It is most useful when BW/ODP consumers miss deltas, queues grow, subscriptions are stuck, or extractor retention must be analyzed. For reliable support work, start with the exact system, client, user and business context, then use the transaction's own status, document or log evidence before changing configuration or data.
- RSPCRSPC is the BW transaction for building, activating, scheduling, and monitoring process chains — the sequences of loads, transformations, activations, and change runs that move and prepare data in the warehouse. The one fact that explains most confusion: a chain is not a linear script but a tree of background jobs, where each node's successor fires based on the predecessor's success, failure, or always-condition.
- RSRTRSRT is the BW query monitor transaction used to execute a query directly on the server, bypassing the reporting frontend, so that generated SQL, cache behavior, aggregate usage, and OLAP runtime settings can be inspected. It is the primary tool for isolating whether a reporting problem originates in the query itself or in the frontend rendering it.
- SMQ1SMQ1 displays the outbound queued RFC (qRFC) queues on the system where data originates, showing every LUW waiting to be transferred to a receiving destination in strict FIFO order per queue name. It is the first place to check when BW delta extraction, LO cockpit postings, or any qRFC-based transfer appears stuck before it even leaves the source system.
- SMQ2SMQ2 displays inbound qRFC queues on the receiving system - the entries (LUWs) waiting to be processed there. It is the mirror image of SMQ1, which shows the same transport from the sending side. Used when delta loads, IDoc transfers, or extraction feeds into BW appear stuck despite the source system reporting the data as sent.
Key Tables5
- ROOSOURCEROOSOURCE stores the header metadata of a DataSource as known to the source system: technical name, logical system, application component, object version, and the delta process type assigned to it. It is the source-system counterpart of the BW-side DataSource definition and is what BW reads during replication.
- ROOSFIELDROOSFIELD stores one row per field of a DataSource's extract structure: the field name, its position, whether it is part of the key, and the technical attributes (selection, hierarchy, lowercase) that control how that field behaves during extraction. It is metadata replicated from the source system, not extracted business data, and it is read by joining on the DataSource name held in ROOSOURCE.
- RSREQDONERSREQDONE is a BW status management table that records, per request and per InfoProvider, which lifecycle steps (load, activation, rollup, compression, aggregate fill) have been completed. It does not store data content or record counts, only completion flags used by the system to decide whether a request is safe for further processing or reporting.
- RSPCCHAINRSPCCHAIN is the BW header table for process chains: one row identifies a chain by its technical ID and version (active or modified). It does not store the step sequence, execution history, or run status of a chain - those live in separate node, variant, and log tables. It is a design-time metadata table, read through transaction RSPC rather than queried directly in most troubleshooting.
- RSPCPROCESSLOGRSPCPROCESSLOG stores one row per individual process step executed inside a BW process chain run - each load, DTP, attribute change run, index deletion, or other chain step gets a log entry with a status flag, timestamp, and log ID. It is the table behind the process chain monitor's traffic-light display and the first place to check when a chain step shows red, yellow, or appears stuck.
Common Issues2
- Data load failing in the process chainA process chain load fails most often because of a source system connection drop, a lock held by an overlapping chain run, an invalid character or referential integrity problem surfacing in the transformation, or a background authorization change that broke the batch user. The chain monitor log and the individual DTP monitor together identify which of these it is; guessing and repeating the request wastes a load window and often masks the real cause.
- Delta extraction missing records after an initRecords go missing after an init almost always because of a timing gap between when the setup table was filled and when the delta queue actually started collecting changes, or because the init selection was narrower than the full load scope. The fix is a scoped repair full load for the affected window, not another reinit, which resets the pointer but never recovers the lost records.