Message Types

System integration solutions exchange messages in many formats: XML invoices, JSON orders, EDIFACT despatch advices, flat files. Nodinite names each format as a Message Type, so it knows what kind of data every logged message holds and how to search it.

• ✅ Identify every message format in your integration landscape, from XML and JSON to EDI and flat files
• ✅ Search by business concept, such as Order Number, whatever the format
• ✅ Re-index retroactively when you add a new Search Field
• ✅ See traffic per format with built-in, perpetual statistics
• ✅ Set encoding and retention once per format

Start now: See the Add or manage Message Type user guide.

What is a Message Type?

Participants in an integration agree on the name and content of each message they exchange, usually following a standard such as the UN standard for EDI Despatch Advice. In Nodinite, a Message Type is that agreed name. Message Types are the "which format" of your integration architecture:

• Integrations document "what" (business scenarios like "Order-to-Cash")
• Systems identify "who" (participants like SAP, BizTalk, Dynamics 365)
• Services define "how logically" (the connection, with direction and contracts)
• Message Types specify "which format" (XML invoices, JSON orders)
• Endpoints pinpoint "where physically" (HTTPS URLs, file paths, queue names)

How a Message Type fits in. Purple: the logging side, where a Log Agent or a Log API call sends a Log Event that the Logging Service processes. Orange: the Message Type (which format). Green: the Endpoint (where and how). Together they form a Transport Contract in a Service. Blue: what you configure around them, the Service and the Search Fields whose expressions run only for the Message Types they are assigned to.

A Message Type:

• Has a unique name for one message format, such as an XML schema, a JSON schema, or an EDI standard
• Is the binding point for Search Field Expressions that extract searchable values
• Sets the Character encoding and the Days to keep for its messages
• Can restrict which messages a Log View shows

Every message logged to Nodinite has a Message Type. When the Message Type names an XML schema, the message must be well-formed XML. A Message Type without validation accepts any content: binary data, XML, or even an empty body, such as an API call where only the HTTP headers are logged. An optional description and a link to a web site, such as a wiki page about the format, help end users understand it, and Stylesheets can present its messages in a user-friendly way. Nodinite stores Message Types in the Configuration Database.

Examples of Message Types

• http://SAP.Invoice/1.0 – XML invoice from SAP, named by its namespace
• EDIFACT.DESADVD96A – EDI Despatch Advice following the D96A standard
• Orders/1.0#Order – order schema version 1.0, root element Order
• https://api.company.com/customers/v2#Customer – JSON API customer payload

The Message Types list, filtered on contoso.com: each Message Type with its Days to keep for events, context, and bodies, and the time of its first and last logged event.

How Message Types Fit into the Integration CMDB

Message Types are level 5 in Nodinite's integration CMDB: they identify the format and structure of exchanged data. See The Integration CMDB Hierarchy for the full chain.

Message Types in Transport Contracts: Half of the Log Point

Message Types are half of every Transport Contract in a Service. A Transport Contract defines a log point and needs two pieces:

• Message Type – "Which format?" (XML invoice, JSON order, EDIFACT shipment)
• Endpoint – "Where physically?" (HTTPS URL, file path, queue name)

The Logging Service matches the Message Type and Endpoint of each logged event against the Transport Contracts to find the Service, System, and Integration the message belongs to. One Endpoint can carry several Message Types, such as a shared mailbox receiving both orders and order responses, and one Message Type can travel through several Endpoints. The Services page shows these patterns.

CMDB Capabilities Enabled by Message Types

• ✅ Format Inventory: Catalog every message format in your enterprise, from XML schemas and EDI standards to JSON APIs and flat files
• ✅ Contract Validation: Verify that Services handle the expected Message Types in their Transport Contracts
• ✅ Search Field Binding: Search by business concept (Order Number, Customer ID) across format variations
• ✅ Log Correlation: Match logged events to Integrations, Services, and Systems through the Message Type and Endpoint
• ✅ Living Documentation: Message Types populate themselves from logged events as integrations run

Where Message Types Come From

Message Types originate from logging. A message can't be logged without a Message Type, so the catalog builds itself from what actually runs in production.

• For custom logging through the Log API (custom code, the Log4Net Appender, .NET, Java, and so on), your code sets the Message Type in the Log Event.
• Nodinite Log Agents propose a Message Type from their configuration.

The proposed value is stored as the Original Message Type. When the Logging Service processes the message, it determines the final Message Type, creating it if it doesn't exist yet. Until then the message is unprocessed; after processing, including any pending re-indexing, it is processed.

Unprocessed Message

The Message Type block of a Log Event that was not resolved: both the Message Type and the Original Message Type read Unparsed Interchange.

Processed Message

After processing, the block shows the resolved Message Type as a badge, SupplyChain.Schemas/1.0#Orders, with the Original Message Type (Serialized Interchange) and the Encoding below it.

When the content is JSON, XML, or EDIFACT, the Logging Service extracts the Message Type from the payload. The Original Message Type stays on the record, but Nodinite uses the extracted value as the Message Type, which enables precise Search Fields.

Note

You can override this logic by providing your own Message Type as a Context Option.

XML

For XML messages, Nodinite combines the target namespace and the root node, for example Orders/1.0#Order.

EDIFACT

For EDIFACT messages, Nodinite builds the Message Type from the UNH (message header) segment, using the pattern in the EDIMessageTypeParseString System Parameter. The default pattern produces names such as ORDERS.D96AUN.

JSON

For JSON messages with the schema property set, Nodinite sets the Message Type accordingly. Read more about JSON schema in 'Defining JSON Messages with JSON Schema'.

Microsoft BizTalk Server

The Logging Service has special support for Microsoft BizTalk Server. When a BizTalk pipeline uses a defined schema, the Message Type is well known. Passthru pipeline components, however, log messages as either Unparsed Interchange or Serialized Interchange, depending on direction, and Nodinite resolves the real type for you.

XML Content

If the content is XML and UTF-8 encoded (the BizTalk Server default), Nodinite resolves the Message Type the same way BizTalk does, by combining the target namespace and the root node name:

urn:oasis:names:draft:ubl:schema:xsd:DespatchAdvice-2#DespatchAdvice

Non-XML Content

For flat file and EDI messages, the Logging Service queries the BizTalk Server Configuration database (BizTalkMgmtDB) to resolve the schema used for the message exchange.

Tip

For BizTalk Server, the Message Type is known to Nodinite even when Passthru pipeline components are used.

Message Types Set on the Endpoint

When the Message Type would still be Unparsed Interchange or Serialized Interchange, set a pre-defined default Message Type on the BizTalk send port's Endpoint. Add or manage Endpoint describes the setting on the Advanced tab.

Important

Avoid the built-in Unparsed Interchange and Serialized Interchange types. Always set a default Message Type on the Endpoint for these message exchanges.

Automated Deployments

Manage Nodinite Message Types as part of your DevOps routine.

You can create and update Message Types from Azure DevOps and other pipelines through the Nodinite Web API.

Message Types in Daily Operations

Message Types are more than documentation. Nodinite uses them throughout its operational features.

In Search: Search Fields

Message Types decide which Search Field Expressions process which messages. One business concept, such as Order Number, gets one expression per format:

Format-independent search: a business user searches for "Order Number = 12345" without knowing whether the order came as Papinet XML or EDIFACT. Nodinite applies the expression assigned to each message's Message Type.

• One Search Field, many formats – "Customer ID" can have an XPath expression for urn:schemas:orders:Order#Order (XML), a RegEx expression for EDIFACT.ORDERS.D96A (EDI), and a JSON Path expression for https://api.company.com/orders/v1#Order (JSON)
• Efficient processing – only the expressions assigned to a message's Message Type run; a Global expression runs for every message, so target specific Message Types where you can
• Easy maintenance – change the extraction for one format without touching the others

Choose the Search Field Expression plugin that matches the format:

Add or manage Search Field holds the configuration details and best practices for assigning expressions to Message Types.

Re-Indexing by Message Type

When you add or change a Search Field, Nodinite can re-index messages that are already logged and extract the new values retroactively, per Message Type. Weeks after go-live, a new "Purchase Order Number" Search Field can still find every historical order: you choose the Message Types to re-index, and only their messages and their assigned expressions are processed again. Few other products can extract business data from messages they have already logged.

Re-indexing is chosen per Message Type, so you re-process only the formats that changed.

Re-indexing is for Administrators only, on live Message Types: the row Reindex, Reindex Message Type on the edit page, and Reindex under With Selected. How to start a re-index is on Manage Message Types, and Add or manage Search Field explains how a re-index runs and how to plan a large one.

In Log Views

Log Views can be restricted to selected Message Types, so each team sees only the formats it owns, and users can filter Log Events by Message Type.

Character Encoding

Every Message Type has a Character encoding that tells Nodinite how to turn the stored bytes of its messages into text. ^{New 7.11} The default is UTF-8 (without BOM); change it when a format always arrives in another encoding, such as Windows-1252, EBCDIC (IBM037), or Base64 text. The Logging Service uses it to process and re-index messages, and the Web Client uses it for the message body view, Stylesheets, and the Search Field Wizard. The Message Type is the lowest of four priorities: an Endpoint override, an encoding in the XML declaration of the body, and a context property on a single Log Event all win over it. Character Encoding explains the order, and Add or manage Message Type shows where to set it.

Retention (Days to Keep)

Each Message Type decides how long Nodinite keeps the Log Events, their context, and their message bodies. The Logging Service periodically removes processed data that is older than the Days to keep, so you can keep high-volume or sensitive formats briefly and audit-relevant formats for years. New Message Types get their defaults from System Parameters. On the edit page they are on the Retention tab, whose title shows the three values for events, context, and bodies, next to General and Statistics. Add or manage Message Type describes the settings.

In the Integration Landscape

Clicking a Service in the Integration Landscape reveals its Transport Contracts, including the Message Types that flow through it.

Statistics

Nodinite keeps perpetual traffic statistics for every Message Type. They are collected automatically as messages are logged, with no setup, and answer the question "where does this format travel, and how much of it?"

The Statistics tab of the O2C.Forwarding/1.0 Message Type: a chart of the number of events per Endpoint over time, and a table with each Endpoint's URI, Endpoint Type, Log Agent, first and last event, and total number of events.

What the Statistics Show

• Endpoints carrying the format – every Endpoint the Message Type was logged on, with its URI, Endpoint Type, and Log Agent, including deleted Endpoints when you choose to
• Number of events per Endpoint over time – a chart for the date range you pick, which you can filter by Direction
• First and last event – when the format was first and most recently seen on each Endpoint

Why They Matter

• ✅ Where does this format come from? See every system, agent, and channel that sends or receives it
• ✅ Migration tracking: Watch traffic move from an old Endpoint to a new one, and confirm when the old one is quiet
• ✅ Version retirement: See whether anyone still sends an old schema version before you retire it
• ✅ Re-index and retention planning: Know the volume behind a Message Type before you re-index it or change its Days to keep
• ✅ Compliance Reporting: Show auditors real traffic volumes per format

For the other direction, which formats travel through a given Endpoint, see the Endpoint statistics. Add or manage Message Type shows where to open the Statistics tab.

Who Uses Message Types?

What Every Message Type Carries

^{New 7.12} A Message Type shares one set of features with the other Repository entities: Integrations, Systems, Services, Contracts, Endpoints, and Domains.

With Selected also offers Edit Retention and Reindex for the selected Message Types. Step by step: Manage Message Types.

Custom Metadata

As with all entities in the Nodinite Repository Model, a Message Type can have any number of Custom Metadata fields, such as format owner or standard version.

Custom Fields

A Message Type can also have any number of Custom Fields assigned.

Next Steps

• Add or manage Message Type – set encoding, retention, and documentation
• Message Types Overview – find and view Message Types
• Manage Message Types – add, delete, restore, export, and re-index Message Types
• Add or manage Search Field – assign Search Field Expressions to your Message Types
• Add or manage Service – use Message Types in Transport Contracts

Related Topics

Repository Model – the complete integration CMDB
Integrations – business scenarios exchanging Message Types
Systems – participants sending and receiving messages
Services – group Message Types in Transport Contracts
Endpoints – the other half of every Transport Contract
Search Fields – business-concept fields enabled by Message Types
Search Field Expressions – format-specific extraction bound to Message Types
EDIMessageTypeParseString – the pattern for EDIFACT Message Type names
Logging Service – processes messages and determines Message Types
Log API – log messages with your own Message Types
Log Views – filter and restrict Log Events by Message Type
Stylesheets – present messages in a user-friendly format
Character Encoding – how message bodies are decoded
Integration Landscape – see the Services that carry Message Types
Web API – automate Message Type management through DevOps