SAP NMS Daily Basis Health Check (Monitoring Transactions and Spool Error Report)

Each business day this automation performs the routine SAP Basis health check on the BMW NMS production SAP system. It logs on, works through a fixed checklist of monitoring transactions (ST22, SM66, SM12, SM13, SMQ1, SM21, SM37, SM58), exports each result list to a local spreadsheet, reduces each export to genuine, unique errors, and separately reports SP01 spool error counts by e-mail. The outcome is that the support team receives, in one place, the previous business day's short dumps, lock entries, failed updates, stuck RFC queues, cancelled jobs, database errors and spool problems.

Note on scope: the source release file bundles several unrelated automations (PIX TU error-log monitoring, SPOA service-package cancellation, S-Gate password reset, ISAR Citrix checks, TF/ATLAS parts upload, SAP stock monitoring, a training "Create Orders" exercise, a Landshut user-request reader). This SOP covers only the SAP NMS health check; the relationship of the other automations to it is not indicated in the source.

At a glance

Trigger	Not recorded in the source. The run is self-contained — the process itself loads the checklist of transaction codes into its tracking list at the start — so it is started as a whole (by scheduler or by hand) rather than by an arriving request.
Frequency	Appears to be each business day. The date helper checks today's weekday and uses Friday's date when today is Monday, otherwise the previous day. The exact schedule is not recorded in the source.
Systems used	SAP GUI — NMS production, logon entry NRP (an older version of the object selects NRI); SQL Server database BMW_RPA on localhost\SQLExpress; Microsoft Excel; Microsoft Outlook; Windows file system
Inputs	Checklist of SAP transaction codes (ST22, SM66, SM12, SM13, SMQ1, SM21, SM37, SM58); SAP logon credentials (from the database, or the stored default user qx68203); reporting date window derived at run time; per-transaction selection defaults (user *, SM12 table *, SP01 "Created by" * and client 010, SM37 status flags)
Outputs	One spreadsheet per transaction in C:\BluePrism\data\SAP_NMS\ (e.g. NMS_ST22.xls, NMS_SM66.xls, NMS_SM12.xls, NMS_SM13.xls); de-duplicated error data sets; SP01_ErrorCounts.xls; an Outlook e-mail "NMS-SP01 Error Counts" to and copying s.jyothi.avadhanam@accenture.com; completed/exception status per transaction on the tracking list NMSWorkQueue; a "Consolidated NMS Template" workbook stamped with the current date
Typical run	Not recorded in the source (no duration or volume figures).
Owner	Not recorded in the source. The only named recipient is s.jyothi.avadhanam@accenture.com.

Before you start

Access and credentials

• A SAP account on the NMS production system with authority to run ST22, SM66, SM12, SM13, SMQ1, SM21, SM37, SM58 and SP01, and to export lists to a local file. The bot obtains this either from the database (see below) or from the stored default user qx68203.
• Read access to the SQL Server database BMW_RPA on localhost\SQLExpress. The credential lookup runs the query: select user_id,password from system_credentials where application_name='NMS';
• Note for the process owner: several other objects in the same release file carry hard-coded credentials in plain text (for example muc\qxq0595 / 1qaz1qaz in the Landshut object, qxq0595 / 3edc3edc in the SAP connection object). Whether these are live accounts requiring remediation is not stated in the source, but they should be reviewed.

System state

• SAP Logon must be installed and the logon entry NRP must be present in the list (the bot picks the entry by clicking it, so the entry's position and label matter).
• Microsoft Excel must be installed. The bot opens exported files and runs embedded code inside them.
• Microsoft Outlook must already be open before the reporting step. The mail step attaches to an existing Outlook window (window title matching *- Outlook); if it cannot attach it will attempt to launch Outlook, but the reliable state is Outlook already running and signed in.

Files and folders

• C:\BluePrism\data\SAP_NMS\ must exist and be writable. Exports are written here and any file from the previous run is overwritten (the bot clicks Replace on the SAP save dialog).
• The SP01 count file is written as SP01_ErrorCounts1.xls in the SAP working directory and read back from C:\Users\s.jyothi.avadhanam\Documents\SAP\SAP GUI\SP01_ErrorCounts.xls. These two paths are inconsistent in the source; confirm the actual path on the machine before running.
• The tracking list NMSWorkQueue — an internal to-do list the bot ticks items off as it works them — should be empty of leftover items from a previous failed run.

Procedure

Stage 1 — Get the SAP credentials

1. Connect to SQL Server localhost\SQLExpress, database BMW_RPA.
2. Run select user_id,password from system_credentials where application_name='NMS'; and take the returned user id and password.
3. If the newer transaction object is used instead, the credential lookup is skipped and the stored default user qx68203 is used with a password held in the object. The source shows both variants; which one is live is not stated.

Stage 2 — Log on to the NMS SAP system

1. Launch SAP Logon and wait for the logon list to appear (up to about 7 seconds).
2. Select the system entry NRP by clicking it. (The older object selects an entry labelled NRI on the same screen — treat this as an environment difference and confirm which is correct for your landscape.)
3. Wait for the credentials window. If it does not appear, the bot raises "Window doesn't exist" and stops.
4. Type the user id, then the password, then confirm with OK.
5. If SAP displays a System Message window straight after logon, the bot activates it, clicks OK, and carries on. No error is reported.

Stage 3 — Load the monitoring checklist onto the tracking list

1. Take the checklist of transaction codes held in the process (ST22, SM66, SM12, SM13, SMQ1, SM21, SM37, SM58) and add it to the tracking list NMSWorkQueue — one item per transaction code. This makes each check independently trackable: it can be retried or flagged as failed without abandoning the other checks. How the checklist itself gets populated is not shown in the source (see "Not determinable").

Stage 4 — Take the next check off the list

1. Fetch the next item from NMSWorkQueue.
2. If no item comes back (the item reference is blank) then all checks are done — go to Stage 10 (close SAP).
3. Otherwise, read the transaction code from the item and route to the matching routine: ST22, SM66, SM12, SM13, SMQ1, SM21, SM37 or SM58.

Stage 5 — Work out the reporting date window

1. Read today's weekday.
2. If today is Monday then set the "From" date to Friday's date (so the weekend is covered).
3. Otherwise set the "From" date to the previous day. The "To" date is set to today.
4. These dates are typed into the selection screens of ST22, SM13, SM21, SM37, SM58 and SP01.

Caution: several object defaults still contain fixed test date ranges (for example From 01.02.2016, To 14.02.2017, and 06.02.2017/07.02.2017 in the stock-monitoring object). These are left over from development. Confirm the derived dates are actually being used before trusting a run.

Stage 6 — Run the transaction and export the list

The common pattern for every transaction:

1. Type the transaction code into the command field, prefixed to force a new screen (/nst22, /nsm66, /nsm12, /nsm13, and so on), and press OK.
2. Fill in the selection screen (see the table below).
3. Execute.
4. Export the result list: System → List → Save → Local file, choose Spreadsheet, confirm OK.
5. On the save dialog, type the directory C:\BluePrism\data\SAP_NMS\, then the file name, then click Replace to overwrite the previous run's file.
6. If the results window, file-type popup or save popup does not appear in time, the bot raises a system exception (see Exceptions).

What each transaction is checking — these are the developer's own annotations, quoted:

Transaction	Selection entered	Purpose (developer's note)	Export file
ST22	From/To date, user *; tick Exception, Program affected, Program and components; click Start	Short dumps / runtime errors	NMS_ST22.xls
SM66	none — the overview screen is read directly	"Check the Work proccess which is taking more time to run which is in PRIV mode"	NMS_SM66.xls
SM12	Table name * (older version also fills lock argument, client, user name)	Lock entries. Note also says "Delete previous day locks" — but no delete steps exist in the automation	NMS_SM12.xls
SM13	From/To date, then Execute; result table read on screen	"check if any failed updates are there"	NMS_SM13.xls
SMQ1	Client, queue name, queue destination, then Execute	"Reprocessing stuck RFCs" — the screen is only opened; no reprocessing steps exist	not exported in the outline
SM21	System Log → Choose → All remote system logs; From/To date; click Read System Log. Then Find, search for DB errors, and read the hit count and error text	"search for database erros"	read on screen
SM37	Job name, user name; tick Released, Ready, Active, Finished, Cancelled; From/To date; Execute; then Extras → Export → Local file → Spreadsheet	"Check for canceled jobs"	file name from the object; unique errors extracted afterwards
SM58	From/To date, user name, then Execute	"Reprocessing stuck RFCs" — screen opened only	not exported in the outline

An additional transaction BD87 (IDoc status monitor: From/To date, IDoc status, execute, drill into client 010, expand the tree, display IDocs) exists in the older supporting object but is not on the checklist routed in Stage 4. Whether it is meant to be in the daily run is not stated.

Stage 7 — Reduce the export to real, unique errors

1. Open the exported spreadsheet in Excel.
2. Run the embedded reduction routine for that transaction:
   • SM37 → removes duplicates, returns the unique cancelled-job rows plus a row count.
   • SM12 → returns unique lock entries plus a count.
   • ST22 → returns unique dump rows plus the error list.
3. For tables read straight off the SAP screen rather than exported, the filtering happens in the collected data instead:
   • SM13: any row with an empty value in column INFO5 is discarded, so only genuine failed updates remain.
   • In the older object, any row whose client (MANDT) is not 010 is also discarded.
4. A separate routine stamps the current date into a "Consolidated NMS Template" workbook. The workbook's path and sheet are not shown in the source.

Stage 8 — Close the item off and repeat

1. Mark the tracking-list item for that transaction code Completed.
2. Return to Stage 4 and take the next check.

Stage 9 — Spool error counts and e-mail report

This runs as a sibling process with its own SAP logon; whether it runs in the same window as Stages 1–8 is not stated.

1. Log on to SAP system NRP as above.
2. Enter transaction SP01 and confirm.
3. On the selection screen: set Created by to *, the created from and created to dates to the derived date window, and Client to 010. Execute.
4. If the spool selection screen needs re-activating after execute, the bot recovers by activating the window and clicking Display, then continues.
5. Export the spool list: System → List → Save → Local file → Spreadsheet → OK, then type the file name SP01_ErrorCounts1.xls and click Replace.
6. Read the saved file back into Excel and count the errors.
7. In Outlook, create a new mail:
   • Subject: NMS-SP01 Error Counts
   • To: s.jyothi.avadhanam@accenture.com
   • CC: s.jyothi.avadhanam@accenture.com
   • Body: the error counts, pasted in via the clipboard. Then click Send.
8. Terminate the SAP session used for SP01.

The older supporting object contained an alternative SP01 method: repeatedly use Find in the displayed spool list to count "spool requests being processed" versus "spool requests with errors" ("Finding numbder of Spool requests being proccessed and spool request with errors"). This is superseded by the export-and-count method above.

Stage 10 — Close SAP

1. When the tracking list returns no more items, close/terminate the SAP session.
2. End the run.

Exceptions and recovery

Condition	What the automation does	What a human should do
Any error while working a transaction code (SAP screen missing, export dialog absent, Excel failure)	Catches it, marks that tracking-list item as an exception with the underlying SAP/system error text attached as the reason, then resumes with the next transaction code. The run is not aborted.	Review exception items on NMSWorkQueue after the run and perform that transaction's check manually. There is no automatic retry or re-queue.
An expected SAP window does not appear within its wait time	Raises a system exception with a message such as "Window doesn't exist", "Login window doesn't exist", "REsults window doesn't exist", "FileType window doesn't exist", "Save popup doesn't exist".	Check SAP availability and whether the GUI layout or theme changed. Screens are located by on-screen region in several places, so a resolution or layout change will break them.
SAP shows a System Message window immediately after logon	Caught; the bot clicks OK and continues logging on.	Nothing. But note that the message content is not read or reported — if the message matters, read it manually.
Tracking list returns no item	Skips the transaction loop entirely and goes straight to closing SAP.	If this happens at the start of a run, the checklist did not load — investigate before assuming the checks passed.
SM13 rows with an empty INFO5 value; rows for clients other than 010	Removed from the data set before reporting.	Be aware the reported set is filtered, not the raw SAP list.
An exported spreadsheet already exists in C:\BluePrism\data\SAP_NMS\	Clicks Replace on the SAP save dialog — the previous run's export is overwritten. No archive is kept.	If day-on-day comparison is needed, copy the folder before the run.
Credential lookup fails in the database object	The database helper raises an "Action Failed" exception only if it is configured to raise on failure; otherwise it returns a failure flag and message, and attempts a rollback and connection close. Whether it is configured to raise is not shown.	Verify the system_credentials row for application_name='NMS' exists and the SQL Express instance is running.
Outlook cannot be attached to for the report mail	Recovery path attempts to launch Outlook, then resumes.	Have Outlook open and signed in before the run. If the mail did not arrive, resend the counts manually from SP01_ErrorCounts.xls.

Data handled

Name	What it holds	Where it comes from
Transaction Codes	The checklist of monitoring transactions to work through: ST22, SM66, SM12, SM13, SMQ1, SM21, SM37, SM58	Held in the process; the source does not show it being populated
NMSWorkQueue	The tracking list, one entry per transaction code, each marked Completed or Exception	Created at Stage 3 from Transaction Codes
Item ID / Data	Reference and content of the transaction check currently being worked; a blank Item ID is the signal that the list is empty	Taken from NMSWorkQueue at Stage 4
Query / Query Results	The credential SQL (select user_id,password from system_credentials where application_name='NMS';) and the returned user id and password	SQL Server BMW_RPA
System Name / QNo / Password	SAP logon target (NRP, older variant NRI) and the SAP user (stored default qx68203) and password	Object defaults, or the database lookup
From Date / To Date	The reporting window: Friday's date when run on a Monday, otherwise the previous day, through today	Derived at run time by the date helper. Note stale defaults such as 01.02.2016 / 14.02.2017 remain in some objects
Directory / FileName	Export location C:\BluePrism\data\SAP_NMS\ and per-transaction file names (NMS_ST22.xls, NMS_SM66.xls, NMS_SM12.xls, NMS_SM13.xls)	Object defaults
Errors / UniqueData / Runtime Errors	The reduced error sets — unique dumps, unique lock entries, unique cancelled jobs, genuine failed updates	Read from the exported spreadsheet or the SAP screen table, then de-duplicated and filtered
DBErrors Count / Error Text	The SM21 database-error hit count and error text read from the Find result popup	Read from the SM21 screen
Spool Collection / ErrorCounts	The SP01 spool list read back from the exported file, and the error count text placed into the mail body	SP01_ErrorCounts.xls
To / CC	Report recipients — both set to s.jyothi.avadhanam@accenture.com	Object defaults in the SP01 reporting process

Not determinable from the source

• Where the checklist of transaction codes actually comes from — no step populates it (hard-coded, imported, or set at start-up is not shown).
• The schedule, start time and expected run duration; and whether the transaction loop and the SP01 e-mail report run in the same session or independently.
• Who owns and monitors NMSWorkQueue, and what happens to items marked as exceptions — no retry count or re-queue logic is present.
• Who else should receive the results. The only recipient is a single Accenture address, used in both To and CC; the operational distribution list is not in the source.
• Whether the exported spreadsheets and the "Consolidated NMS Template" workbook are consumed downstream (report, ticket, dashboard) or just left on disk. The template's file path and sheet name are not shown.
• Escalation criteria. The notes say what to look for (long-running PRIV work processes, failed updates, stuck RFCs, cancelled jobs, DB errors) but no thresholds or follow-up actions are defined. SMQ1 and SM58 are only opened despite the note "Reprocessing stuck RFCs"; SM12 says "Delete previous day locks" but no delete steps exist. Whether these actions are done manually or were never built is unclear.
• The meaning of and difference between SAP entries NRP and NRI, and which environment the credentials in system_credentials point to.
• Volumes: how many dumps, jobs or locks are typically found, and file sizes.
• Whether BD87 (IDoc monitoring) is meant to be part of the daily checklist — it exists in a supporting object but is not routed.
• The relationship of the other automations bundled in the same release file (PIX TU error-log monitoring and dealer mails, SPOA service-package cancellation from ITSM incidents, S-Gate password reset via BAT, ISAR Citrix/CLAT and logged-in-user checks, TF/ATLAS parts-discrepancy upload to MQS, SAP AW/AE stock monitoring, the "Create Orders" training exercise, the Landshut user-request reader) to this process, and which are live versus abandoned prototypes.
• Whether the hard-coded credentials found in some objects are live accounts needing remediation.

---

How this SOP was checked

Generated from the project's source files and audited against them. Audit verdict: minor issues, confidence medium.

Faithful, well-hedged account of the SAP_NMS_All_Transactions process (logon → load 8 transaction codes into NMSWorkQueue → get next item → CHOOSE route → per-TC export to C:\BluePrism\data\SAP_NMS\ → Mark Completed / Mark Exception on recover → Close SAP) and of the sibling SAP_NMS_SP01_VBO process (SP01 selection with Created by '*', client 010, export, read back, Outlook mail 'NMS-SP01 Error Counts' to/cc s.jyothi.avadhanam@accenture.com, terminate SAP). Real values (transaction codes, /n prefixes, file names, NRP vs NRI, SM13 INFO5 and MANDT='010' filters, Monday/other date branch, SQL credential query, hard-coded credentials in Landshut/SAPConnection) are preserved and developer notes are quoted correctly. Unsupportable items (trigger, schedule, checklist origin, thresholds, template path) are properly declared. Main weaknesses: two procedural stages are built from objects the live call chain does not invoke, and ~12 other deployed processes in the release are documented only as out-of-scope names.

Remaining minor notes:

• Stage 1 — Get the SAP credentials; At a glance (Systems used / Inputs) — The DB credential lookup (Connect To Database :: DB Connect, query on system_credentials for application_name='NMS') exists only in the legacy objects NMS_SM12_VBO::Login and SAP_NMS_VBO::Login. The live process SAP_NMS_All_Transactions calls SAP_NMS_All_TC_VBO::Login, whose Login page has no DB call — it uses defaults System Name='NRP', QNo='qx68203' and a stored password. Presenting the DB lookup as Stage 1 of the procedure misattributes a legacy stage to the live flow. (Make Stage 1 the SAP logon with the stored user (qx68203) as the primary path, and demote the SQL Server BMW_RPA credential lookup to a note about the superseded NMS_SM12_VBO/SAP_NMS_VBO objects.)
• Stage 7 — Reduce the export to real, unique errors — No call from SAP_NMS_All_Transactions or from the shown SAP_NMS_All_TC_VBO pages (ST22, SM66, SM12) invokes any de-duplication routine; ST22's page ends at 'Click Replace'. The ST22_NWS object pages (NWS_ST22, NMS_ST22, NMS_SM12) and MS Excel VBO::SAP_NWS_SM12 have no caller anywhere in the outline. Only NMS_SM12_VBO's SM37 page actually calls MS Excel VBO::SAP_SM37_Code. (State that only the SM37 path is shown to call a reduction routine (SAP_SM37_Code), and that the ST22/SM12 de-duplication code exists as standalone object pages with no caller visible in the source — so whether it runs in the daily flow is not determinable.)
• Stage 7 step 4 and Outputs ("Consolidated NMS Template" workbook) — MS Excel VBO's 'Consolidated NMS Template' page (which passes CurrentDate to inline code) is never called by any process or object in the outline. Listing it as a procedural step and as an output attributes it to a stage the source does not connect. (Remove it from the procedure and outputs, or list it under 'Not determinable' as an unreferenced Excel routine with no caller in the source.)
• Stage 2 step 5 and Exceptions table row 'SAP shows a System Message window' — Condition described backwards. In SAP_NMS_All_TC_VBO::Login the block/recover wraps the attempt to activate the System Message window and click OK; the catch fires when that attempt fails (i.e. when no System Message window is present), not when the message appears. (Say: the bot tries to activate a post-logon System Message window and click OK; if no such window exists the failure is caught and the run resumes logon without error.)
• Stage 5 — Work out the reporting date window — Invented specifics: the source's Get Dates page only shows a decision 'Is Monday' branching to calculations named 'Get Friday Date' / 'Get From Date' and 'Get To Date'. The values 'previous day' and 'To = today' are not shown, and Get Dates is only shown being called from the ST22 page. (State the Monday/otherwise branch and that the actual date arithmetic is inside calculation stages not exposed by the source; note the derived window is confirmed only for ST22 (and SP01, which has its own Get From/To Date calculations).)
• Exceptions table, first row ("There is no automatic retry or re-queue") — Mark Exception is called with Retry=? (value not shown in the source), so the absence of retry cannot be asserted. (Say the retry/keep-locked settings on Mark Exception are not recorded in the source, so whether items are re-presented is unknown.)
• Stage 6 step 4 ("The common pattern for every transaction") — Over-generalised export path. SM66 and SP01 use System → List → Save → Local file; ST22 uses Export → Local file → FileType(Spreadsheet) → OK; SM12 uses a direct Export button; SM37 uses Extras → Export → Local file. (Note that the menu route to the export differs per transaction and list the variants.)
• Stage 4 (routing) / Exceptions — The process's CHOOSE stage has an 'Otherwise1' default branch that the SOP does not mention; behaviour for a transaction code outside the eight is not described. (Add that an unmatched transaction code falls to a default branch whose action is not shown in the source.)
• Scope note / whole document — Twelve further deployed processes in the same release (PIX_TU_Monitoring and Blueprsim, SPOA Package Cancellation, SPOA PAckage Cancel Test, SGate Password Reset, Set SPOA Role -SGate, ISAR CLAT Logs, ISAR User Admin Performance, ISAR Users Verification, TF_Atlas_Descrepancies, TF_Citrix, SAP_StockMonitoring_Process, Create Orders) have no procedure documented at all, though queues PIXTUMonitMailSend, SPOAPackageCancellation and QueueTrainingOrder and their business steps are fully described in the source. (Either state clearly that this is Part 1 of a multi-process release with the other processes to be documented separately, or add at least a one-stage summary per process (trigger, system, queue, outcome) since the source supports it.)