Design grouped Log Views for Runtime Inspection
A grouped Log View can become a powerful runtime inspection experience, but only when the group truly represents one business transaction and the Repository has enough context to resolve Services, Contracts, and Systems. This guide explains what administrators should configure so users get a clear Participants mode and Systems mode instead of a confusing pile of related events.
- Group one business transaction at a time
- Keep related events easy to explain to business and operations users
- Give the runtime inspection view enough Repository context to resolve Services and Systems
- Make unknown or ambiguous results rare, useful, and actionable
How admin choices affect the user experience
Find the right transaction"] Grouping[" Group by
Create one coherent group"] Repo[" Repository
Service, Contract, System"] Participants[" Participants mode
Detailed runtime path"] Systems[" Systems mode
Rolled-up overview"] Issues[" Issues
Unknown or ambiguous steps"] Search --> Grouping Grouping --> Participants Repo --> Participants Repo --> Systems Participants --> Issues Systems --> Issues style Search fill:#87CEEB style Grouping fill:#FFD700 style Repo fill:#90EE90 style Participants fill:#90EE90 style Systems fill:#90EE90 style Issues fill:#FF6B6B
Diagram: Search Fields help users find the right business transaction, Group by defines the related events in scope, and Repository data determines how clearly the runtime inspection view can resolve participants and Systems.
What runtime inspection needs
| Need | Why it matters | Recommended admin action |
|---|---|---|
| One business transaction per group | Users trust the story only when the related events belong together | Use Group by on a stable business identifier or interchange identifier |
| Useful related events | Too many unrelated events make Participants mode noisy | Narrow the Log View with Systems, Services, Message Types, Endpoints, or Roles when needed |
| Search Fields that match business language | Business users must be able to find the right group quickly | Expose Search Fields for order numbers, invoice numbers, shipment IDs, customer IDs, or similar identifiers |
| Repository bindings | Runtime inspection resolves better when events map to a Service or Contract | Keep Repository bindings and Transport Contract assignments current |
| System ownership | Systems mode depends on clear System ownership | Ensure each Service or Contract belongs to the right System |
Choose Group by wisely
Use Group by to define what the user will later inspect as one runtime story.
| Group by choice | Good fit | Watch out for |
|---|---|---|
| Order ID, invoice number, shipment ID, or similar business identifier | Business-facing troubleshooting and audit work | Only works when every related event carries the same identifier |
| Application or interchange identifier | Technical transaction tracing across several platforms | Can become too broad if one identifier covers a batch instead of one transaction |
| Endpoint only | Narrow operational searches | Usually too broad for runtime inspection because many unrelated events can share one Endpoint |
| Log Status or time alone | Exception review and monitoring sweeps | Rarely useful as the main Group by for a runtime diagram |
Test a sample group before publishing the Log View. If the group tells a clean story in the event list, it usually tells a clean story in the runtime inspection view as well.
Build a useful Participants mode
Participants mode works best when the Repository can identify one clear participant for each step.
Aim for these outcomes:
- a Service appears when one Service is the clear match
- a Contract appears when one Contract is clear but the Service is not
- ambiguous participants stay visible when several candidates match the same step
- unknown participants stay visible when the related events cannot be tied to a clear participant
Transport Contract information is especially important here because it helps the runtime inspection view keep sender, receiver, and flow direction understandable.
Build a useful Systems mode
Systems mode depends on clear System ownership in the Repository. When the runtime inspection view can tie a participant to a System, it can roll the step up into a System boundary and keep the overview readable.
Systems mode becomes more useful when you:
- give Systems business-friendly names
- keep Services assigned to the right System
- review Contracts that still lack a clear System owner
- accept that Unknown System is better than a misleading placement
Common reasons the runtime inspection view is noisy
| Symptom | Likely cause | What to review |
|---|---|---|
| Too many related events in one group | Group by is too broad | Tighten the grouping key or narrow the Log View scope |
| Too many unknown participants | Missing Repository bindings or missing Transport Contract information | Review Services, Contracts, and Repository bindings |
| Many steps in Unknown System | Services or Contracts do not have a clear System | Review System ownership in the Repository |
| Several ambiguous participants | Multiple Services or Contracts share the same Transport Contract context | Clarify ownership, naming, and grouping choices |
Admin checklist
- Expose Search Fields that help users find that transaction quickly.
- Choose a Group by value (requires a search field) that represents one business transaction.
- Validate that a sample group contains the right related events.
- Review the Repository so Services, Contracts, and Systems are complete.
- Test both Participants mode and Systems mode with real production-like data.
- Keep the Log View focused enough that the runtime inspection story stays easy to read.