- 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[" Log Event"] Details[" Event details"] Payload[" Payload"] Context[" Context Properties"] Event --> Details Event --> Payload Event --> Context style Event fill:#87CEEB style Details fill:#90EE90 style Payload fill:#90EE90 style Context fill:#90EE90

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[" Log API"] Service[" Logging Service"] Context[" Context Options"] MsgType[" Message Type"] Search[" Search Fields"] Bind[" Repository Binding"] Repo[" Repository Model"] API --> Service Service --> Context Service --> MsgType Service --> Search Context --> Bind MsgType --> Bind Search --> Bind Bind --> Repo style API fill:#87CEEB style Service fill:#90EE90 style Context fill:#FFD700 style MsgType fill:#90EE90 style Search fill:#90EE90 style Bind fill:#90EE90 style Repo fill:#87CEEB

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[" Log Event"] Bind[" Repository Binding"] Systems[" Systems"] Services[" Services"] Contracts[" Contracts"] Integrations[" Integrations"] Landscape[" Integration Landscape"] Event --> Bind Bind --> Systems Bind --> Services Bind --> Contracts Bind --> Integrations Systems --> Landscape Services --> Landscape Contracts --> Landscape Integrations --> Landscape style Event fill:#87CEEB style Bind fill:#90EE90 style Systems fill:#90EE90 style Services fill:#90EE90 style Contracts fill:#90EE90 style Integrations fill:#90EE90 style Landscape fill:#87CEEB

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[" Grouped Log View"] Participants[" Participants mode"] SystemsMode[" Systems mode"] Runtime[" Runtime Diagram"] Group --> Participants Group --> SystemsMode Participants --> Runtime SystemsMode --> Runtime style Group fill:#87CEEB style Participants fill:#90EE90 style SystemsMode fill:#90EE90 style Runtime fill:#FFD700

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[" Log Event"] Repo[" Repository Model"] BPMNode[" BPM"] MapifyNode[" Mapify"] C4Node[" C4 Diagrams"] Event --> Repo Repo --> BPMNode Repo --> MapifyNode Repo --> C4Node style Event fill:#87CEEB style Repo fill:#90EE90 style BPMNode fill:#FFD700 style MapifyNode fill:#90EE90 style C4Node fill:#90EE90

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 Step