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.

V5 info

Validate
Whether validation is required. Set it to None (the default) or Content And Value.

Content And Value indicates that you want to perform content checks (such as Content Validation and Composition) and value checks (such as value data type, null permitted, length, range, enumeration).

Failure Action
The action that you want to be taken when a validation failure occurs. You can set Exception (the default), User Trace, or Local Error Log.

Exception throws an exception on the first validation failure. The failure is logged in the user trace if you have asked for user tracing of the message flow, and validation stops. This default setting is most useful after you have completed debugging your message flow and application.

User Trace writes all validation failures to the user trace, even if you have not asked for user tracing of the message flow.

Local Error Log writes all validation failures to the error log (for example, the Event Log on Windows).

In both the User Trace and Local Error Log cases, validation continues. These settings are useful when you first set the Validate property to Content And Value, so that you see all validation failures, not just the first.

Timing
When to have input message fields validated. You can set Deferred (the default), Immediate, or Complete.

Immediate validates the entire message, although any unresolved subsets resulting from the use of Composition Choice or Message are not validated until they are resolved.

Complete validates the entire message.

Deferred validates each field when it is parsed. Partial parsing might cause this to be late in the message flow, or never.

The MRM parser uses partial parsing, which means that an input message is not completely parsed at the start of a message flow. When fields in the message are referenced, as much of the message is parsed as is necessary to completely resolve the reference. The Timing property gives you control over how message validation interacts with partial parsing:
  • If you select a Timing value of Complete or Immediate, partial parsing is overridden, and as much of the message as possible is parsed immediately. For Complete, this is the whole message; for Immediate, everything is parsed except those complex types with a Composition of Choice or Message (because they can be parsed only when the content has been resolved by the user in ESQL).
  • If you select a Timing value of Deferred, validation of a field in the message is delayed until it is parsed by partial parsing.
If you select Deferred or Immediate, 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 at the start of your message flow.

The Timing property is available only on the MQInput node.

Include All Value Constraints
The check box is selected; you cannot change it.

Include All Value Constraints specifies these value constraint checks:

  • Min Length
  • Max Length
  • Null Permitted
  • Date Template
  • Scale
  • Min Inclusive
  • Max Inclusive
  • Enumeration
  • Pattern

See Simple type logical value constraints for a description of these value constraints.

Fix
The default value is None; you cannot change it.
None specifies that only limited remedial action is to be taken when Validation is set to Content And Value, validation failures occur, and Failure Action is not set to Exception:
  • Extraneous fields are discarded for fixed formats in the MRM domain (CWF and TDS non-tagged).
  • If mandatory content is missing, defaults are supplied (if available) on both parsing and writing for fixed formats (TDS non-tagged).
  • If an element's data type in the tree does not match that specified in the dictionary, the data type is converted to match the dictionary definition if possible. This happens when the MRM parser writes the bit stream at the output of the message flow (all formats).
If Failure Action is set to Exception, no remedial action is taken, and an exception is thrown at the first validation failure.
Related concepts
Message flows overview
Related reference
Built-in nodes