Message Types

Message Types are the foundation of Nodinite's powerful search and filtering capabilities. They identify what kind of data each message contains—enabling format-specific extraction, precise correlation, and business-friendly search across all your integrations.

What Message Types enable:

• Identify every message format in your integration landscape (XML, JSON, EDI, flat files, custom)
• Bind Search Field Expressions to specific formats for efficient, accurate value extraction
• Correlate transactions across different systems and message formats
• Enforce Log View restrictions to show only relevant messages to each team
• Automate management through DevOps pipelines with the Web API
• Re-index retroactively by Message Type when adding new Search Fields

What is a Message Type?

System integration solutions communicate by exchanging messages as part of business conversations. Participants agree on the name and content for each message type, usually following a business standard such as the UN standard for EDI Despatch Advice.

A Message Type object:

• Defines a unique name for a specific message format
• Specifies the type of data the message contains (XML schema, JSON schema, EDI standard, etc.)
• Acts as the binding point for Search Field expressions that extract searchable values
• Determines which messages appear in Log Views with Message Type restrictions

Nodinite stores Message Types in the configuration database and uses them throughout the platform.

Example Message Type names:

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

How Message Types Enable Cross-Format Search

The power of Message Types comes from their role as the binding layer between message formats and Search Field extraction:

This architecture enables format-independent search: Business users search for "Order Number = 12345" without knowing or caring whether it came from XML (Papinet) or EDI (EDIFACT). Nodinite automatically applies the correct extraction logic based on the Message Type.

Key benefits of this binding:

• One Search Field, multiple formats – "Order Number" works across XML, EDI, JSON, and custom formats
• Efficient processing – Only expressions assigned to the message's type are evaluated
• Intelligent correlation – Track orders across different systems using different formats over time
• Easy maintenance – Change extraction logic for one format without affecting others

How Message Types Fit into the Integration CMDB

Message Types occupy a critical layer in Nodinite's integration CMDB—they identify the format and structure of exchanged data:

CMDB Hierarchy:

1. Integrations (Business Scenario) - "Order-to-Cash integration"
2. Systems (Participants) - "SAP sends to BizTalk which sends to Dynamics 365"
3. Services (Connection Points) - Services define how Systems connect with direction and contracts
4. Transport Contracts (Log Points) - Combination of Message Types + Endpoints
5. Message Types (Formats) - Identify message structure and enable Search Field extraction
6. Endpoints (Physical Channels) - Specify transport locations

Message Types enable the CMDB to bridge technical implementation and business meaning:

✅ Format Inventory: Catalog all message formats across your enterprise (XML schemas, EDI standards, JSON APIs, flat files)
✅ Contract Validation: Verify Services handle expected Message Types in their Transport Contracts
✅ Search Field Binding: Enable business-concept search (Order Number, Customer ID) across format variations
✅ Log Correlation: Match logged events to Integrations, Services, and Systems via Message Type + Endpoint combinations
✅ Living Documentation: Message Types auto-populate from logged events as integrations run

This format-aware CMDB ensures you can search, filter, and correlate messages by business concepts—not just technical XML tags or EDI segments.

• All logged messages within Nodinite must have a well-known Message Type.
• For a message type that specifies XML conforming to a particular schema collection, the message must contain valid, well-formed XML.
• For a message type that specifies no validation or schema, Nodinite accepts any message content—including binary data, XML, or even empty messages (such as API calls where only HTTP headers are logged).

A Message Type is a member of a Service in the Repository Model and represents the type of message for a logged event. Examples include:

• http://SAP.Invoice/1.0
• EDIFACT.DESADVD96A
• Orders/1.0#Order

Messages can be displayed for end-users in a user-friendly format using Stylesheets.

Origin of Message Types

Message Types originate from the process of logging. Messages cannot be logged without a Message Type. The proposed Message Type from the Logging Agent Configuration is retained and stored as the Original Message Type.

• For custom logging, the Message Type is defined by your custom code.
  • Log API (Custom, Log4Net Appender, iCore, .NET, Java, ...)
• All logged messages are processed by the Logging Service. During processing, the Message Type is determined, one way or another.

When a message is logged to Nodinite, it is unprocessed. Once the Logging Service has handled unprocessed messages and those pending re-indexing, the message becomes processed.

Automated Deployments

Manage Nodinite Message Types as part of your DevOps routine.

As part of your Azure DevOps routine, you can programmatically create or manage Message Types by invoking the Nodinite Web API.

Microsoft BizTalk Server

The Logging Service provides special support for Microsoft BizTalk Server. When BizTalk solutions use pipeline components with a defined schema, the Message Type is well-known. For Passthru pipeline components, the message type is unknown and must be handled. Nodinite offers several options.

• For Nodinite Logging Agents, the Message Type is created using our logic.
  • BizTalk logging is governed by the Logging Service.

  Important

  Avoid the built-in Unparsed Interchange and Serialized Interchange. Always set a default message type in the Advanced tab of the Endpoint for the message exchange.

Passthru

Using any of the Passthru pipeline components results in logged messages being either Unparsed Interchange or Serialized Interchange, depending on direction.

XML Content

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

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

Non-XML Content

For flat file and EDI-based messaging, the Logging Service queries the BizTalk Server Configuration database (BizTalkMgmtDB) for additional information to resolve the current schema used for the message exchange.

Tip

For BizTalk Server, even if Passthru pipeline components are used, the message type will still be known to Nodinite.

Message Types Set on Endpoint

For BizTalk Server, when the message type is either "Unparsed Interchange" or "Serialized Interchange", you can configure the Nodinite Endpoint to set a superseding pre-defined Message Type.

Unprocessed Message

Processed Message

If the message is JSON, XML, or EDIFACT based, the Logging Service extracts the Message Type from the message payload. The Original Message Type is kept at the record level, but Nodinite uses the extracted value as the Message Type. This enables advanced Search Fields.

Note

You can override the logic by providing your own defined message type as a Context Option.

XML

For XML messages, Nodinite extracts the Message Type from the Target Namespace combined with the root node, for example (Orders/1.0#Order).

EDIFACT

For EDIFACT messages, Nodinite sets the Message Type using the value from the UNA field.

JSON

For JSON messages with the schema property set, Nodinite sets the Message Type accordingly.

Read more about JSON schema in the following user guide: 'Defining JSON Messages with JSON Schema'

Search Fields and Message Types: The Binding That Powers Search

Message Types are the foundation for Search Field extraction—they determine which expressions process which messages. This binding enables precise, efficient data extraction across your entire integration landscape.

How the Binding Works

When you configure a Search Field Expression, you assign it to specific Message Types:

1. Targeted Extraction: Each expression can target one or more Message Types
2. Format-Specific Logic: Use XPath for XML Message Types, RegEx for EDI, JSON Path for JSON
3. Global vs. Specific: Mark expressions as "Global" (all types) or assign to specific types
4. Processing Efficiency: Only expressions matching the message's type are evaluated

Example: A "Customer ID" Search Field might have:

• An XPath expression assigned to urn:schemas:orders:Order#Order (XML)
• A RegEx expression assigned to EDIFACT.ORDERS.D96A (EDI)
• A JSON Path expression assigned to https://api.company.com/orders/v1#Order (JSON)

All three extract the same business concept (Customer ID), but use different techniques for different message formats.

Expression Types by Message Format

Choose the right Search Field Expression plugin for your Message Type's format:

XML Message Types:

• XPath – Standard XPath extraction from XML content
• XPath with RegEx – Combine XPath navigation with pattern matching
• XPath on Message Context – Extract from message metadata
• XPath on Wrapped XPath – Multi-level extraction for nested structures

JSON Message Types:

• JSON Path – JSONPath extraction from JSON content

EDI/Flat File Message Types:

• RegEx – Pattern matching for structured text
• RegEx with capturing groups – Extract multiple values simultaneously
• Flat File CSV – Column-based extraction from CSV files
• Flat File Fixed Width – Position-based extraction from fixed-width files

Any Message Type:

• Message Context Key – Direct access to message properties
• Formula – Transform and combine values with 31 built-in functions

All formats:

• RegEx variants work on any text-based content (XML, EDI, JSON, CSV, custom formats)

Re-Indexing by Message Type: A Unique Competitive Advantage

When you add or modify Search Field Expressions, you can re-index historical messages to apply the changes retroactively. This capability is truly unique to Nodinite—competing products typically cannot retroactively extract business data from already-logged messages.

Why retroactive re-indexing matters:

Imagine discovering after weeks of production logging that you need to search by "Purchase Order Number"—a field you didn't initially extract. With Nodinite:

1. Add a new Search Field "Purchase Order Number"
2. Create Search Field Expressions bound to relevant Message Types (XML XPath, EDI RegEx, JSON Path)
3. Select those Message Types for re-indexing
4. Nodinite retroactively processes historical messages, extracting Purchase Order Numbers
5. Historical data becomes searchable—no messages are lost, no manual data entry required

Without this capability, you'd have only two options: manually parse log files (impossible at scale) or accept that historical data is unsearchable (business impact).

Re-index selected Message Types to apply Search Field changes retroactively—a capability no competing product offers.

Re-indexing is Message Type-specific:

• Select which Message Types to re-process (not all-or-nothing)
• Only messages of selected types are affected (efficient targeting)
• Only expressions assigned to those types are re-evaluated (performance optimization)
• Existing Search Field values are updated with newly extracted data (no duplicates)

This Message Type-scoped re-indexing ensures you can apply changes surgically—re-process only the formats that changed, not your entire message history.

Performance Tip: Be selective with re-indexing. Processing millions of messages takes time. Re-index only the Message Types that need it. Schedule re-indexing during off-peak hours if processing large volumes.

Performance Considerations

The Message Type ↔ Search Field Expression binding directly impacts system performance:

Best Practices:

• Be specific: Assign expressions to specific Message Types rather than marking all as "Global"
• Avoid over-extraction: Only create Search Fields for values you'll actually search
• Test before deploying: Use the Test Expression feature to validate before enabling
• Monitor processing: Track Logging Service performance after adding new expressions
• Batch configuration: Add multiple Search Fields, then re-index once

Why it matters:

• Each expression adds processing time per message
• Global expressions process every message regardless of type
• Poorly written RegEx expressions can be computationally expensive
• Re-indexing large Message Types with many expressions can take hours

Important

Configure Search Field Expressions wisely—the Message Type binding ensures efficient extraction, but only if you target the right types with appropriate expressions.

Removal of Old Messages Based on Message Type (Days to Keep)

This topic is detailed in the Add or manage Message Type user guide.

Custom Metadata

As with all entities in the Nodinite Repository Model, a Message Type can have any number of Custom Metadata fields assigned, supporting flexible documentation and governance.

Custom Fields

Similarly, a Message Type can have any number of Custom Fields assigned, enabling tailored information management for your integration landscape.

Next Steps

Configure your Message Types:

1. Repository Overview – View and manage all Message Types in your system
2. Add or manage Message Types – Create or update Message Type definitions
3. Add or manage Search Field – Bind Search Field Expressions to your Message Types
4. Search Field Expressions – Explore all 12 expression plugins for data extraction
5. Add or manage Service – Organize Message Types within Services

Understanding the Concepts

What is a Search Field? – Learn how Search Fields enable business-friendly search
Search Field Expressions Overview – Understand expression plugins and when to use each
Repository Model – See how Message Types fit into the overall model

Related Topics

Understanding Repository Model Entities

Repository Model – Complete integration CMDB overview
Integrations – Business scenarios exchanging Message Types
Systems – Participants sending/receiving messages
Services – Group related Message Types in Transport Contracts
Endpoints – Combine with Message Types to form Transport Contracts (log points)

Search and Extraction

Search Fields – Business-concept fields enabled by Message Types
Search Field Expressions – Format-specific extraction logic bound to Message Types

Operational Features

Logging Service – The engine that processes messages and determines Message Types
Log API – Log messages programmatically with custom Message Types
Log Views – Filter and display messages by Message Type
Stylesheets – Format message display based on Message Type
Integration Landscape – Visualize which Message Types flow through Services
Web API – Automate Message Type management through DevOps