Validating messages

The broker provides validation based on the message dictionaries for predefined messages.

Validation, therefore, applies only to messages that you have modeled and defined to the MRM domain. Validation options apply to the body of the message and do not affect message headers.

The broker does not provide any validation for self-defining messages.

Message flows are designed to transform and route messages that conform to certain rules. By default, the MRM parser validates a message, but only to ensure the integrity of the parsing operation. However, you can validate a message more stringently against the message model contained in the message dictionary, by specifying validation options on certain nodes in your message flow.

You can use validation options to validate the following messages:

These validation options can guarantee the validity of data entering and leaving the message flow. The options provide you with some degree of control over the validation performed to:

You can also specify what action to take when a validation fails.

Message validation involves navigating a message tree and checking its validity. It is an extension of tree creation when the message is parsed, and an extension of bit stream creation when the output message is written.

Start of changeValidation options are available on the MQInput, Compute, and Mapping nodes:End of change

MQInput node
The input message is validated when the message is parsed, and the message tree created from the bit stream. You can specify whether the entire message is to be parsed and validated at this time (Timing = Complete), or whether individual fields in the message are parsed and validated only when referenced (Timing = Deferred).

The Airline sample shows how message validation works in the input node.

Compute and Mapping nodes
Messages that are created by the Compute or Mapping node can be validated when the message bit stream is created from the message tree. This means that even though the validation options are specified on the Compute or Mapping node, the message is not validated until it is written to a bit stream by a subsequent output node.

This has the following implications:

  • If a message tree created by a Compute or Mapping node is passed as input to a second Compute or Mapping node, the validation options are lost. Any message trees created by the second node have the validation options specified by the second node, even if the whole message is copied.
  • When the bit stream is written and validation options are applied, the entire message is validated. It is possible that the message tree contains an unresolved type (for example, if a Compute node copied an unresolved type from an input message to an output message without resolving it). If such a type is encountered, a validation error occurs because it is not possible to validate the type. To prevent this, ensure that all unresolved types are resolved before they are copied to output messages.
A limited amount of validation occurs by default, if you leave the validation settings unaltered. At this default level, an exception is thrown if one of the following is true:
  • Min Length or Max Length string limits are broken
  • There is a data mismatch, where, for example, the parser cannot interpret the data provided for the field type specified
  • The order of elements in the output message does not match the order in the logical message tree (TDS fixed length and CWF environments only)

However, you can request more thorough validation of messages. For example, you might want to validate one or more of the following conditions and throw an exception, or log the errors:

For information about how you can control validation by using different properties, see Validation properties.

Related concepts
Message flows

Related tasks
Designing a message flow
Creating a message flow
Defining message flow content

Related reference
Built-in nodes
Validation properties for messages in the MRM domain