RSPC — Process Chain Maintenance and Monitoring

RSPC is where process chains are defined and run. A chain is a directed graph of process nodes — InfoPackage or DTP execution, attribute change run, DSO activation, index or aggregate rebuild, PSA deletion, and so on — connected by successor links that fire on success, failure, or unconditionally. Each node, when triggered, is dispatched as its own background job rather than executed inline, which is the structural fact behind most confusion: the chain's green/red/yellow status in the monitor is a summary built from the underlying job and process log entries, not a live state. When that log update lags or a job sits queued on a busy server, the chain display and the actual data state disagree, and consultants chase the wrong symptom.

RSPC is reached for two situations: building or modifying the scheduled sequence of a nightly or intraday load, and diagnosing why that sequence failed or stalled overnight. It sits downstream of extraction and transformation design, which is done in RSA1, and upstream of query performance, which is a separate concern entirely. During incident triage, a consultant opens RSPC first to see which node failed, then drops into RSMO to inspect the actual request-level detail of that node, since RSPC's own log view often just shows a status icon and a generic message. RSPC is not used to fix a broken transformation or extractor — those are fixed at their source and the chain is simply restarted or repaired.

In SE16, query RSPCPROCESSLOG filtered by the chain ID and the date/time window of the failing run; check the status and return code for the specific process instance rather than trusting the chain overview icon. Take the job name shown in that log entry's popup and look it up in TBTCO/TBTCP filtered by job name and date to see whether the job actually finished, is still scheduled, or was released and never picked up by a work process. If RSPCPROCESSLOG shows success but the chain monitor still shows red, the monitor cache is stale and a refresh, not a rerun, is the fix.

RSPC works the same way in embedded BW on S/4HANA and in BW/4HANA as the transaction for building, activating, and repairing process chains. Some ECC-era process types tied to classic extractors no longer apply since those source objects are gone, but the chain mechanics — nodes, successor conditions, background job dispatch — are unchanged. BW/4HANA adds Fiori-based process chain monitoring apps for a more real-time view of running chains, but RSPC remains the tool for actually editing and repairing them.

This is primarily a BW/BI functional consultant's transaction for chain design, scheduling, and first-line diagnosis. Basis gets involved when the root cause is background job capacity, server group configuration, or work processes exhausted at the job scheduling layer rather than in the chain logic itself. A clean handover includes the chain ID, the failing run's log/job identifiers, the specific node and process type involved, and whether the underlying object was tested standalone.

RSA1 is the natural predecessor read, since it is where the extractors, transformations, and DTPs that a chain merely sequences are actually designed and fixed. RSMO is the companion tool for any failing chain node, since it gives request-level detail that RSPC's own log view does not. RSA7 is worth checking when a chain's delta-based load node fails, since a stuck or overfull delta queue on the source side produces exactly the kind of chain failure that looks like a chain problem but is not one.