- 3 minutes to read

How Log Events Become Repository Model Stories, Runtime Diagrams, and Mapify Views

Imagine a Log Event as a tiny note that Nodinite can read.

The note says three simple things:

  • what happened
  • what was sent
  • what extra labels came with it

Those labels help the Logging Service connect the note to the Repository Model.

What is inside one Log Event?

Every Log Event has three small parts:

  • Event details - when, where, and how the event arrived
  • Payload - the message itself
  • Context Properties - the helper labels that explain what the message means
graph TD Event["fa:fa-envelope Log Event"] Details["fa:fa-clock Event details"] Payload["fa:fa-box Payload"] Context["fa:fa-tags Context Properties"] Event --> Details Event --> Payload Event --> Context style Event fill:#2678BD style Details fill:#93d16d style Payload fill:#93d16d style Context fill:#93d16d

Diagram: One Log Event contains event details, payload, and Context Properties. Nodinite reads all three parts before it decides how to connect the event to the Repository Model.

How the note gets read

The Log API hands the Log Event to the Logging Service. The Logging Service reads the note, checks the Context Options, and decides how the event should connect to the Repository Model.

Think of Context Options as little helper stickers. They tell Nodinite which Message Types to expect, which Search Fields matter, and how the event should support Repository Binding.

graph TD API["fa:fa-cloud Log API"] Service["fa:fa-gears Logging Service"] Context["fa:fa-tags Context Options"] MsgType["fa:fa-file-lines Message Type"] Search["fa:fa-magnifying-glass Search Fields"] Bind["fa:fa-link Repository Binding"] Repo["fa:fa-sitemap Repository Model"] API --> Service Service --> Context Service --> MsgType Service --> Search Context --> Bind MsgType --> Bind Search --> Bind Bind --> Repo style API fill:#2678BD style Service fill:#93d16d style Context fill:#FFD525 style MsgType fill:#93d16d style Search fill:#93d16d style Bind fill:#93d16d style Repo fill:#2678BD

Diagram: The Log API sends the event to the Logging Service. The service reads Context Options, Message Types, and Search Fields, then creates or updates Repository Binding in the Repository Model.

How the Repository Model grows

The Repository Model is the grown-up map behind the scenes.

When the event has enough clues, Nodinite can connect the story to:

That means the same Log Event can help build living knowledge about the Integration Landscape.

graph TD Event["fa:fa-envelope Log Event"] Bind["fa:fa-link Repository Binding"] Systems["fa:fa-building Systems"] Services["fa:fa-cog Services"] Contracts["fa:fa-file-contract Contracts"] Integrations["fa:fa-diagram-project Integrations"] Landscape["fa:fa-map Integration Landscape"] Event --> Bind Bind --> Systems Bind --> Services Bind --> Contracts Bind --> Integrations Systems --> Landscape Services --> Landscape Contracts --> Landscape Integrations --> Landscape style Event fill:#2678BD style Bind fill:#93d16d style Systems fill:#93d16d style Services fill:#93d16d style Contracts fill:#93d16d style Integrations fill:#93d16d style Landscape fill:#2678BD

Diagram: The same Log Event can connect to Systems, Services, Contracts, and Integrations. Together they form the Integration Landscape.

How one group becomes a runtime story

When Log Views are grouped, Nodinite collects the matching Log Events for one business trip.

That grouped view can then become a Runtime Diagram.

There are two easy ways to read it:

Mode Kid version What it shows
Participants mode The people or helpers in the story Which Service or Contract handled each step
Systems mode The big boxes in the story How the same trip moved from System to System
graph TD Group["fa:fa-layer-group Grouped Log View"] Participants["fa:fa-share-nodes Participants mode"] SystemsMode["fa:fa-building Systems mode"] Runtime["fa:fa-diagram-project Runtime Diagram"] Group --> Participants Group --> SystemsMode Participants --> Runtime SystemsMode --> Runtime style Group fill:#2678BD style Participants fill:#93d16d style SystemsMode fill:#93d16d style Runtime fill:#FFD525

Diagram: A Grouped Log View becomes a Runtime Diagram. You can read the same story in Participants mode or Systems mode.

Why BPM, Mapify, and C4 all care about the same facts

  • BPM shows the business step.
  • Mapify shows the big interactive relationship map.
  • C4 Diagrams show the architecture shape in a structured way.

All three can use the same Repository Model facts that started with the Log Event.

graph LR Event["fa:fa-envelope Log Event"] Repo["fa:fa-sitemap Repository Model"] BPMNode["fa:fa-project-diagram BPM"] MapifyNode["fa:fa-map Mapify"] C4Node["fa:fa-diagram-project C4 Diagrams"] Event --> Repo Repo --> BPMNode Repo --> MapifyNode Repo --> C4Node style Event fill:#2678BD style Repo fill:#93d16d style BPMNode fill:#FFD525 style MapifyNode fill:#93d16d style C4Node fill:#93d16d

Diagram: One Log Event helps build the Repository Model. The same Repository facts can then feed BPM, Mapify, and C4 Diagrams.

Tiny cheat sheet

Thing Easy way to think about it
Log Event A tiny note from a running system
Context Options Helper stickers that explain the note
Repository Binding The string that ties the note to the map
Grouped Log View A pile of notes that belong to one trip
Runtime Diagram The story of that trip
Mapify The big interactive playground map
C4 Diagrams The neat blueprint version of the same facts

Next Steps