Inspect grouped Log Views as runtime diagrams

When a business transaction spans multiple Services and Systems, a grouped Log View can do more than list related Log Events. It can open a runtime diagram that helps business users, support teams, and integration specialists understand what happened without manually stitching the story together.

If your environment includes Architecture Diagrams, the same visual language can be used to inspect a grouped Log View without creating a stored diagram first.

• Move from a grouped Log View to a visual runtime diagram in one step
• Start with Systems mode for an easy system-to-system overview
• Switch to Participants mode when you need Service-level or Contract-level detail
• Keep BPM milestones and related events close to the same investigation

What this view helps you answer

• Which System handled the transaction first, next, and last?
• Where did the flow stop or become unclear?
• Which related events belong to the same business transaction?
• Does the BPM milestone match the actual runtime path?

How the runtime diagram helps

Diagram: A grouped Log View becomes a runtime diagram you can read in Systems mode or Participants mode (Services and/or Contracts), while BPM keeps the business milestones visible and the Issues section keeps unresolved steps explicit.

Participants mode

Use Participants mode when you need to inspect the actual runtime handoffs. The diagram shows the participant that best matches each step in the grouped Log View.

Participants can resolve to:

• a Service when the runtime step clearly maps to one Service
• a Contract when the runtime step clearly maps to one Contract but not one Service
• an ambiguous participant when several candidates fit the same step
• an unknown participant when the related events do not resolve to a clear participant

This makes Participants mode useful for troubleshooting, handover reviews, and operational root-cause analysis.

Systems mode

Use Systems mode when you need a fast business-friendly overview. Instead of showing every participant separately, the diagram rolls the same runtime path up into System boundaries.

Systems mode is especially useful when you want to:

• explain a transaction path to business stakeholders
• see cross-system handoffs before drilling into detailed events
• focus on which system owns the current problem
• spot steps that still land in Unknown System because the Repository needs more context

System boundaries open collapsed by default, so the first view stays easy to read even when a transaction crosses many Services.

Unknown and ambiguous steps are useful

Unknown and ambiguous steps are not noise. They tell you where the grouped Log View or the Repository needs more work.

Typical causes include:

• the group contains events that are too broad for one business transaction
• the related events are missing clear Repository bindings
• a Service or Contract exists, but the owning System is missing
• multiple Services or Contracts could match the same step

When you see these markers, keep using the related events list and BPM milestone view to continue the investigation while the Repository is improved.

Where BPM fits

BPM and the runtime diagram answer different questions:

Use them together:

1. Start in BPM when the business wants milestone status.
2. Open the grouped Log View for the transaction or milestone that needs attention.
3. Open the runtime diagram to see the real path across participants or Systems.
4. Return to the related events list when you need payload, comments, or detailed event history.

Next Step

• Working with Nodinite Log Views
• Business Process Model (BPM)
• Inspect grouped Log Views as runtime diagrams

Related Topics

• What is a Log View?
• Design grouped Log Views for runtime inspection
• Architecture Diagrams
• What is a Search Field?
• End-to-End Process Tracking