Validating messages

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

Before you start:

Read the concept topics about message flows and parsers, especially MRM parser and domain and XML parsers and domains.

Validation applies only to messages that you have modeled and deployed to the broker. Specifically, the message domains that support validation are MRM, XMLNSC, and IDOC.

The broker does not provide any validation for self-defining messages. The MRM and IDOC parsers validate predefined messages against the message dictionary generated from a message set. The XMLNSC domain validates predefined messages directly against XML Schema generated from a message set.

Message flows are designed to transform and route messages that conform to certain rules. By default, parsers perform some validity checking on 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 set by specifying validation options on certain nodes in your message flow.

You can use validation options to validate the following messages:
  • Input messages that are received by an input node
  • Output messages that are created, for example, by a Compute, Mapping, or JavaCompute node
These validation options can ensure the validity of data entering and leaving the message flow. The options provide you with some degree of control over the validation performed to:
  • Maintain a balance between performance requirements and security requirements
  • Validate at different stages of message flow execution; for example, on input of a message, before a message is output, or at any point in between
  • Cope with messages that your message model does not fully describe

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

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

Validation options are available on the following nodes:
Node type Nodes with validation options
Input node MQInput, SCADAInput, HTTPInput, JMSInput, TimeoutNotification, ,
Output node MQOutput, MQReply, SCADAOutput, HTTPReply, JMSOutput, JMSReply, ,
Other nodes Compute, Mapping, JavaCompute, Validate, ResetContentDescriptor, MQGet, HTTPRequest, , , ,

Validation options can also be specified on the ESQL CREATE statement and the ASBITSTREAM function.

To validate input messages that are received on an input node, you can specify validation properties on the input node. The input message is then validated when the message bit stream is parsed to form the message tree.

You can also use the Parse Timing property of the input node to control whether the entire message is parsed and validated at this time, or whether individual fields in the message are parsed and validated only when referenced.

To validate output messages that are created by a transformation node, specify validation properties either on the node itself, or on the output node that sends the message. The validation takes place when the message bit stream is created from the message tree by the output node.

Alternatively, use a Validate node to validate a message tree at a particular place in your message flow, or use the ESQL ASBITSTREAM function in a Compute, Filter, or Database node.

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 statements is true:
  • A data mismatch occurs; for example, the parser cannot interpret the data that is provided for the field type specified.
  • The order of elements in the output message does not match the order of elements in the logical message tree (MRM, CWF and TDS fixed length models only).
Additionally, the MRM parser performs limited remedial action under the following circumstances:
  • Extraneous fields are discarded on output for fixed formats (CWF and TDS fixed length models only).
  • If mandatory content is missing, default values are supplied, if available, on output for fixed formats (CWF and TDS fixed length models only).
  • 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.
However, by using validation options 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:
  • The whole message at the start of the message flow
  • That complex elements have the correct Composition and Content Validation
  • That all data fields contain the correct type of data
  • That data fields conform to the value constraints in the message model
  • That all mandatory fields are present in the message
  • That only the expected fields are present in the message
  • That message elements are in the correct order

The samples in the Samples Gallery illustrate some of these validation options.

When using validation options, it is important to understand the following behavior.
  • The Parse Timing property, which controls whether on demand parsing (sometimes called partial parsing) takes place, has an effect on the timing of the validation of input messages, including message headers.

    For more information about the Parse Timing property, see Parsing on demand.

  • If a message tree is passed to an output node, by default the output node inherits the validation options in force for the message tree. You can override these options by specifying a new set of validation options on the output node.
  • If a message tree is passed as input to a Compute, Mapping, , , or JavaCompute node, any new output message trees that the node creates have the validation options specified by the node itself (even if the whole message is copied). You can override this behavior and specify that the messages that are created by the node inherit the validation options of the input message tree.
  • (MRM domain only) When the bit stream is written, and validation options are applied, the entire message is validated. The message tree might contain 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 error, ensure that all unresolved types are resolved before they are copied to output messages.
  • (MRM domain only) Do not select the Truncate fixed length strings check box because validation is done before truncation, and a fixed length field fails validation if its length exceeds the length that is defined in the message set. For more information about the Truncate fixed length strings property, see Custom Wire Format message set properties and TDS Format message set properties.

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

Related concepts
Parsers
MRM parser and domain
XML parsers and domains
Message modeling
Predefined and self-defining messages
Message flows overview
Related tasks
Designing a message flow
Creating a message flow
Defining message flow content
Related reference
Built-in nodes
Parsing on demand
Validation properties
CREATE statement
ASBITSTREAM function
Notices | Trademarks | Downloads | Library | Support | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Last updated : 2009-01-07 15:19:51

ac00400_