# SAP NMS Weekly Monitoring (ST22 / SM37 / BD87)
Each week the NMS SAP system is checked for signs of trouble: ABAP runtime errors (short dumps), the state of background jobs, and IDocs stuck in the interface monitor at statuses 02 and 51. This automation logs into SAP as the monitoring user, runs each of those transactions for a Thursday-to-Thursday reporting window, exports each result list to a file on the automation server, reformats it into the NMS weekly monitoring report workbook, and emails the responsible analyst a completion notice naming any transaction that failed. The business outcome is a consistent, evidenced weekly health record of the NMS system without an analyst having to drive SAP GUI by hand.
## At a glance
| | |
|---|---|
| **Trigger** | Started externally. Each of the four monitoring routines begins at its own start point and logs straight into SAP; there is no timer, file watcher or scheduler artefact in the source. Assume a scheduler entry or manual launch. |
| **Frequency** | Weekly, on a Thursday-to-Thursday window. This is inferred from the routine names, the email subjects ("…Weekly Job Execution") and the date-calculation routine, which computes values called `Thursday` and `CurrentThursday` and derives the From/To dates from them. The exact schedule is not recorded in the source. |
| **Systems used** | SAP GUI (system **NRP**, user **qx68203**); Microsoft Excel; the local folder `C:\BluePrism\data\SAP_NMS\`; SMTP email; a shared electronic to-do list ("work queue") named **NMSWeeklyWorkQueue** |
| **Inputs** | A list of SAP transaction codes to run (held in a variable called `TCodes`); SAP credentials held inside the automation; the reporting window dates, which are calculated rather than supplied |
| **Outputs** | Four SAP list exports in `C:\BluePrism\data\SAP_NMS\` (`NMS_Weekly_ST22`, `NMS_Weekly_SM37`, `NMS_Weekly_BD87_1`, `NMS_Weekly_BD87_2`); the formatted NMS weekly monitoring report workbook; one completion email per transaction; a logon-failure email if SAP cannot be reached; completion/exception records against each item in NMSWeeklyWorkQueue |
| **Typical run** | Four separate routines (ST22, SM37, BD87_02, BD87_51). As written, **each routine handles exactly one transaction per run** — see stage 6, step 2. Individual SAP waits total roughly one to two minutes per transaction. Overall duration not recorded in the source. |
| **Owner** | Not recorded in the source. The only named person anywhere is **s.jyothi.avadhanam@accenture.com**, who is both sender and recipient of every email — apparently the developer's own address. |
## Before you start
- **SAP access.** You need the SAP GUI installed and the logon pad entry for system **NRP** visible. The automation signs in as user **qx68203**. The password is held in a variable inside the automation; its value and storage location are not visible in the source, so confirm with the process owner that the credential is current before a run.
- **The SAP session must be free.** The logon routine has explicit handling for an "Already Logged In" pop-up, which means a stale session elsewhere will change the logon path. Close any existing SAP session for qx68203 first.
- **The output folder must exist and be writable:** `C:\BluePrism\data\SAP_NMS\`. Previous exports with the same names will be overwritten — the ST22 routine actively clicks **Yes** on the "Confirm Save As" overwrite prompt.
- **Excel must be closed** before the run. Several Excel routines force-close the application at the end, and the automation opens its own Excel session; a workbook left open by a user can interfere.
- **The transaction list must be loaded.** The variable `TCodes` is what gets pushed onto NMSWeeklyWorkQueue at the start. The source does not show how it is populated, so verify with the owner what should be in it before launching.
- **Access to the to-do list NMSWeeklyWorkQueue**, so you can see which transactions completed and which were flagged as exceptions after the run.
- **Mailbox access** for s.jyothi.avadhanam@accenture.com, or a forwarding rule, so someone actually reads the completion and failure notices.
## Procedure
Throughout this procedure, "work item" means one entry on the shared to-do list NMSWeeklyWorkQueue, representing one SAP transaction to be run and later marked done or failed.
### Stage 1 — Log on to SAP
1. Launch the SAP GUI and wait about 7 seconds for the logon pad.
2. Select system **NRP** from the logon pad (the automation double-clicks the entry).
3. Wait up to 10 seconds for the logon window. **If the logon window does not appear within 10 seconds, then** raise a system exception "Window doesn't exist" — this is picked up by the logon recovery in the Exceptions table.
4. Click the **User** field and type the user ID **qx68203**; click the **Password** field and type the password; click **OK**.
5. **If a "System Message" pop-up appears after logon, then** activate it and click **OK**, then carry on.
6. **If SAP reports the user is already logged in, then** activate the "Already Logged In" window, set an internal flag recording this, and carry on. The flag is returned as the logon message.
### Stage 2 — Load the week's transaction codes onto the work list
1. Add the contents of `TCodes` to the shared to-do list **NMSWeeklyWorkQueue**. Each entry represents one SAP monitoring transaction to be executed.
2. Priority, tags, deferral and initial status are not set in the source — the items go on with platform defaults.
### Stage 3 — Claim the next transaction to run
1. Take the next unworked item from **NMSWeeklyWorkQueue**, capturing its reference, its payload and its status.
2. **If the item reference is blank (nothing left to work), then** skip all SAP execution and go straight to Stage 7 (close SAP and send the completion email).
3. **If an item was returned, then** proceed to the relevant transaction in Stage 4. Which transaction runs is fixed per routine, not chosen from the item's contents: the ST22 routine always runs ST22, the SM37 routine always runs SM37, and so on.
### Stage 4a — Run ST22 (ABAP runtime errors / short dumps)
Applies to the ST22 weekly routine.
1. Enter transaction code **`/nst22`** in the command field and press OK.
2. Calculate the reporting window: the date routine computes a Thursday reference and derives a **From Date** and **To Date** from it.
3. Wait up to 10 seconds for the ST22 selection screen. **If it does not appear, then** raise "From Date Doesn;t exist" (the developer's own wording).
4. Click the **From Date** field, select all existing text, and type the calculated From Date. Repeat for the **To Date** field.
5. Click the **User** field, select all, and type **`*`** (all users).
6. Tick the three option boxes: **Exception**, **Program Affected**, **Program Components**.
7. Click **Start** and wait up to 25 seconds for the results list. **If the list does not appear, then** raise "REsults window doesn't exist".
8. Click **Export**, then **Spreadsheet**. Wait up to 10 seconds for the spreadsheet-type dialog; **if it does not appear, then** raise "FileType window doesn't exist". Click **OK**.
9. Wait up to 10 seconds for the Save pop-up; **if it does not appear, then** raise "Save popup doesn't exist". Write the file name **`C:\BluePrism\data\SAP_NMS\NMS_Weekly_ST22`** and press **Save**.
10. **If a "Confirm Save As" overwrite prompt appears, then** activate it and click **Yes**. If it does not appear, carry on regardless.
11. Force-close any Excel instance, then pass the file **`NMS_Weekly_ST22.MHTML`** to the report-formatting step (Stage 5).
### Stage 4b — Run SM37 (background job overview)
Applies to the SM37 weekly routine.
1. Enter transaction code **`/nsm37`**.
2. Complete the job selection screen. The screen fields the automation is wired to are **Job Name**, **User**, the status checkboxes **Released / Ready / Active / Finished**, and **From Date SM37** / **To Date SM37**. *The source listing for this page is truncated, so the exact values typed into Job Name and User, and which status boxes are ticked, cannot be confirmed from the outline — verify against a live run before rebuilding.*
3. Press **Execute** and wait for the results window.
4. Export the results list via the **Extras → Export** path shown in the mapped screen elements, saving to **`C:\BluePrism\data\SAP_NMS\NMS_Weekly_SM37`** using the Save As dialog's File Name field and Save button.
5. Pass the exported file to the report-formatting step (Stage 5).
### Stage 4c — Run BD87 (IDoc status monitor, statuses 02 and 51)
Applies to the two BD87 routines.
1. Enter transaction code **`/nbd87`**.
2. Run the IDoc status monitor once per status. The BD87 routine is invoked with the label **`BD87_02`** by one routine and **`BD87_51`** by the other.
3. The two output file stems configured are **`C:\BluePrism\data\SAP_NMS\NMS_Weekly_BD87_1`** and **`C:\BluePrism\data\SAP_NMS\NMS_Weekly_BD87_2`**. *Which stem belongs to status 02 and which to status 51 is not stated in the source, and the BD87 page's selection-screen steps are truncated — confirm before relying on the file names.*
4. Pass the exported file to the report-formatting step (Stage 5).
### Stage 5 — Format the export into the NMS weekly monitoring report
1. Hand the exported file to Excel. The report-update routine waits 5 seconds, then selects the correct formatting macro based on the transaction:
| Transaction | Macro used |
|---|---|
| ST22 | ST22 Weekly Code |
| SM37 | SM37 Weekly Code |
| BD87_1 | BD87 Weekly Code |
| BD87_2 | BD87 Weekly Code (same macro for both BD87 files) |
2. The macro lays the exported data into the NMS weekly monitoring report. *The report workbook's name, location and sheet layout are not stated in the source.*
3. Wait a further 5 seconds, then close Excel.
### Stage 6 — Mark the transaction complete
1. Record the claimed work item in **NMSWeeklyWorkQueue** as successfully completed.
2. **Note a likely defect:** after marking the item complete, each routine goes directly to closing SAP. There is **no loop back to "claim the next item"**, so as written a single run processes exactly one work item, no matter how many were loaded in Stage 2. Flag this to the process owner; if multiple transactions per run are intended, the routine needs a loop.
### Stage 7 — Close SAP and notify
1. Close the SAP session.
2. Send an email from and to **s.jyothi.avadhanam@accenture.com**, with the subject fixed per routine:
| Routine | Subject line |
|---|---|
| ST22 | `[RPA]NMS ST22 Weekly Job Execution` |
| SM37 | `[RPA]NMS SM37 Weekly Job Execution` |
| BD87_02 | `[RPA]NMS BD87_02 Weekly Job Execution` |
| BD87_51 | `[RPA]NMS Weekly BD87_51 Job Execution` |
3. The body is the **Failed Transactions** text. It starts each run at the default value **`Failed Transactions -`** and is extended only if a transaction errored. A body reading exactly `Failed Transactions -` therefore means a clean run.
## Exceptions and recovery
Two recovery blocks exist in each weekly routine. One has a handler that sends the logon-failure email; the other has a handler that marks the claimed queue item as an exception and appends to `Failed Transactions`. **Which stages each block encloses, and the point at which the flow resumes after the second handler, are not recoverable from the outline** — confirm against the live process before relying on the scope of either block.
| Condition | What the automation does | What a human should do |
|---|---|---|
| An error reaches the first recovery block — in practice, an SAP logon failure | Sends an email from/to s.jyothi.avadhanam@accenture.com, subject **`[RPA]SAP NMS Weekly Logon Failed`**, body = the technical error text; then resumes and the run ends at the routine's End3 end point. The exact stages this block covers are not recoverable from the outline. | Check SAP availability and the qx68203 credential, clear any stale session, and re-run the affected routine. No monitoring data was captured. |
| An error reaches the second recovery block — in practice, a failure while executing the claimed transaction | Marks the work item in NMSWeeklyWorkQueue as an exception, with the technical error text as the reason; appends to the **Failed Transactions** text; then resumes. The stages covered and the resume point are not recoverable from the outline, so whether the completion email is still sent afterwards cannot be confirmed from the source. | Inspect the exception reason on the queue item and re-run that transaction manually or by relaunching the routine. If a completion email does arrive, anything after `Failed Transactions -` in the body names what failed. Whether the item is flagged for retry is not set in the source. |
| NMSWeeklyWorkQueue returns no item | Skips all SAP work, closes SAP and sends the completion email anyway | Treat a completion email with no export files as a sign the queue was empty. Check how `TCodes` was populated. |
| SAP logon window absent after 10 seconds | Raises "Window doesn't exist", handled by the logon recovery above | As for logon failure. |
| "System Message" pop-up after logon | Activates the window, clicks **OK**, continues | Nothing, unless the message content matters — the automation does not read it. |
| SAP reports the user already logged in | Activates the "Already Logged In" window, sets a flag, continues | Investigate why a session was already open; concurrent sessions can corrupt the export dialogs. |
| ST22: selection screen, results list, file-type dialog or Save pop-up not present within its wait (10s / 25s / 10s / 10s respectively) | Raises a "Check Window" exception with the specific message ("From Date Doesn;t exist", "REsults window doesn't exist", "FileType window doesn't exist", "Save popup doesn't exist") | Usually a slow SAP response or a changed screen layout. Re-run; if it recurs, the screen mappings need re-recording. |
| ST22 export file already exists (Confirm Save As prompt) | Activates the prompt and clicks **Yes**, overwriting; if the prompt does not appear, carries on | Nothing. Note that last week's export is destroyed — archive the folder first if history matters. |
| Excel formatting fails during the weekly report update | Nothing specific. The weekly Excel step ("Update NMS Weekly Monitoring Report") consists only of waits, a transaction-code choice, inline macro code and a close-Excel step — it performs **no file, workbook or session validation**, so an Excel failure surfaces only as a generic exception into whichever recovery block encloses it. *(The wider MS Excel library does contain "Bad Handle", "Workbook Not Found" and "File Not Found" checks, but these are library capability not exercised by the weekly routines.)* | Check that the SAP export actually landed in `C:\BluePrism\data\SAP_NMS\` and that no user has Excel open. |
## Data handled
| Name | What it holds | Where it comes from |
|---|---|---|
| `TCodes` | The list of SAP transaction codes to be worked this week; loaded onto NMSWeeklyWorkQueue at the start of every routine | Source not shown in the outline — no default value is set |
| **NMSWeeklyWorkQueue** | The shared to-do list holding one entry per transaction; doubles as the audit record of which transactions succeeded and which raised exceptions | Populated in Stage 2 from `TCodes` |
| `Item ID`, `Data`, `Status` | The reference, payload and status of the single work item claimed in Stage 3; the item reference is also what gets marked completed or excepted | Returned when the item is claimed from the queue |
| `Failed Transactions` | Running list of transactions that errored; forms the body of the completion email. Default: **`Failed Transactions -`** | Default value, extended by the error handler |
| `System Name` = **NRP**, `QNo` = **qx68203**, `Password` | SAP logon details used in Stage 1 | Held as defaults inside the SAP automation object; the password value is not visible in the source |
| `From Date`, `To Date` | The reporting window typed into ST22 (and SM37) selection screens | Calculated by the date routine from `Thursday` / `CurrentThursday` |
| `Directory` = **`C:\BluePrism\data\SAP_NMS\`** | Destination folder for every SAP list export | Default inside the SAP automation object |
| `FileName` (per transaction) | Output file stems: `NMS_Weekly_ST22`, `NMS_Weekly_SM37`, `NMS_Weekly_BD87_1`, `NMS_Weekly_BD87_2`. ST22's formatted file is referenced as `NMS_Weekly_ST22.MHTML` | Defaults inside the SAP automation object |
| `TransactionCode` | The command-field string typed into SAP: `/nst22`, `/nsm37`, `/nbd87` for the weekly routines | Defaults inside the SAP automation object |
Note that the wider package also contains an extensive library for SM12, SM13, SM21, SM58, SM66, SMQ1, SMQ2, SMQ3, DB01, SP01, AL11 and for ATLAS and STARD report templates. **None of these are called by the four weekly routines documented here** — treat them as out of scope unless the owner says otherwise.
## Not determinable from the source
- What schedule runs the four routines, and in what order. There is no timer or scheduler artefact, and the container routine named "SAP NMS Weekly Monitoring Process" is defined but **contains no steps at all**.
- How `TCodes` is populated, and therefore what actually lands on NMSWeeklyWorkQueue each week.
- Whether processing only one queue item per run is intended or a defect (no loop back from "mark completed" to "claim next item").
- Which stages each of the two recovery blocks encloses, and where the flow resumes after the queue-exception handler.
- Which BD87 file stem (`NMS_Weekly_BD87_1` vs `NMS_Weekly_BD87_2`) corresponds to IDoc status 02 vs 51, and what selection criteria the BD87 screen is filled with — that page is truncated in the source.
- The full SM37 selection criteria actually used: job name mask, user, and which of Released / Ready / Active / Finished are ticked — that page is truncated too.
- The name, location and sheet layout of the consolidated NMS weekly monitoring report workbook the Excel macros write into.
- Where the SAP password is stored and how it is refreshed.
- Who consumes the report downstream and what action is taken on the findings — the only recipient in the source is the developer's own address.
- Whether failed queue items are retried, and who owns and monitors NMSWeeklyWorkQueue; the retry and lock settings on the exception step are not populated.
- Expected volumes (number of short dumps, jobs, stuck IDocs) and any threshold that would make a week's result abnormal — no thresholds appear anywhere in the automation.
How this SOP was checked
Generated from the project's source files and audited against them. Audit verdict: minor issues, confidence high.
Accurately reconstructs the four weekly routines (ST22, SM37, BD87_02, BD87_51): logon to NRP as qx68203, load TCodes into NMSWeeklyWorkQueue, claim one item, run the fixed transaction, mark completed, close SAP, send per-routine completion email. Email subjects, sender/recipient, folder C:\BluePrism\data\SAP_NMS, file stems, /nst22 /nsm37 /nbd87, Get Dates (Thursday/CurrentThursday), the Excel 'Update NMS Weekly Monitoring Report' macro selection table, the empty container process, and the missing loop back to 'get next item' are all correctly traced. Truncated pages (SM37, BD87) and unsourced items (TCodes origin, report workbook name, password store, schedule) are properly flagged as undeterminable. Remaining gaps are inference presented as fact around exception-block scope and Excel error handling.
2 corrections from the audit were applied to the procedure above.
Remaining minor notes, not corrected:
- Title/overview and Stage 4c heading ('IDoc status monitor, statuses 02 and 51') — The source only shows the labels BD87_02 and BD87_51 passed as a TCode input and file stems NMS_Weekly_BD87_1/_2. The IDocStatus / RemainingIdocStatuses inputs exist on SAP_NMS_All_TC_VBO, which no process in this release calls. Reading 02/51 as IDoc statuses is domain inference. (Present the 02/51 reading as a likely interpretation (BD87 is the IDoc monitor) rather than as established fact, consistent with the hedge already given in Stage 4c step 3.)
- Stage 2, step 2 — Says priority, tags, deferral and initial status 'are not set in the source — the items go on with platform defaults'. The outline marks these inputs as unresolved ('?'), which means the value could not be recovered, not that it is empty. (Say the values for priority, tags, defer-until and status could not be recovered from the source and should be confirmed.)
- Stage 4b, step 4 ('Export the results list via the Extras → Export path') — The SM37 page body is omitted from the outline; only the element name SM37.Export.Extras appears. The export sequence and its ordering relative to the Save As dialog are inferred. (Flag the export navigation itself as unverified, in the same way step 2 flags the selection-screen values.)