Monitor and Act from the BPM
Knowing that an order failed is half the job; the other half is fixing the system behind the step. A Nodinite BPM puts logging and monitoring on the same drawing, so you go from "this step failed" to "this service is stopped" to "started again" without switching tools.
- ✅ A lightbulb on each Service shows the worst state of the Resources behind it
- ✅ Remote Actions from the BPM, the same ones as in a Monitor View, for the Roles you allow
- ✅ Every Remote Action is recorded in the audit log
- ✅ Non-Events Monitoring alerts when expected messages don't arrive at all
The Business Context
In the Order-to-Cash demo, each step of the process is a Service in the BPM. Behind each Service run real things that a Monitoring Agent watches as Resources: a Windows service, a scheduled task, an IIS application pool, a queue.
The Problem
Logging and monitoring usually live in different tools. Support sees that an order stopped at Confirmation Sent; operations sees a stopped task on a server; and nobody connects the two until someone with server access is found.
The Solution
See Health on the Process
Link the Resources to the Service of the step they serve, and the worst state of those Resources shows on the BPM: one Resource in Error turns it red. Unavailable and Connection Error outrank Error, so a Service with one Resource in Error and one Unavailable shows light gray; Integrated Monitoring explains how the color is picked. Where you see it depends on the view:
- In the BPM Designer, the whole Service shape takes the worst Resource state.
- In BPM Log Search and the BPM Viewer, the steps take the Log Status Code of the order's events, and the lightbulb on each Service takes the worst Resource state.
Order Received has a healthy lightbulb; Confirmation Sent and Order Invoiced have Resources in Error. Services with no linked Resources show no lightbulb.
Confirmation Sent] R2[fa:fa-server Resource Error] --> S S --> L[fa:fa-lightbulb Lightbulb Error
worst state wins] style R1 fill:#93d16d style R2 fill:#c33d34 style S fill:#2678BD style L fill:#c33d34
Green OK, red Error: the worst state wins, so healthy Resources never hide a failing one.
Use the two together: the event tells you what failed for this order, the lightbulb tells you whether the system is still failing.
Act Where You See It
Click the lightbulb to list the Service's Resources with their state and log text, each with an Action button.
The Resources behind Confirmation Sent: a scheduled task in Error and an IIS application pool that is OK.
From there, users run Remote Actions. They are the same actions as in a Monitor View, provided by the Monitoring Agents for each Resource, such as starting or stopping a Windows service; which ones exist depends on the agent and changes as agents evolve. An administrator decides per Role who may run them, so operations can restart a service while business owners only look. Knowledge Base Articles linked to the Resources tell the person on duty what to do.
The Action menu groups Monitor Views, Resource history and Articles, administration links, and Control Center, where the Remote Actions the agent provides for this Resource appear.
Catch What Never Happened
A failed step is visible; an order that never arrived isn't. Non-Events Monitoring alerts when expected messages don't arrive or volumes fall outside what you expect.
The Results
- Support, operations, and business owners look at the same picture of the process.
- The person who spots a stopped service can restart it, if their role allows, without remote desktop access to the server.
- Problems with the systems behind a step show on the BPM even when no order is in flight.
How This Scenario Uses Nodinite Features
- Integrated Monitoring - lightbulb and Resource details on each BPM Service
- Resources and Monitoring Agents - the monitored systems behind each step
- Remote Actions - start, stop, and other actions, controlled by Roles
- Knowledge Base Articles - instructions next to the Resource
- Non-Events Monitoring - alerts on missing or late messages