Log Event

A Log Event is the JSON object that every logging solution sends to Nodinite, whether it is one of the out-of-the-box Log Agents or your own code. It records one business or technical event, optionally with the message itself, so you get end-to-end logging across any platform.

This page explains the parts of a Log Event, how to deliver it, and what happens after it arrives. The Reference Pages section at the end lists where each field and value is documented.

The Three Parts of a Log Event

A Log Event has mandatory details and an optional payload and context.

The three parts of a Log Event: details (blue, mandatory), payload (orange, optional), and context (green, optional).

Deliver Log Events

Log Events reach Nodinite in three ways:

• Nodinite Log Agents collect events from the platform and push them into Nodinite for you, for example the Azure Logic Apps agent and the IBM Integration Bus and ACE logging of the IBM MQ agent. You don't write any Log Events yourself.
• Synchronous: your own code posts the Log Event directly to the REST-based Log API; see Log using REST.
• Asynchronous (recommended for your own code): write the Log Event to an intermediate store, such as a queue, a folder, or a database table, and let the Nodinite Pickup Log Events Service Logging Agent fetch it and pass it on to the Log API; see Asynchronous Logging.

Nodinite Log Agents (blue) and custom code (purple) post directly to the Log API (green); asynchronous custom logging goes through an intermediate store (orange) that the Pickup Service (teal) reads.

Why Asynchronous Logging Is Recommended

• Your logging solutions don't depend on the Log API; reboot or update Nodinite whenever you like.
• You don't need to write your own retry logic.
• The Pickup Service manages delivery and concurrency, so the Log API is never overloaded.
• The decoupled architecture lets you change either side without touching the other.

What Happens After You Log an Event

The Logging Service processes every Log Event in four steps, which turn a raw integration event into business-friendly, searchable data without custom queries or database knowledge.

Step 1: Event Received (Unprocessed)

• The Log Event arrives through the Log API (REST) or the Pickup Service (asynchronous).
• It is stored in a Log Database with the status Unprocessed.
• It waits for the Logging Service.

Step 2: Message Type Determination

The Logging Service determines the Message Type, which identifies the format or schema of the message, from:

• the OriginalMessageTypeName field of the Log Event, if provided;
• the XML payload (namespace + root node);
• a schema property in the JSON payload;
• the UNH segment of an EDIFACT payload, formatted by the EDIMessageTypeParseString System Parameter;
• a Context Options override, such as ExtendedProperties/1.0#MessageTypeName.

For Microsoft BizTalk Server, flat file and EDI messages get a post-processing step: the Logging Service looks up the schema in the BizTalk Server configuration database to resolve the proper Message Type, and an Endpoint can set a Message Type for passthru interchanges; see Message Types for BizTalk Server.

Step 3: Search Field Extraction

• The Logging Service decodes the body with the resolved character encoding: the ExtendedProperties/1.0#Encoding context property first, then an encoding named in the XML declaration of the body, then the Character encoding of the Endpoint, then the one of the Message Type (default UTF-8 without BOM) ^{New 7.11}
• It finds the Search Field Expressions bound to the Message Type, and each expression extracts values from the payload or the context:
  • XPath extracts from XML payloads.
  • JSON Path extracts from JSON payloads.
  • RegEx extracts from EDI and text formats.
  • Message Context Key extracts from context properties.
  • Formula combines and transforms values; see Formula.
• The extracted values become searchable in Log Views.
• Search Fields and built-in fields, such as the Application interchange id, also drive the Group by feature of Log Views: grouping correlates the events of one business transaction, which is how a BPM ties events from different systems together.
• Add or change a Search Field later and re-index to extract values from Log Events that are already logged.

Step 4: Event Processed

• The status changes from Unprocessed to Processed.
• The Message Type and the Search Field values are indexed.
• The event appears in Log Views with full search, so business users find it by familiar terms such as Order Number or Customer ID.

Example Flow

An XML invoice (blue) gets its Message Type (purple), three XPath expressions extract values (orange), and the values become searchable (green).

Tip

See Message Types for how a Message Type binds a format to its expressions, and Search Fields for the expression plugins.

Repository Auto-Mapping

Log Events can populate the Repository Model automatically: context keys create and bind Integrations, Services, Systems, Transport Contracts, and positions in BPMs while you log, and the Endpoints and Message Types come from the Log Event details. This moves know-how from developers to business and IT operations teams and removes most manual administration.

Important

You must enable the AllowRepositoryAutomapping System Parameter for the Logging Service to honor the Repository Model data in a Log Event.

Use the Repository Binding context key for the structure, BPM Binding to position Services in a BPM, and Context Options for the individual keys.

Reference Pages

The Log API exposes these models; each page below is the single reference for its part.

Next Steps

• JSON Log Event
• Log using REST
• Asynchronous Logging
• Context Options

Related Topics

• Log API
• Message Types
• Search Fields
• Logging Service
• Log Databases
• Log Views
• Log Agents
• Repository Model