End-to-End Process Tracking
A business transaction, such as an order, passes through several systems, and each one logs its own events. End-to-End Process Tracking is how Nodinite brings those events together and plots them on a BPM, so you see one order across all its steps instead of searching each system's log.
This page explains what has to be in place for that to work, using the Order-to-Cash demo. To search a BPM as a user, see Search log events from a BPM.
Understanding the Tracking Chain
You provide the correlation: a key that every event of the transaction carries, and the Search Fields users search on. From there Nodinite works out by itself which BPMs can display the events of the interchange, with no binding to a BPM at design time; Role permissions and explicit Log View associations can narrow that. Each link in the chain below is something you log or configure once:
Endpoint · Message Type
Payload · Context] --> B[fa:fa-gear Event bound to a Service
via Transport Contract] A --> C[fa:fa-magnifying-glass Search Field Expressions
extract Order Number] B --> E[fa:fa-arrow-progress Step on the BPM
colored by Log Status Code] C --> D[fa:fa-hard-drive Log View
search, then group by
Application interchange id] D --> E style A fill:#2678BD style B fill:#3F827B style C fill:#E47528 style D fill:#E47528 style E fill:#93d16d
Blue: logged by your integrations. Teal: Repository binding. Orange: administrator configuration. Green: the result on the BPM.
Key Components Explained
| Component | Role | O2C demo |
|---|---|---|
| Log Event | One logged occurrence, with an Endpoint, a Message Type, a Log Status Code, and optionally a payload (Body) and context properties. The format is defined in JSON formatted Log Event. | One event per step, Message Types O2C.Order.Received/1.0 to O2C.Order.Invoice/1.0 |
| Services and Transport Contracts | Decide which BPM cell an event belongs to. A Service's Transport Contracts tie an Endpoint and Message Type to it. | Created from the Repository Binding in each event's context |
| Search Fields and Search Field Expressions | Make business values searchable. An administrator adds expressions per Message Type that read the payload (XPath, JSONPath, RegEx, CSV…), a context property (Message Context Key), or a Log Event field (field()). | Order Number, extracted from each step's message |
| Log View | Selects the events you may search, and groups them into transactions by a group-by field. | Order 2 Cash, grouped by Application interchange id |
| Log Status Codes | Set the step color. | 0 success; -1337 on the step where an order stops |
Why Grouping and Searching Are Separate
The group-by field and the Search Fields do different jobs. In the demo, users search on Order Number because that's what they know, while the Log View groups on Application interchange id, a Log Event field that every event of one order carries regardless of message format. The result is presented per group, so you pick an order, not a single event.
What the Log View Looks Like
The O2C Log View groups on Application interchange id with Lock group by turned on, so users can't break the grouping the BPM relies on:
The group-by field defines the transaction; locking it keeps every user on the same definition.
On the Search criteria tab, Auto Start Search runs the search when the page opens, and the Time Interval Configuration sets the default range:
Order ID is both a restriction (Not Empty) and the default search field.
See Log Views for BPM search for the recommended settings.
What You See
Search from the BPM with BPM Log Search New 7.11, or open a grouped Log View. The events of the selected group are listed, and each step with events takes the color of its Log Status Code. Steps with no events stay gray.
Order PIC-20261009-1644-0010 reached Confirmation Sent, which failed. Steps 4–7 have no events yet.
When several groups match, you choose which one to plot:
Each row is one order (group), with its event count and first and last log time.
In a grouped Log View the same events appear with every BPM that matches them:
A grouped Log View showing the process state and history of one transaction.
With Hierarchical BPMs New 7.3, a grouped Log View matches events from the master process and its sub-processes. From the group header you open the parent BPM or one of its sub-processes, and from a sub-process opened this way a button takes you back to the parent.
When a Step Stays Gray
| Check | Why |
|---|---|
| The event was logged, in the Log View's time range | No event, no color. Use Non-Events Monitoring to alert on milestones that don't arrive. |
| The event's Endpoint and Message Type are bound to the Service in that cell | Otherwise the event isn't placed on the BPM. |
| The event carries the same group-by value as the rest of the transaction | Otherwise it lands in another group. |
| A Search Field Expression exists for the event's Message Type | Otherwise searching on the business value can't find it. Search Fields can re-index historical events after you add an expression. |
A gray step between colored ones is a different signal. If later steps of the same order have events but an earlier one doesn't, the message most likely did pass that step, but something changed at run time, such as a new Endpoint or Message Type. Inspect the step's events and adjust the Service's Transport Contracts; because binding is resolved when the BPM is displayed, the step colors as soon as the contract matches.
Practices That Pay Off
- Log at business milestones, such as Order Received or Order Invoiced, not every technical hop. One event per BPM step keeps the picture readable.
- Carry one transaction key on every event, in context or as a Log Event field, and group the Log View by it. Business values change shape between systems; a technical key doesn't.
- Set Log Status Codes that reflect the business outcome, so a red step means something to the business reader.
- Use Search Field Links for the next hop: they turn an extracted value, such as an order number, into a link to the record in your ERP or CRM.