Validation properties

You can control validation by setting properties on the Validate and Parser Options tabs for the nodes that are listed in the following table.

Validation options are available on the following nodes:

Node type	Nodes with validation options
Input node	FileInput, FTEInput, HTTPInput, JMSInput, KafkaConsumer, MQInput, MQTTSubscribe, .NETInput, SCAInput, SOAPInput,TCPIPClientInput, TCPIPClientReceive, TCPIPServerInput, TCPIPServerReceiveTimeoutNotification
Output node	EmailOutput, FileOutput, FTEOutput, HTTPReply, JMSOutput, JMSReply, KafkaProducer, MQOutput, MQReply, MQTTPublish, SCAReply, SOAPReply, TCPIPClientOutput, TCPIPServerOutput
Other nodes	Compute, CICSRequest, DatabaseRetrieve, HTTPRequest, FileRead, JavaCompute, Mapping, MQGet, ResetContentDescriptor, SCAAsyncResponse, SCARequest, SOAPRequest, SOAPAsyncResponse, Validate, XSLTransform

For an overview of message validation in the integration node, refer to Validating messages.

You can set the properties that are shown in the following table.

Tab	Properties that affect validation
Validation	Validate, Failure Action
Parser 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, such as Content validation and Composition, and value checks, such as whether the value conforms to data type, length, range, and enumeration.

Note: Even if Content is selected, the SOAP, DFDL, and XMLNSC domains always perform Content and Value validation.

Some nodes also provide the following option:

Inherit: Instructs the node to use all the validation options that are provided with the input message tree in preference to any supplied on the node. Inherit therefore resolves to None, Content, or Content And Value. If Inherit is selected, the other validation properties on the tab are not available.

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.

MRM and IDOC Exception list when failure action set to Exception

XMLNSC and SOAP 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. This property is affected by the Parse Timing property; when partial parsing is selected the current parsing operation parses only a portion of an input message, so only the validation failures in that portion of the message are reported.

MRM and IDOC Exception list when failure action set to Exception List

XMLNSC and SOAP 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 where it is possible to do so.

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 where it is possible to do so.

Parser Options tab properties

Parse Timing

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 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 on-demand parsing.
If you select a Parse Timing value of Immediate, on-demand parsing is overridden, and everything in the message is parsed and validated except, if the message domain is MRM, those complex types with a Composition of Choice or Message that cannot be resolved at the time
If you select a Parse Timing value of Complete, on-demand parsing is overridden, and everything is parsed and validated. If the message domain is MRM, complex types with a Composition of Choice or Message that cannot be resolved at the time cause a validation failure.

If you enable 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, if the message domain is MRM, 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 does not affect the validation of output messages.