RSMO — BW Data Load Request Monitor

RSMO opens the monitor for a specific data load request in BW or embedded BW on S/4HANA. It renders the request as a tree of steps - extraction from the source, transfer into PSA, and further processing into the InfoProvider - each carrying its own traffic light. The structural fact that causes most confusion: the overall traffic light shown at the top reflects the worst status among the individual steps, not the current or final step. A red overall status can mean the last step failed while extraction and PSA staging succeeded cleanly; a yellow status can mean simply still running, or it can mean a job died without RSMO ever being told to turn red. RSMO is purely a viewer over status tables, job logs, and PSA content combined into one screen. It cannot repair data, restart a queue, or correct a transformation; those actions happen elsewhere.

RSMO is reached for the moment a scheduled load in a process chain or InfoPackage turns red, turns yellow and stays there too long, or produces a record count that looks wrong. It is the natural first stop before opening SM37 for the job log, SM58 for stuck tRFC calls, or ST22 for a dump, because RSMO names the exact step that failed and links directly into the relevant detail. In a process chain, double-clicking a failed load node in the chain log opens RSMO for that request automatically, so most consultants never call it cold. It is not used to change or reload data - once the failing step is identified, the actual fix is executed through the InfoPackage, the DTP, or by repairing and restarting the process chain node, not from within the monitor screen itself.

To confirm a request is genuinely stuck rather than just slow, check RSREQDONE for the request's technical name, its status flag, and its last-update timestamp; if the timestamp is old and the status is not a final value, the extraction or processing job died without ever reporting back to the monitor. Cross-check the extraction job name shown in the RSMO header against the job log in SM37 for the same time window. If the request is a delta load fed by a queue, confirm entries are actually present and processed in the underlying delta or extraction queue rather than assuming RSMO's own display is wrong.

RSMO exists unchanged in BW/4HANA and in embedded BW inside S/4HANA, functioning as the same per-request monitor over the same tree structure. It does not apply to native S/4HANA CDS-based reporting extraction that bypasses BW entirely. Newer chain-level monitoring can surface through Fiori-based process chain monitoring apps, but the request-level detail from those apps still opens into the classical RSMO screen underneath for the actual step diagnosis.

First-line ownership sits with the functional BW or analytics consultant reading the monitor daily. Escalate to Basis when the root cause is RFC connectivity, background job scheduling capacity, or infrastructure-level queue processing. A useful handover states the request's technical name, target InfoProvider, source system, the exact step that failed, and any dump ID already found in the job log.

Read rsa1 next for the workbench where InfoPackages and DTPs are built and request history is browsed in context. Use rsa3 when the extraction step itself, rather than the BW side, is suspect. Follow rspc for the process chains that schedule loads and link straight into RSMO on a failed node. Check smq1 and smq2 when a delta-queue-based extraction stalls at the transfer step, and lbwq when a logistics extraction structure is the underlying queue feeding that delta.