BizTalk Schema validation – Default and Deep Validation

One of the most common misconceptions for new BizTalk developers is assuming that if a message passes through a pipeline, it must be valid according to the schema. In reality, BizTalk uses a “lazy” approach to validation by default to keep performance high.

To build robust systems, you must understand the two levels of validation available.

Level 1: Default Validation (The XML Disassembler)

When you use a standard XML Receive pipeline, the XML Disassembler is responsible for identifying the message.

• What it does: It checks if the XML is “well-formed” (tags are closed, structure is readable) and identifies the MessageType.
• What it misses: It will not stop a message if a field marked as xs:int contains text, or if a string exceeds a maxLength restriction.

Level 2: Deep Validation (The XML Validator)

If your business logic or backend system requires strictly validated data, you must add the XML Validator component to your pipeline.

• Best Practice: Place the XML Validator in the Validate stage of your Receive Pipeline, immediately after the Disassembler.
• What it does: It performs a full XSD validation. It checks every restriction, enumeration, and mandatory field requirement you defined in the BizTalk Schema Editor.

By default, BizTalk Server will examine only the namespace and the root node name of a message to identify and validate the schema, and will not detect extra elements in the message body.

To perform a deep validation of a message format, you have to:

• Create a Receive Pipeline with the XML Disassembler component;
• Specify the schema to validate the message against
• And set “Validate Document Structure” property to True.

XML Disassembler only validates the structure of the input XML document; if you want to validate any restrictions specified in the schema, you have to use the XML Validator component in the “Validate” stage of the receive pipeline.

When Should You Use Each?

• Default Validation: Sufficient for internal trusted traffic or when you want the highest possible throughput.
• Deep Validation: Mandatory for edge cases, public-facing Web Services (ASMX/WCF), or when receiving data from external partners, where you cannot guarantee quality.

Pro-Tip: Handling Validation Failures

Remember that if the XML Validator fails, the message is suspended. If you are using a Request-Response port (like a Web Service), the client will receive a generic SOAP fault unless you use a custom pipeline component to catch the validation error and return a friendly message.

Hope you find this helpful! If you liked the content or found it useful and would like to support me in writing more, consider buying (or helping to buy) a Star Wars Lego set for my son.