BMW SAP Landscape & Application Monitoring Suite (BPRelease_04042017)

This automation performs the daily and weekly technical health checks on BMW's SAP landscapes (NMS, ATLAS, Finance, VDS) and on a set of surrounding operational systems — the PIX dealer file-transfer portal, the ITSM incident tool, S-Gate user administration, SPOA service-package administration, and Citrix-published applications. For each target system it signs in, runs a defined list of SAP monitoring transactions or application checks, exports the result lists to spreadsheets, formats them into a standard monitoring report, and e-mails the outcome — or the failure — to the support team. Two of the variants go further than reporting: the PIX variant sends error-description letters directly to affected dealers, and the ITSM-driven variants actually change user roles in S-Gate and cancel service packages in SPOA on the strength of resolved tickets.

The business outcome is that a support team receives a daily/weekly evidence pack of system health and a list of anything that failed, without an operator manually working through eleven SAP transactions per system.

At a glance

Trigger	Started externally (Blue Prism Control Room schedule or a manual start). No schedule definition exists in the export. Each process begins by logging into its target system and then builds its own to-do list; nothing waits for work to arrive.
Frequency	Not recorded in the source. Naming and date logic imply a split: daily for SAP_ATLAS_*, SAP_NMS_All_Transactions, PIX_TU_Monitoring_Process, SAP_FI_* (date logic picks yesterday, or Friday when today is Monday) and weekly for SAP_NMS_*_Weekly_Monitoring_Process (date logic anchors on Thursday) and SAP Stock Monitoring (anchors on Sunday).
Systems used	SAP GUI (NMS system NRP; ATLAS systems AEP, AAP, AWP; Finance RWP/TSP; VDS VDP; stock systems AWP/AEQ), PIX web application, ITSM incident tool, S-Gate, BAT, SPOA web application, Citrix (ISAR, TF, VDS access), Microsoft Excel, Microsoft Word, Outlook and SMTP (ind.smtp.accenture.com:25), SQL Server (localhost\SQLExpress, database BMW_RPA), gAMS/B2B portal, mainframe web (Beta92)
Inputs	SAP and application credentials (some hard-coded, some read from SQL table system_credentials); fixed transaction-code lists per system; ATLAS system list AEP/AAP/AWP; a derived date range; PIX "From Date"; dealer contact list PIX_Dealer_Info.xlsx; Word error-description templates; ITSM search filters
Outputs	Per-transaction SAP exports (C:\BluePrism\data\SAP_NMS\NMS_<TCODE>.xls, ATLAS_<TCODE>.xls, C:\BluePrism\data\SAP_Finance\RWP_F961.xls, etc.); formatted monitoring report workbooks; Word screenshot evidence (C:\temp\SAP_FI_Atlas_BD87.docx, …SM35.docx); completion and failure e-mails; dealer-facing PIX error letters; S-Gate role changes; SPOA package cancellations; MQS parts upload; queue audit trail of completed/exception items
Typical run	Not recorded in the source. No volumes, durations or error counts appear in the export.
Owner	Not recorded in the source. Every e-mail in the export is addressed to s.jyothi.avadhanam@accenture.com (also the sender), with the Finance and PIX-OU variants going to balram.goud@accenture.com and manoj.kumar.boddula@accenture.com. This looks like test wiring rather than a production distribution list.

Before you start

Access and credentials

• SAP GUI installed with logon entries for the systems in scope: NRP (NMS), AEP, AAP, AWP (ATLAS and stock), VDP (VDS), RWP/TSP (Finance).
• SAP monitoring user IDs as referenced in the export: NMS qx68203; ATLAS AWP and stock qxl3498; ATLAS AAP/AEP (a separate password data item exists for AAP); Finance qxk9917 and qx91445; VDS qxl1963. Passwords are variously blank (expecting a credential store), hard-coded, or read from SQL.
• SQL Server reachable at localhost\SQLExpress, database BMW_RPA, with table system_credentials populated. The query used is: select user_id,password from system_credentials where application_name='NMS';
• PIX portal login navisione.
• ITSM login: Q-number QXO8154.
• S-Gate login (used for role changes) and BAT login QXO8154.
• Citrix portal access with the published applications 30_Antares-PROD, ISAR-Client, CLAT, 00_Administration → Konsolen → Citrix_AppCenter-PROD, and 14_IE11.
• Security note: the export contains plaintext credentials (muc\qxq0595 / 1qaz1qaz in the Landshut object; qxq0595 / 4rfv4rfv in SAPConnection). Rotate these and move all credentials to a secure store before any redeployment.

Files and folders that must exist

Path	Purpose
C:\BluePrism\data\SAP_NMS\	NMS transaction exports and weekly reports
C:\BluePrism\data\SAP_Finance\	F961 and SM13 Finance exports
C:\BluePrism\data\SAP_Stock_Monitoring\ and …\AW Files	Stock monitoring AE/AW exports
C:\BluePrism\data\PixTUMonitoringLogs\Error_Code.xlsx	Working file for the PIX error table
C:\BluePrism\data\PixTUMonitoringLogs\PIX_Dealer_Info.xlsx	Dealer and market support-group e-mail addresses by country code
C:\BluePrism\data\PixTUMonitoringLogs\MailList.xlsx	To/CC list used by the Outlook send route
C:\BluePrism\data\PixTUMonitoringLogs\PIX Error Descriptions.docx	Error-description template, sectioned by <code> Starts / <code> Ends markers
C:\temp\	Destination for the Finance Word screenshot documents
C:\Users\…\TF_Atlas_Discrepancies\Descrepancy_Check.bat, Descripencies.csv, Parts.txt	Parts discrepancy chain

System state

• Excel and Word must be installed and closable without prompting. Several routines end by force-closing Excel.
• Outlook must be open when the Outlook send route is used — that route attaches to a window titled *- Outlook and pastes the body via the clipboard, so nothing else may use the clipboard during the run.
• The SAP monitoring user must not already be logged on. SAP_NMS_All_Transactions will abandon the run if it is (see stage 2).
• Screen resolution must not change: the Stock Monitoring spool export drives fixed screen coordinates (Y offsets starting at 328/340, incremented per spool).

Procedure

The suite is a family of similar runs. Stages 1–9 are the common SAP monitoring pattern; stages 10–12 are the variants that deviate from it.

Stage 1 — Log into the target system

1. Launch the application. For SAP, this opens SAP Logon.
2. Where the credentials are not held in the process, read them first from SQL Server: run the system_credentials query above against localhost\SQLExpress / BMW_RPA and take user_id and password.
3. Select the system entry from the SAP Logon list — NRP for NMS, AEP/AAP/AWP for ATLAS and stock, VDP for VDS, RWP/TSP for Finance.
4. Key the user name and password and confirm. For the ATLAS login, if the system name is AAP then the AAP-specific password is used, otherwise the standard password is used.
5. Dismiss the two dialogs SAP may raise:
   • the System Message window — click OK;
   • the multiple logon dialog — select "continue with logon" and click OK.
6. If SAP reports the account is already logged on, the login step returns the text Already Logged In to the caller.
7. Non-SAP variants sign in the same way: PIX (launch, click into user name and password fields, click OK), ITSM (Q-number and password, with a fallback to an older login screen layout if the new one does not appear), Citrix (user name, password, domain MUC, then Logon), SPOA, and S-Gate (which additionally sets the interface language to English).

Stage 2 — Abort early if the SAP session is already in use

1. SAP_NMS_All_Transactions reads the message returned by the login step.
2. If the message is exactly Already Logged In then the bot closes SAP and ends the run immediately, performing no monitoring. This prevents two concurrent runs colliding on the same SAP user.
3. Otherwise it proceeds to build the work list.
4. Note the inconsistency: the ATLAS and weekly-monitoring login pages handle the same situation by clicking "continue with logon" and carrying on, and the calling process ignores the returned message. Only the NMS all-transactions process actually aborts.

Stage 3 — Build the run's work list

1. Load the run's fixed list of items into a work queue — a shared to-do list held in the automation platform, which the robot works through one row at a time so that each row can be individually marked done or failed and re-inspected afterwards.
2. The queue used depends on the process:

Process	Queue name	What each row is
SAP_NMS_All_Transactions	NMSWorkQueue	One SAP transaction code
SAP_NMS_*_Weekly_Monitoring_Process	NMSWeeklyWorkQueue	One weekly transaction code
SAP_ATLAS_All_Transactions, SAP_ATLAS_AWP_All_Process	SAPAtlasWorkQueue	One SAP transaction code
SAP_ATLAS_All_Systems	SAP_ATLAS_Systems	One ATLAS system name (AEP / AAP / AWP)
PIX_TU_Monitoring_Process, PIX_TU_Monitoring	PIXTUMonitMailSend	One PIX error-log row
Set SPOA Role -SGate	SPOA Roles WorkQueue	One ITSM incident
SPOA Package Cancellation	SPOAPackageCancellation	One ITSM incident
Create Orders (training material)	QueueTrainingOrder	One order line from a CSV

3. The list contents themselves are held in process data items (Transaction Codes, TCodes, Atlas systems) whose values are not visible in the export. The codes exercised by the underlying objects are:
   • NMS: ST22, SM66, SM12, SM13, SMQ1, SM21, SM37, SM58, BD87, AL11, SP01
   • ATLAS: SM12, SM13, ST22, SMQ1, SMQ2, SMQ3, SM66, SM58, SCOT, SM21, DB01
   • NMS weekly: ST22, SM37, SM13, BD87_02, BD87_51 (each as its own process)

Stage 4 — Take the next item and route it

1. Fetch the next unworked row from the queue.
2. If no row is returned (the item reference comes back empty) then skip straight to stage 9 (close down and report).
3. Otherwise route the row:
   • For transaction-code queues, a selection step matches the code and jumps to the matching handler. Codes that match nothing fall through an "otherwise" branch.
   • For SAP_ATLAS_All_Systems, the routing is on the system name: if the system is AEP or AAP then run SAP_ATLAS_All_Transactions for that system; otherwise run SAP_ATLAS_AWP_All_Process. Both are passed the system name as an input.

Stage 5 — Run the monitoring transaction and export the list

1. Work out the date range first. The Get Dates routine reads the current day and:
   • daily runs: if today is Monday then the "from" date is the previous Friday, otherwise it is yesterday; "to" date is today;
   • weekly runs: the range is anchored on Thursday;
   • the Stock Monitoring variant anchors on Sunday.
2. Enter the transaction code in the SAP command field, prefixed to force a new screen — for example /nst22, /nsm13, /nsm66, /nbd87 — and confirm.
3. Fill in the selection screen. The known field settings are:

Transaction	Selection screen entries
ST22 (runtime errors / short dumps)	From date, To date, User *; tick Exception, Program affected, Program and components; press Start. The ATLAS AWP variant instead clicks "Today's errors".
SM12 (lock entries)	Table name *, Lock argument *, Client 010, User name *; press OK. A developer note records the intent: "Delete previous day locks".
SM13 (failed update records)	From and To date, cancelled updates; execute.
SM37 (batch jobs)	Job name * (or STOCKCHECK_* for stock monitoring), User *, status checkboxes Released/Ready/Active/Finished/Cancelled, From and To date; execute. Developer note: "Check for canceled jobs".
SM21 (system log)	Select System Log → Choose → All remote system logs, From and To date, re-read system log. Developer note: "search for database erros" — the log is then searched for database errors and the hit count read.
SMQ1 / SMQ2 / SMQ3 (queues)	Client, Queue name, Queue destination; execute. Developer note: "Reprocessing stuck RFCs".
SM58 (transactional RFC)	From date, To date, User name; execute. Developer note: "Reprocessing stuck RFCs".
SM66 (work process overview)	No selection; go straight to export. Developer note: "Check the Work proccess which is taking more time to run which is in PRIV mode".
SP01 (spool requests)	Created by *, Created from/to dates, Client 010; execute, then Display. Developer note: "Finding numbder of Spool requests being proccessed and spool request with errors".
BD87 (IDoc reprocessing)	From date, To date, IDoc status; execute, click client 010 in the tree, expand two levels, click Display IDocs.
SE16N (stock/parts table reads)	Table MBEW with area a190 for stock; table MARA for the parts discrepancy run.
SLG1, SCOT, DB01, AL11	Driven by their own handlers; selection detail is not exposed in the outline.

4. Export the result list. The standard SAP path used throughout is: System → List → Save → Local file → Spreadsheet → OK, then type the directory and file name into the save popup and press Replace. Some handlers use the toolbar Export button and the Extras → Export → Local file menu route instead.
5. File naming follows a fixed convention: NMS_<TCODE>.xls and NMS_Weekly_<TCODE> under C:\BluePrism\data\SAP_NMS\; ATLAS_<TCODE>.xls for ATLAS; RWP_F961.xls and SAP_FI_SM13.xls under C:\BluePrism\data\SAP_Finance\.
6. Each window and dialog is checked for existence before use, with an explicit named error if it is absent (see Exceptions).

Stage 6 — Drill into individual errors (ST22 detail loop)

1. After the ST22 list is exported, re-read the error codes it contains.
2. For each error code in turn:
   1. Click Filter on the result list.
   2. On the first pass only, select the filter field Name of Runtime Error and move it to the active side.
   3. Open Values of Filter Criteria, enter the error code, and confirm.
   4. Select the filtered error row.
   5. Export the error description via System → List → Save.
3. Write the collected descriptions back into the report template under the matching section. The template routine accepts these section keys: ST22ErrorDesc, SM13ErrorDesc, SM37JobLog, BD87_51, BD87_All, AL11.

Stage 7 — Format the export into the reporting template

1. Open the exported spreadsheet and run the per-transaction formatting and de-duplication routine for the code just processed.
2. The routine lands the figures into the standard monitoring report layout. The values it produces, by transaction, are: unique ST22 dump codes, SM12 lock entries, SM13 cancelled updates, SM37 cancelled jobs, SM21 database errors, SMQ1/SMQ2 queue errors, SM58 stuck RFCs, and SM66/SMGW figures.
3. ATLAS uses a parallel routine keyed by transaction code and system name, so AEP, AAP and AWP results land in their own columns of the ATLAS BND template.
4. Weekly runs use a separate weekly-report routine, keyed by ST22 / SM37 / BD87_1 / BD87_2 / SM13, and read the exported file (for ST22, NMS_Weekly_ST22.MHTML).
5. SP01 is handled differently: the exported spreadsheet is read back and the spool error counts converted into a short text summary for the mail body.
6. The Finance BD87 and SM35 checks produce screenshot evidence rather than spreadsheets: the SAP screen is captured with Print Screen, pasted into a new Word document, and saved as C:\temp\SAP_FI_Atlas_BD87.docx / C:\temp\SAP_FI_Atlas_SM35.docx, then mailed as an attachment. SM35 additionally reads the total and the processed session counts, computes the difference, and substitutes both into a pre-written body: "…[count] batch sessions were processed successfully and [count1] batch session were processed with errors."

Stage 8 — Mark the item done and loop

1. Mark the queue row Completed.
2. Return to stage 4 and take the next row.
3. Repeat until the queue returns nothing.

Stage 9 — Close the application and report the run

1. Close SAP (or terminate the browser / Citrix session, as appropriate).
2. Send the run summary e-mail. The body is the accumulated Failed Transactions - text, so a clean run mails that prefix with an empty list after it.
3. Subject lines in use:

Process	Subject
SAP_NMS_All_Transactions	NMS Jobs Execution
SAP_NMS_ST22_Weekly…	[RPA]NMS ST22 Weekly Job Execution
SAP_NMS_SM37_Weekly… and SAP_NMS_SM13_Weekly…	[RPA]NMS SM37 Weekly Job Execution (the SM13 process reuses this subject and, in the export, calls the SM13 handler from a step labelled "Execute SM37" — likely a copy-paste artefact)
SAP_NMS_BD87_02_Weekly…	[RPA]NMS BD87_02 Weekly Job Execution
SAP_NMS_BD87_51_Weekly…	[RPA]NMS Weekly BD87_51 Job Execution
SAP_NMS_SP01_VBO	NMS-SP01 Error Counts (body is the error-count summary)
PIX_TU_Monitoring_Process	PIX TU Monitoring Completed (body is the list of failed TU numbers)
SAP_StockMonitoring_Process	SAP Stock Monitoring Status
SAP_FI_F961_Prod	SAP F961
SAP_FI_SM13_Prod	SAP FI SM13

4. Mail is sent either via SMTP (ind.smtp.accenture.com, port 25) or by driving Outlook directly — new mail, fill To/CC/Subject, click into the body, copy the content to the clipboard and paste it, then Send.

Stage 10 — PIX variant: dealer error-log letters

1. Log into PIX as navisione.
2. Open Error Log, enter the "From Date" (the "To Date" is calculated), and click Search.
3. Read the on-screen error table, write it to C:\BluePrism\data\PixTUMonitoringLogs\Error_Code.xlsx, then run the de-duplication routine over that file.
4. Load the de-duplicated rows into queue PIXTUMonitMailSend.
5. For each row taken from the queue:
   1. If the row has a partner technical unit (TU) and the error number is exactly four digits then continue; otherwise the row is skipped.
   2. Search the technical unit in PIX and read its country code.
   3. Read PIX_Dealer_Info.xlsx and look up, by country code, the dealer e-mail address and the market support-group address.
   4. If a dealer e-mail was found then build the letter: open PIX Error Descriptions.docx (or PIX TU Error Log Monitoring Template.doc) and extract the text between the markers <error code> Starts and <error code> Ends; substitute the placeholders [Dealer Name] and [Dealer Number]; send to the dealer with the market support group on CC. Subject: PIX TU Error Description or PIX Error Description For <TU>.
   5. If no description exists in the template for that code then send the fallback body instead — "We couldn't find proper error description for the below Error Code of TU number. TU Number: … ErrorCode: … Please process this request." — to the PIX support team for manual handling.
   6. Mark the queue row Completed.
6. Additional PIX checks available in the object (each ending in a description letter):
   • TU state: read the TU state; if it is inactive then send the error-1009 description letter.
   • TU media: read the media setting and send the error-101 description letter.
   • Connections: search the partner TU, read the connection state; if the state is cancelled then read the start and end dates and send a description letter.
7. Close the PIX session, then send the run-complete mail with the list of failed TU numbers.
8. A separate PIX OU (organisational-unit) variant logs in the same way, iterates generations with a date range and a state filter, searches each OU receiver to read TU / name / country, writes the collected rows to C:\BluePrism\data\PIX_OU_Monitoring\PIX_OU_Data, and mails that workbook as an attachment with subject PIX OU Monitoring.

Stage 11 — ITSM-driven request variants

Package cancellation

1. Log into ITSM with Q-number QXO8154.
2. Search incidents with: Assigned group spoa:global:3rd, tag/notes filter #SD#Cancel Package#, status Resolved.
3. Read each result's notes and incident ID into queue SPOAPackageCancellation.
4. For each queued incident:
   1. Parse the package code out of the free-text notes. (The notes are conversational — a sample in the export reads "Please cancel BSI plus package 5 years/100000 km. bearing code 07NA only from the VIN … Note: Please don't cancel RI package 07CK." — so the parsing must pick the code to cancel and ignore the code to leave alone.)
   2. If no package name could be extracted then mark the queue item as an exception with reason Couldn't find Package Name and attempt no cancellation.
   3. Otherwise mark the item Completed. Note: in the export the cancellation itself (SPOA_Package_cancle :: Search Vehicle Number / Delete Package) is wired into the separate test process SPOA PAckage Cancel Test, not into the main cancellation process — the production linkage is ambiguous.
5. In SPOA, the cancellation sequence is: log in, click Service Package Deletion, select variable input, enter the chassis/vehicle number, Search; read the package table; loop the rows, skipping the header; trim and compare each package name to the requested one; if it matches, convert the registration date and check registration date >= today minus 2 months; if the date passes, tick the row checkbox; otherwise move on. Finally write the reference text and click Cancel Package.

S-Gate role change

1. Log into ITSM as above.
2. Search incidents with: Assigned group s-gate:global:3rd, tag SPOA, status Closed.
3. Read notes and incident IDs into queue SPOA Roles WorkQueue.
4. For each queued incident:
   1. Parse the requested roles, the reference user, the actual user, the environment, and an "invalid incident" indicator out of the notes.
   2. Log into S-Gate (language Englisch), navigate Menu → User Administration → Admin AG/NSC → Edit User.
   3. Enter the target Q-number and Search.
   4. Click Edit Role, iterate the requested roles and set each one, then Continue to RAUS and Save and View.
   5. Terminate S-Gate and mark the queue item Completed.
5. A related password-reset variant uses BAT rather than S-Gate: log into BAT, select the language, open Check User Integration, then — if the supplied login name contains a dot it is written to the LoginName field, otherwise to the Q-Number field — search, open the user record, and read the account status and e-mail address. If the status contains User is locked after 3 login failures or Enforce password change then send the standard self-service reset instructions (subject SGate Password Reset), which walk the user through sgate.bmwgroup.com → "Problem with Password" → "Reset Password". Otherwise no mail is sent.

Stage 12 — Citrix and parts variants

ISAR availability checks (three separate processes, each with its own purpose):

1. ISAR User Admin Performance: Citrix login → click 30_Antares-PROD → click ISAR Client → confirm the Open dialog → attach to the ISAR-Client * window → click Start → click Benutzerverwaltung → confirm the Benutzerverwaltung window appeared → log off Citrix and close the browser.
2. ISAR CLAT Logs: Citrix login → open CLAT → handle the Citrix security warning (see Exceptions) → attach to the CLAT window → Datei → Öffnen to verify the XML load.
3. ISAR Users Verification: Citrix login → 00_Administration → Konsolen → Citrix_AppCenter-PROD → in AppCenter, right-click the root, choose Configure and run discovery, click Next, untick single sign-on, Next, Remove then Add Local Computer, Next, wait, Next, Finish — this refreshes the logged-in user list.

Parts discrepancy chain:

1. Log into SAP AEP as QXI4826, run SE16N, enter table MARA, execute.
2. Export the result to ATLAS_Material_Data.xls and run the ATLAS material formatting routine over it.
3. Run the batch file Descrepancy_Check.bat, which produces Descripencies.csv.
4. Read the CSV, extract the part numbers, and write them to Parts.txt.
5. Log into Citrix, browse to http://vtpep.muc/, sign in via IWA, then navigate Internal → MQS-Production → Part Transfer.
6. Set string type to MAT, browse to \\Client\C$\Users\…\Descrepancies\Parts.txt, and click "Select Parts from file" to upload.

gAMS performance test: launch the B2B portal, sign in, My Workspace → My Applications → M-gAMS, Continue, maximise, enter the gAMS number, Open. Then click through every tab in sequence, confirming each sub-element appears within its own timeout: Timing, Control, Positions, Evaluation, AFOs, Attachments, Links, NAELs/BAW, Cash, Report View, Evaluation Overview, History. Timestamps are taken before the tab sweep and after exiting the module.

Exceptions and recovery

Condition	What the automation does	What a human should do
SAP logon fails, or the logon window never appears	The recovery block around the logon step mails SAP Logon Failed (daily) or [RPA]SAP NMS Weekly Logon Failed (weekly) with the full error detail, then ends the run. No monitoring is performed.	Check whether the SAP system is up, the user is unlocked, and the password has not expired. Re-run once resolved — nothing was exported, so there is no partial state to clean up.
SAP reports the monitoring user is already logged on	Two different behaviours exist. SAP_NMS_All_Transactions closes SAP and ends silently with no monitoring done. The ATLAS and weekly logins instead click "continue with logon" and carry on.	Confirm no other session (human or robot) is using the monitoring ID. Treat a silently-ended NMS run as "did not run", not "all clear" — the absence of a completion mail is the only signal.
A single transaction code fails mid-run (window missing, export dialog absent, timeout)	The item-level recovery block marks that queue row as an exception with the bubbled-up error text, appends the code to the Failed Transactions - string, and resumes with the next row. One bad transaction does not abandon the run.	Read the failed-transaction list in the completion mail, then inspect the exception items in the relevant queue for the underlying error. Run the missing transaction manually in SAP and add its output to the report.
An expected SAP window or field is absent within its wait timeout	An explicitly named error is raised, e.g. From Date doesn't exist, Results window doesn't exist, FileType window doesn't exist, Save popup doesn't exist, Table Name doesn't exist, Directory doesn't exist. These surface to the item-level handler above.	The named window tells you where it stopped. Usual causes are a slower-than-usual SAP response, an SAP screen/layout change, or a changed screen resolution (several steps use fixed coordinates).
PIX monitoring throws anywhere in the run	The outer recovery block mails Exception in PIX TU Monitoring with the error detail and terminates the PIX session. Item-level failures mark the queue row as an exception and record the affected TU numbers.	Check the PIX portal is reachable and the error-log table layout has not changed. Review exception items in PIXTUMonitMailSend — any TU listed there did not receive its dealer letter.
No error description exists in the Word template for a PIX error code	Falls back to the pre-written "description not found" body naming the TU number and error code, and mails it to the PIX support team instead of the dealer.	Add the missing <code> Starts / <code> Ends section to PIX Error Descriptions.docx, then handle that dealer notification manually for this run.
SPOA ticket notes contain no recognisable package name	Queue item marked as exception with reason Couldn't find Package Name. No cancellation is attempted.	Read the incident, identify the package manually, and cancel it in SPOA by hand — or correct the ticket wording so the parser can read it next time.
The SPOA package was registered more than two months ago	The date check (registration date >= today minus 2 months) fails, so the checkbox is not ticked and the loop moves to the next package row. Nothing is cancelled and no alert is raised.	This is a deliberate business rule, but it is silent. If a ticket appears to have been ignored, check the package registration date first.
ITSM search returns no results	The results-window check raises No Results found. The process-level handler mails Exception in ITSM and ends.	Verify the search filters still match live ticket data (assigned group, tag text, status). "No tickets today" and "search is broken" produce the same mail, so confirm which it was.
Finance F961 or SM13 run finds no errors	Sends an explicit all-clear mail — "We havent find any error today" / "We dont have any error." — rather than staying silent.	Nothing. Treat the all-clear mail as positive confirmation the check ran.
Invalid order data in the Create Orders consolidation exercise (blank/bad product code, quantity, unit price or cost centre)	Raises a System Exception naming the offending field, the item reference and the product code. The recovery path marks the queue item as an exception (Exception bubbled up from Object …) and exits the Order System application.	This is Blue Prism training material against a Training Order System, not a BMW business process. No business action required.
An ISAR/Citrix published application or expected window does not appear	Raises Window doesn't exist. ISAR User Admin Performance mails ISAR User Admin Perf Status with the detail. ISAR CLAT Logs and ISAR Users Verification have no recovery block, so a failure there aborts the run with no notification at all.	For the two unprotected processes, check the run status in the control room rather than relying on mail. Adding a recovery-and-notify block to both is a recommended fix.
The Citrix security warning popup appears	Attaches to the window titled Citrix Receiver - Security Warning and clicks Allow reading only.	Nothing — this is handled.
The login window fails to appear for PIX, S-Gate or a web app	The recovery block terminates the launched application and resumes, so the run either retries cleanly or ends without leaving an orphaned browser session.	Check the application URL and availability. No orphan sessions should need killing.

Data handled

Name	Holds	Source
Transaction Codes / TCodes / Codes	The list of SAP monitoring transactions to run in this pass, one per row	Pre-set inside the process (values not visible in the export)
Atlas systems	The ATLAS systems to loop over — AEP, AAP, AWP	Pre-set inside SAP_ATLAS_All_Systems
System Name	The SAP logon entry for the current pass — NRP, AEP, AAP, AWP, VDP, RWP, TSP	Passed in from the parent process, or defaulted in the object
From Date / To Date / ToDate	The reporting window for the selection screens	Calculated by Get Dates: yesterday-to-today, or Friday-to-today when run on a Monday; Thursday-anchored for weekly; Sunday-anchored for stock
Failed Transactions	Running text list of transaction codes that failed, default prefix Failed Transactions -; becomes the completion-mail body	Appended by the item-level recovery block
LoggedOnMsg / logged on	Login outcome text; the value Already Logged In triggers the early abort	Returned by the SAP login page
Item ID, Data, Status, Attempts	The current queue row's reference, payload fields, state and retry count	Returned by the "get next item" step
Directory / FileName	Export target, e.g. C:\BluePrism\data\SAP_NMS\ + NMS_ST22.xls, ATLAS_SM12.xls, NMS_Weekly_SM37	Pre-set per transaction handler
Errorcodes / ST22 ErrorCodes / ErrorDesc	The distinct ST22 runtime-error codes read back from the export, and the descriptions retrieved for each	Produced by the Excel formatting routine, then by the SAP filter-and-export loop
ST22UniqueData, SM12LockEntries, SM13CancelledJobs, SM21DatabaseErrors, SM37CancelledJobs, SMQ1Errors, SMQ2Errors, SM58StruckRFCs, SMGWErrors	The consolidated figures the report is built from	Produced by the consolidated report routine over the exported spreadsheets
ErrorCollection / Error Collection / TUErrorDetails	The PIX error-log table as read from screen, then de-duplicated	Read from the PIX Error Log page, written to Error_Code.xlsx, filtered by the de-duplication routine
Country Code, DealerEmail, Support Group Email	The market of a technical unit and the addresses to notify	Country code read from PIX; addresses looked up in PIX_Dealer_Info.xlsx
Starts With / Ends With / Content / output	The template section markers (<code> Starts / <code> Ends) and the extracted, placeholder-substituted letter body	Built from the error code; text pulled from PIX Error Descriptions.docx
Failed TU Numbers	Technical units whose letter could not be sent; becomes the PIX completion-mail body	Set by the PIX item-level recovery block
Collection (ITSM)	One row per matching incident, carrying the notes text and the incident ID	Read from the ITSM search results window
Notes	The free-text incident body that the parsers mine for user names, roles, environment, vehicle numbers and package codes	ITSM incident record
PackageName / Actual Package / Final Date	The package to cancel, and its registration date for the two-month eligibility check	Parsed from incident notes; date read from the SPOA package table
Roles / Reference User Details / ActualUser / Environment / IsInValidIncident	The role-change request as parsed out of the incident notes	Parsed from ITSM notes
Email Id, User Status	The BAT account's e-mail address and lock/password status, used to decide whether to send reset instructions	Read from the BAT user record
Query / Query Results	select user_id,password from system_credentials where application_name='NMS'; and its result	SQL Server localhost\SQLExpress, database BMW_RPA
session_all / session_process / result	Total, processed and errored SM35 batch session counts; substituted into [count] and [count1] in the Finance mail body	Read from the SM35 screen; result is the arithmetic difference
IsErrorExist	Whether the F961 export contains any error rows, deciding all-clear vs alert mail	Computed over the read F961 spreadsheet
Time1 / Time2	Start and end timestamps around the gAMS tab sweep	Set before and after the gAMS module
Attachment	Attachment list for the PIX OU mail (the PIX_OU_Data workbook)	Built during the PIX OU run

Not determinable from the source

• No schedule exists in the export. Which processes run daily versus weekly, at what time, and in what order (notably whether SAP_ATLAS_All_Systems is the single daily entry point for all three ATLAS systems) cannot be recovered.
• The seeded work-list contents are not visible. The definitive per-system transaction list and its ordering, held in the Transaction Codes / TCodes / Atlas systems data items, cannot be confirmed.
• No acceptance criteria are recorded. What count of ST22 dumps, SM12 locks, SMQ1 queue errors or SP01 spool errors constitutes a problem requiring escalation is stated nowhere. The bot reports; it does not judge.
• The real recipients are unknown. Every mail is addressed to the developer's own Accenture address (or a colleague's), which looks like test wiring rather than a production distribution list.
• Queue governance is undefined — ownership and SLA for NMSWorkQueue, NMSWeeklyWorkQueue, SAPAtlasWorkQueue, SAP_ATLAS_Systems, PIXTUMonitMailSend, SPOA Roles WorkQueue, SPOAPackageCancellation; retry limits; and who clears exception items.
• Where the finished report goes. The completion mails carry only the failed-transaction text and the attachment parameter is left unset in most calls, so it is unclear whether the formatted monitoring workbook is filed centrally, attached, or simply left on disk.
• Volumes and scale — errors per transaction per day, PIX error rows per run, ITSM tickets per day — are absent.
• The template files live outside the export. Rebuilding on another platform requires the NMS report layout, the ATLAS BND template, and PIX Error Descriptions.docx with its section markers.
• Credential handling is inconsistent — some hard-coded in plaintext (Landshut muc\qxq0595 / 1qaz1qaz; SAPConnection qxq0595 / 4rfv4rfv), some read from SQL, some left blank for a credential store. The intended production mechanism is unclear, and the hard-coded ones are a security finding.
• Several assets are stubs or scratch work with no caller. BAT User Status, SAP NMS Weekly Monitoring Process, SendMail and Mainframe are empty. Blueprsim duplicates PIX_TU_Monitoring. sample, sample1, MaxDate, TestWorkQueue, queue Queue 1, ST22_NWS, Hilliards Readiness VBO and SQL Developer VBO appear to be development leftovers. Which are in production cannot be determined.
• Create Orders is labelled a "Consolidation Exercise" against a Training Order System reading C:\BluePrism\Training\Applications\Windows\Orders.csv — almost certainly Blue Prism training material, not a BMW business process.
• The Landshut object has no caller. It reads user-access request approvals (BV / Key User / Business / Local Admin release, completion date) and calls SAPConnection, but no process invokes it. Its business purpose and trigger are unknown, and it stops after 8 records (counter < 9) for reasons not explained.
• The gAMS performance test records timestamps but nowhere shows where Time1 / Time2 are written or what threshold makes the performance acceptable.
• SAP Stock Monitoring loops exactly 8 spool exports (counter < 8) with hard-coded screen Y offsets 328/340 incremented per iteration. Why 8, and how the coordinate approach is meant to survive a resolution change, is undocumented.
• Downstream use of the MQS Part Transfer upload and the discrepancies CSV — who consumes the corrected parts data, and what happens if the upload fails — is not shown.
• The SPOA cancellation linkage is ambiguous. The main SPOA Package Cancellation process parses the package name and marks the item done but does not visibly call the search-and-cancel steps; those appear only in the separate SPOA PAckage Cancel Test process.

---

How this SOP was checked

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

Very strong coverage of the common SAP monitoring pattern: login (incl. AAP-vs-AEP password branch, System Message / multiple-logon dialogs, 'Already Logged In' early abort in SAP_NMS_All_Transactions), queue seeding per process with correct queue names, item routing (CHOOSE on t-code; AEP/AAP vs AWP on system name), per-transaction selection-screen detail and export path, ST22 filter-and-export description loop, Excel template routines (Update NMS Template / ATLAS BND / Weekly keys incl. NMS_Weekly_ST22.MHTML), completion/exception mail subjects, PIX TU dealer-letter chain with the 4-digit/PartnerTU condition and dealer lookup, ITSM->SPOA and ITSM->S-Gate variants with correct filters (spoa:global:3rd/#SD#Cancel Package#/Resolved; s-gate:global:3rd/SPOA/Closed), BAT password-reset conditions, Citrix/ISAR/gAMS/TF-parts variants, and honest flagging of stubs, hard-coded credentials, missing schedule and the ambiguous SPOA cancellation linkage. Weak spots: SAP Stock Monitoring's own flow (AW spool loop -> AE table display -> consolidation macro) is only fragmentarily described; queue SAPNMWWorkqueue is never accounted for; some VDS/Mainframe_WEB objects with no caller are not listed among leftovers.

Remaining minor notes:

• Stage 9, subject-line table row 'SAP_StockMonitoring_Process | SAP Stock Monitoring Status' — Presented as the run-summary/completion mail. In the source, SAP_StockMonitoring_Process contains only one Send Mail, inside CATCH Recover1, with body ExceptionDetail(); there is no completion mail at all. (Move this row out of the completion-mail table and state that Stock Monitoring reports only on failure (exception mail 'SAP Stock Monitoring Status'); a successful run is silent.)
• Exceptions table, row 'ITSM search returns no results' — States the process-level handler mails 'Exception in ITSM' and ends. That handler exists only in 'Set SPOA Role -SGate'. 'SPOA Package Cancellation' has no recovery block anywhere in its outline, so an ITSM 'No Results found' there aborts with no notification. (Split the row: role-change variant mails 'Exception in ITSM'; package-cancellation variant has no recovery/notification and fails silently.)
• Stage 9 step 2 / Exceptions row 'A single transaction code fails mid-run' — Generalises the 'Failed Transactions -' accumulation and completion mail to all queue-driven runs. SAP_ATLAS_All_Transactions, SAP_ATLAS_AWP_All_Process and SAP_ATLAS_All_Systems have no 'Failed Transactions' data item and send no mail at all — their item recovery only calls Mark Exception and resumes. (Scope the failed-transaction string and completion mail to the NMS daily/weekly and PIX processes; note that the ATLAS processes record failures only as queue exception items, with no e-mail.)
• Stage 12, parts discrepancy chain step 5 ('sign in via IWA') — TF_Atlas_Descrepancies uses CITRIX_TF VBO, whose Login page types the URL then Q-number and password into the URL-region fields and clicks a Login button. The IWA Login button belongs to the separate 'Citrix Login' object, which this chain does not call. (Describe the TF chain as: attach to 'MyNetwork *', type http://vtpep.muc/, enter Q-number qxp5286 and password, click Login. Attribute IWA sign-on to the 'Citrix Login' object only.)
• Stage 12, gAMS paragraph ('Timestamps are taken before the tab sweep and after exiting the module') — Execution order in the source is: Tab selection -> SET Calc1 (Time1) -> Exit module -> SET Calc2 (Time2). Time1 is captured after the tab sweep, not before it. (State that the first timestamp is taken after the tab sweep completes and the second after the module/portal exit, so the measured span covers the exit only.)
• Stage 1 step 2 (read credentials from SQL first) — Implies the SQL credential lookup is part of the standard target-system login. Only the older objects NMS_SM12_VBO and SAP_NMS_VBO call Connect To Database :: DB Connect; the production login objects (SAP_NMS_All_TC_VBO, SAP_NMS_Weekly_Monitoring_VBO, SAP_ATLAS_*) use hard-coded/blank data items (e.g. QNo qx68203). (Note that the SQL 'system_credentials' lookup appears only in the legacy NMS objects; the processes actually invoked use in-process data items.)
• Stage 2 note 4 / Exceptions row 'already logged on' — Says the ATLAS and weekly logins handle it by clicking 'continue with logon'. The 'continue with logon' step is present in SAP_Atlas_All_Trans_VBO's Multiple Logon handling; the weekly VBO (and SAP_ATLAS_AWP_All) merely activate an 'Already Logged In' window and set the LoggedOnMsg text — no continue click is shown. (Distinguish: ATLAS all-trans clicks 'continue with logon'; the weekly and AWP logins only record 'Already Logged In' as an output that the calling process discards.)
• Stage 9 subject table, 'SAP_FI_F961_Prod | SAP F961' — Listed as a run-report subject. In SAP_FI_F961_Prod the subject 'SAP F961' belongs to the process recovery block (body = ExceptionDetail(), to balram.goud@accenture.com); the object separately mails 'SAP F961' (error found) and 'SAP F961 monitoring' / 'SAP FI BD87 Monitoring' (all-clear) to other recipients. (Split the F961 mails by trigger and recipient: exception mail from the process, and the error/all-clear mails from SAP_FI_F961_P (noting the mislabelled 'SAP FI BD87 Monitoring' all-clear subject).)
• Coverage — SAP Stock Monitoring and unused queue — The Stock Monitoring end-to-end flow (AWQ login -> SM37 job selection STOCKCHECK_* -> 8-iteration spool export loop with fixed Y offsets -> AEQ login -> SE16N MBEW/a190 table display -> AE export -> MS Excel SAP_AWPMacrocode consolidation) is scattered across stages rather than described as a run. Queue 'SAPNMWWorkqueue' listed in the source is never mentioned or accounted for. (Add a short dedicated Stock Monitoring stage in that order, and list SAPNMWWorkqueue as a defined queue with no referencing process in the export.)