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.
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.
Messages can be displayed for end users in a user friendly format by the use of Stylesheets.
Messages origin from the process of logging. There are 2 entry paths for messages:
- BizTalk logging, governed by the Logging Service.
- Log API (Custom, Log4Net Appender, iCore, .NET, Java, ...)
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
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.
Note: Adding Search Fields and Search Field Expressions on MessageTypes increases workload. Make sure to configure and use this powerful feature wisely
Re-index operation available in the Action Menu
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.
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.
Using any of the Passthru pipeline components results in logged messages being either Unparsed Interchange or Serialized Interchange depending on direction.
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
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.
As a last resort, you can always configure the Nodinite Endpoint to always treat content as being a named user defined Message Type