IBM Integration Bus, Version 9.0.0.8 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

Validating messages

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

Before you start:

Read the concept topics about message flows and parsers, especially DFDL parser and domain and XMLNSC parser.

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

The broker does not provide any validation for self-defining messages. The DFDL, XMLNSC, and SOAP domains validate predefined messages directly against message model schema files. The MRM and IDOC parsers validate predefined messages against the message dictionary 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 completion; for example, on input of a message, before a message is propagated, 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 validity of the tree. 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	FileInput, FTEInput, HTTPInput, JMSInput, MQInput, .NETInput, SCAInput, SOAPInput,TCPIPClientInput, TCPIPClientReceive, TCPIPServerInput, TCPIPServerReceiveTimeoutNotification
Output node	EmailOutput, FileOutput, FTEOutput, HTTPReply, JMSOutput, JMSReply, MQOutput, MQReply, SCAReply, SOAPReply, TCPIPClientOutput, TCPIPServerOutput
Other nodes	Compute, CICSRequest, DatabaseRetrieve, HTTPRequest, FileRead, JavaCompute, Mapping, MQGet, PHPCompute, ResetContentDescriptor, SCAAsyncResponse, SCARequest, SOAPRequest, SOAPAsyncResponse, Validate, XSLTransform

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 (DFDL, MRM CWF, and MRM TDS fixed-length models only).

Additionally, the DFDL parser performs limited remedial action under the following circumstances:

If mandatory content is missing, default values are supplied, if available in the schema, on output.
If the data type of an element in the tree is CHARACTER and does not match that specified in the schema, the data type is converted on output to match the schema, if possible.

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 the data type of an element 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 illustrate some of these validation options.

You can view information about samples only when you use the product documentation that is integrated with the IBM® Integration Toolkit or the online product documentation. You can run samples only when you use the product documentation that is integrated with the IBM Integration Toolkit.

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, affects 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, XSLTransform, DatabaseRetrieve, 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.
(DFDL and MRM domains 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 Message Sets: Custom Wire Format message set properties and Message Sets: TDS Format message set properties.

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

ac00400_.htm |

Last updated Friday, 21 July 2017