Message Types

System Integration Solutions typically communicate by sending messages to each other as part of a conversation. The participants in a conversation agree on the name and content for each type of message usually following some business-standard, for example, the UN standard for EDI Despatch Advice.

A Message Type object defines a unique name for a message type and defines the type of data that the message contains. Message types are persisted in the configuration database and are used by Search Fields to extract values for use in search and restrictions in Log Views.

Nodinite can correlate transactions like order/order response in different formats even transmitted on many various integration brokers spanning long time intervals.

• 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 and/or schema, Nodinite accepts any message content. This includes binary data, XML, or even empty messages (for example an API call where you only want to log the HTTP headers).

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

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

Messages can be displayed for end-users in a user-friendly format by the use of Stylesheets.

Origin of Message Types

Message Types origin from the process of logging. Messages are not allowed to 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 the custom code.
  • Log API (Custom, Log4Net Appender, iCore, .NET, Java, ...)

All logged Messages will be processed by the Logging Service. During processing, the Message Type will get known, one way or the other.

When a message is logged to Nodinite, it is unprocessed. Once the Logging Service has managed to deal with unprocessed and messages pending a re-index operation; The message becomes processed.

Automated deployments

Manage Nodinite Message Types as part of your DevOps routine

As part of your Azure Devop routine; It is possible to programmatically create/manage Message Types by invoking the Nodinite Web API.

Microsoft BizTalk Server

The Logging Service has special support for Microsoft BizTalk Server. When solutions within BizTalk Server uses pipeline components with a defined schema the Message Type is well-known. For Passthru pipeline components the message type is unknown and needs to be dealt with. Nodinite provides many options.

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

  Important

  Avoid the built-in Unparsed Interchange and Serialized Interchange(!). Make sure to 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 happens to be UTF-8 encoded (default for BizTalk Server) and the content is XML then Nodinite will resolve the Message Type in the same way as BizTalk does. This is the composition of the target namespace and the name of the root node, 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 will query the BizTalk Server Configuration database (BizTalkMgmtDB) for additional information to resolve the current schema used for the message exchange.

Tip

In conclusion; For BizTalk Server, this means that even if Passthru pipeline components are being used, the message type will still be known for 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 to be used within Nodinite from the message payload. The Original Message Type is kept on record level, but Nodinite uses the value set/extracted as the Message Type. This facilitates the use of Search Fields.

Note

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

XML

For XML mesages, Nodinite extracts the Message Type from the value for Target Namespace with the combination of 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 here

Search Fields

Values for Search Fields will be extracted during the processing of messages. You can reprocess/re-index messages based on the Message Type if you add or change the configuration for a Search Fields.

Re-index operation available in the Action menu.

Note

Adding Search Fields and Search Field Expressions on MessageTypes increases workload. Make sure to configure and use this powerful feature wisely

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

All entities of the Nodinite Repository Model, a Message Type can have any number of Custom Metadata fields assigned.

Custom Fields

All entities of the Nodinite Repository Model, a Message Type can have any number of Custom Fields assigned.

Next Step

Add or manage Message Types
Add or manage Search Field
Add or manage Service
Message Type Overview

Related

Repository Model
Services
Logging Service
Log API
Search Fields
Log Views
Stylesheets