Validation properties for messages in the MRM domain

You can control validation by setting properties presented by the Validation tab and General Message Options tab on the following nodes:

Node type Nodes with validation options
Input node MQInput, SCADAInput, HTTPInput, JMSInput, TimeoutNotification
Output node MQOutput, MQReply, SCADAOutput, HTTPReply, JMSOutput
Other nodes Compute, Mapping, JavaCompute, Validate, ResetContentDescriptor, MQGet, HTTPRequest,

For an overview of message validation in the broker please refer to Validating messages.

The following validation properties can be set:
Tab Properties that affect validation
Validate Validate, Failure Action, Include All Value Constraints, Fix
General Message Options Parse Timing

Validation tab properties

Validate

Sets whether validation is required. All nodes provide the following options:

None
The default value. No validation is performed
Content
Indicates that you want to perform content checks, such as Content validation and Composition
Content and Value
Indicates that you want to perform content checks, auch as Content validation and Composition, and value checks, such as whether the value conforms to data type, length, range, and enumeration.

Some nodes also provide the following option:

Inherit
Instructs the node to use all the validation options provided with the input message tree in preference to any supplied on the node. Inherit will therefore resolve to one of None, Content, or Content and Value. If Inherit is selected, the other validation properties on the tab are greyed out.

Failure Action

The action that you want to be taken when a validation failure occurs. You can set it to the following values:

Exception
The default value. An exception is thrown on the first validation failure encountered. The resulting exception list is shown below. The failure is also logged in the user trace if you have asked for user tracing of the message flow, and validation stops. Use this setting if you want processing of the message to halt as soon as a failure is encountered.

Exception list when failure action set to Exception

Exception List
Throws an exception if validation failures are encountered, but only when the current parsing or writing operation has completed. The resulting exception list is shown below. Each failure is also logged in the user trace if you have asked for user tracing of the message flow, and validation stops. Use this setting if you want processing of the message to halt if a validation failure occurs, but you want to see the full list of failures encountered. Note that this property is affected by the Parse Timing property; when partial parsing is selected the current parsing operation will only parse a portion of an input message, so only the validation failures in that portion of the message will be reported.

Exception list when failure action set to Exception List

User Trace
Logs all validation failures to the user trace, even if you have not asked for user tracing of the message flow. Use this setting if you want processing of the message to continue regardless of validation failures.
Local Error Log
Logs all validation failures to the error log (for example, the Event Log on Windows). Use this setting if you want processing of the message to continue regardless of validation failures.

Include All Value Constraints

The check box is selected. You cannot change this option.

Include All Value Constraints specifies which basic value constraint checks are to be performed on the values of fields in the message when Validate resolves to Content And Value. The checks performed are:

  • Min Length
  • Max Length
  • Fraction Digits
  • Total Digits
  • Min Inclusive
  • Max Inclusive
  • Min Exclusive (where supported)
  • Max Exclusive (where supported)
  • Enumeration
  • Pattern

For more details on value constraints, see Simple type logical value constraints.

Fix

The default value is none. You cannot change it.

None specifies that no extra remedial action is to be taken when Validate resolves to Content or Content And Value and validation failures occur, The remedial action taken depends on the setting of Failure Action.

If Failure Action is set to User Trace or Local Error Log, the remedial action is limited to the default remedial action that takes place when no validation is being performed, as described in Validating messages:

  1. Extraneous fields are discarded on output for fixed formats (CWF and TDS fixed length models only)
  2. If mandatory content is missing, defaults are supplied, if available, on output for fixed formats (CWF and TDS fixed length models only)
  3. If an element's data type in the tree does not match that specified in the dictionary the data type is converted on output to match the dictionary definition if possible, for all formats.

If Failure Action is set to Exception or Exception List, the remedial action is limited to the third item in the above list, and an exception is thrown for the first two items.

Parse Timing
The Parse Timing property is only available on the following nodes:
Node type Nodes containing Parse Timing property options
Input nodes MQInput, MQGet, SCADAInput, HTTPInput, HTTPRequest, Real-timeInput, JMSInput, Compute JavaCompute, Mapping, ResetContentDescriptor, TimeoutNotification
Other nodes ResetContentDescriptor

The Parse Timing property determines whether on demand parsing is to be used when parsing a message. It also gives you control over the timing of MRM input message validation:

  • If you select a Parse Timing value of On Demand, validation of a field in the message is delayed until it is parsed by partial parsing.
  • If you select a Parse Timing value of Immediate, partial parsing is overridden, and everything in the message is parsed and validated except those complex types with a Composition of Choice or Message that can not be resolved at the time
  • If you select a Parse Timing value of Complete, partial parsing is overridden, and everything is parsed and validated. Complex types with a Composition of Choice or Message that can not be resolved at the time cause a validation failure.

If you switch on MRM message validation, and you select On Demand or Immediate for Parse Timing, validation errors might not be detected until later in the processing of a message by a message flow, or might never be detected if a portion of the message is never parsed. To make sure that all fields in a message are validated, either select Complete, or select Immediate and make sure that you resolve all unresolved types with a Composition of Choice or Message at the start of your message flow.

The Parse Timing property has no effect on the validation of output messages.

Related concepts
Message flows overview
Related reference
Built-in nodes