Last updated

Message Types

System Integration Solutions typically communicate by sending messages to each other as part of a conversation. The participants in a conversation agrees 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 is used by Search Fields to extract values for use in search and restrictions in Log Views.

graph LR subgraph "MessageTypes" roMTPurchaseOrder(fal:fa-file Papinet.PurchaseOrder/2.31) roMTOrder(fal:fa-file EDIFACT.ORDRSP.D96A) end subgraph "Search Field Expressions" roSFEOrderIdFromEdifact(fal:fa-flask RegEx with Capturing Groups) roSFEOrderIdFromXML(fal:fa-flask XPath) end subgraph "Search Fields" roSFOrderId(fal:fa-search-plus Order Number) end roMTPurchaseOrder --- roSFEOrderIdFromXML roSFEOrderIdFromXML --- roSFOrderId roMTOrder ---roSFEOrderIdFromEdifact roSFEOrderIdFromEdifact --- roSFOrderId

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

For a message type that specifies XML conforming to a particular schema collection, the message must contain well-formed XML that is valid for one of the schemas in the collection. For a message type that specifies no validation, Nodinite accepts any message content. This includes binary data, XML, or empty messages. Nodinite uses a built-in DEFAULT message type named Unparsed Interchange. If the message type is not specified during the Log operation, the system will use the DEFAULT message type.

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:

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

Origin of Message Types

Messages origin from the process of logging. There are 2 entry paths for messages:

All logged Messages will be processed by the Logging Service. During this processing the Message Type will get known. Messages are not allowed to be logged without a Message Type. The proposed Message Type from the Monitoring Agent Configuration is stored as Original Message Type

Unprocessed Message

Unprocessed

Processed Message

Processed

If the message is XML based the Logging Service will try to extract the real Message Type from the message. The Original Message Type is kept on record level, but Nodinite uses the value set/extracted for the Message Type.

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.

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

reindex
Re-index operation available in the Action Menu

Removal of old messages based on message type

The Logging Service will periodically remove old Events and Messages. The period is user defined per Message Type.

The Default values for a new Message Type is based on a System Parameter from the SystemParameters table in the configuration database:

  • DaysToKeepMessageEventsDefault: The default number of days to keep events. Deleting an event will also delete its data/body message. This value will be assigned to new messagetypes as its default. The Logging Service must be restarted if this value is changed.

  • DaysToKeepMessageDataDefault: The default number of days to keep data in an event. This value will be assigned to new messagetypes as its default. The Logging Service must be restarted if this value is changed.

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.

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 happen 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 (BizTalkMgmgtDB) for additional information in order to resolve the current schema used for the message exchange.

Message Types set on Endpoint

As a last resort, you can always configure the Nodinite Endpoint to always treat content as being a named user defined Message Type

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.

Custom Meta Data

As all entities of the Nodinite Repository Model a System can have any number of Custom Meta Data fields assigned.

Custom Fields

As all entities of the Nodinite Repository Model a System 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

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