RSPCCHAIN table — Process Chain Header Table in BW

One row in RSPCCHAIN represents the header of one process chain at one version, active or modified, in one client. A process chain built in the chain maintenance tool is a directed graph of processes - a start process plus a network of dependent load, DTP, activation, and custom-ABAP steps - but RSPCCHAIN itself only anchors that this chain exists under a given technical name and carries chain-level attributes rather than the graph itself. Every chain has an active-version row that the background scheduler actually runs, and while someone is editing the chain in the maintenance transaction a modified-version row also exists until it is activated. Deleting a chain removes its header row here along with its dependent definition and log tables, though metadata buffers may lag behind the deletion.

Always restrict on MANDT. CHAIN_ID is the natural and only meaningful selection - get the exact technical name from the chain maintenance transaction before querying anything, since chain IDs are not descriptive. Restrict VERSION to A for what actually runs; only pull M when specifically investigating whether an edit was ever activated. The table itself is small, one or two rows per chain, so it is never a performance concern on its own; if a selection against process-chain data feels slow, the volume is almost certainly in the log table, not here.

Symptom: a chain edited yesterday does not appear to run the new logic today. Select RSPCCHAIN by the exact CHAIN_ID with both VERSION values. If a row exists for M but not for A, or the A row's content clearly predates the edit, the change was saved but never activated in the chain maintenance transaction, so the scheduler is still executing the last activated definition, not the visible one on screen.

The process chain concept and its maintenance transaction carried forward into S/4HANA-based BW and into BW/4HANA largely unchanged conceptually, and RSPCCHAIN as a design-time header table remains part of that framework. Because it is pure metadata rather than reportable transactional or master data, it is not typically exposed through a compatibility CDS view the way InfoProvider or extraction tables are. Version-specific structural changes to the table across BW/4HANA generations are not something to assert with confidence without checking the specific release in front of the reader.

The BW competency center or basis-adjacent scheduling team that owns process chain design and job scheduling owns questions against this table. Functional consultants raise the symptom - a chain step that did not fire - but resolving it usually means someone with authorization in the chain maintenance transaction checking activation status and the background job, not a raw select against RSPCCHAIN.

RSPCPROCESSLOG records the run-level log entries for each execution of a chain identified by CHAIN_ID. RSREQDONE records the individual load requests that a chain's steps trigger, which is the actual link between a chain run and the InfoProviders it touches, typically RSDODSO or RSDCUBE targets. The chain maintenance transaction (RSPC) is what writes and activates RSPCCHAIN; nothing else should be modifying this table directly.