How to validate Xml Documents against schemas in BizTalk

Copy from：http://www.bizbert.com/bizbert/2007/09/01/How+To+Validate+Xml+Documents+Against+Schemas+In+BizTalk.aspx

 

How to validate Xml Documents against schemas in BizTalk

 

I got asked a question the other day: How would you validate an incoming message against a schema if the message was the request part of a request-response pair and you wanted to return a response if the request wasn't valid?

In the example given, an orchestration had been exposed as a web service, and the requirement was to validate the incoming message. If the message did not validate they wanted to return a response message with an error message in it.

I gave two of the ways I would do it, but that wasn't what they were expecting: they were expecting the simplest (and computationally slowest) way of doing it. And I realised that many people use this mechanism as they don't know there's any other way.

Why do I say this? I'll explain as I give my solutions.
First of all: The solution that was expected was to use an orchestration to do the validation - as the person explained to me, that was the only way to get the response message back to the same "connection" i.e. have it go back out as a response to the matching request.
As you'll see this is not true.
In this post I'll cover the ways to do validation.
In the next post, I'll cover how you correlate the response back to the client who is waiting for a response.

Let me say one thing: BizTalk is not magic. There is no magic (thanks Nakor). There's simply some COM+ applications, some .NET assemblies, instances of a Windows Service, some database tables... and a lot of unmanaged code.
What gets confusing are all the concepts layered on top of this - BizTalk does its best to "hide" what's really going on from you, and unfortunately a lot of BizTalk developers don't dig any deeper than that.

Schema Validation and SOA
When you create a web service, you are explicitly defining a contract between that service and a client of that service. There are many parts to that interface, but to keep things simple, I'm only interested in the schema part of it - i.e. what message does the interface accept as input, and what message does it return as output. In a doc/lit world, it should be one XML message in, one XML message out.


Options for validating Schemas

1. Validating at the End Point
So where's the best place to validate your schemas? At the end point.
That is, in the Web Service ASMX code itself.
More importantly, if the incoming message isn't valid then you should raise a SOAP fault - you shouldn't return an error message. To me, this is a fundamental tenet of good SOA design.

Think about what happens if you call a method in a class.
Say the method signature was:
   string DoSomething(string number)

Assume that this method expects a number passed in as a string, and returns some information about that number (I'll gloss over why you'd ever have a method like this!).

If you pass it "fred" (instead of "123") you'd expect the method to throw an exception - not to return you a string with a message saying an error had occurred.
Why should a Web Service be any different?

Why go to all the trouble of rolling your own message schema for dealing with invalid messages when you have a system already for returning detailed error information: SOAP Faults.
Additionally, when you're using BizTalk why would you knowingly allow an invalid message into BizTalk? You wouldn't allow a stranger into your home whilst you checked their credentials would you? Why waste processor cycles on the BizTalk server (and trips to the MessageBox) dealing with a message it can't process?

[If you want a hassle-free way of validating messages in the Web Service, look at the sample code I posted in this post:  Validating Schemas in Web Methods using Attributes
It provides for a way of decorating a WebMethod with an attribute which does all the validation work for you, so no code needs to be placed in your methods.
Additionally, it explains the problem with using auto-generated schemas in your WSDL (which is what happens when you use the Web Services Publishing Wizard in BizTalk).

Aside 1: I have to add that you also need to question the wisdom of validating a schema. You can never guarantee that a message is valid. It might pass schema validation and still be invalid. Unfortunately, XML Schema Definitions don't allow for a completely unambiguous specification of a message - you have to accept this when you choose to use XSDs and therefore understand the complexities they can add.]

2. Validating in the Pipeline
This is probably the most common way of dealing with things.
You create a custom receive pipeline, with both the XmlDisassembler and XmlValidator components in it, and you set the "Validate document structure" to true on the XmlDisassembler.
(It's important to know the difference between the two here: the XmlDisassembler will validate the document structure, the XmlValidator will (additionally) validate any restrictions specified in the schema).
Note: for a send pipeline, you can just use the XmlValidator, and additionally the XmlAssembler if you wish to demote Context Properties into your sent message.

What happens if the document doesn't validate?
In BizTalk 2004, an exception would be thrown in the pipeline - if you didn't handle this then the message would be lost, and the only way you'd know something had gone wrong is when your client timed out (if the process started from a Web Service call), and you found an entry in the event log.
To get around this we ended up using components like Stephane Bouillon's EnhancedValidator, which would wrap the XmlValidator, catch the validation exception and generate a new message which was placed in the MessageBox. We could then write an orchestration or send port which could process this message

In BizTalk 2006, if you turn off Failed Message Routing then you get the 2004 behaviour.
If you turn on Failed Message Routing, then an Error Report is created by demoting certain Context Properties promoting some new Context Properties to indicate that the message is now an Error Report and dropping this message in the MessageBox (it's important to realise that an Error Report is not a new message - it's the received message with some additional Context properties).

3. Validating in an Orchestration
This is the option that people seem to go for when they want to send a response back to a waiting Web Service client, as it's the easiest way of doing this.
For validating in an orchestration, you have to write the validation code in a C# class, and call that class from within your orchestration (examples of how to validate an XML instance against a schema in C# can be found here).
It's interesting to note that if you use a Transform in your orchestration, this will also cause the schema to be semi-validated - under the covers, BizTalk is using XslTransform and XPathDocument classes, which need valid XML to work correctly. However, this might be a bit late to discover that your message is invalid.
Personally, I've never seen the point of doing this validation in an orchestration - why write code when it's written for you already in the XmlValidator component??

If you've found another mechanism for validating instances (or I've missed one) please let me know in the comments, or using the mail icon at the bottom of the page.

The next post will cover how to respond when the request part of a request/response pair of messages is invalid - how do you send a response back to the client.