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 wocould 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
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 wowould do
It, But that wasn' t what they were expecting: they were expecting the simplest
(And computationally slowest) way of doing it. And I realized that has people
Use this mechanism as theyDon't know there's any other way.

Why
Do I say this? I'll explain as I give my solutions.
First of all:
Solution that was expected was to use an orchestration to do the validation-
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
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
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
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
Biztalk developers don't dig any deeper than that.

Schema Validation
And SOA
When you create a web service, you are explicitly defining
Contract between that service and a client of that service. There are using 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/empty world, it shocould be one XML
Message in, one XML message out.

Options
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 shoshould raise a soap fault-you shouldn't return
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
"123") You 'd expect CT the method to throw an exception-not to return you
String with a message saying an error had occurred.
Why shoshould 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
Returning detailed error information: Soap faults.
Additionally, when you're
Using BizTalk why wowould you knowingly allow an invalid message into BizTalk? You
Wouldn't allow a stranger into your home whilst you checked their credentials
Wocould you? Why waste processor cycles on the BizTalk Server (and trips to
MessageBox) dealing with a message it can't process?

[If you want a hassystemic-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
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
Dealing with things.
You create a custom receive pipeline, with both
XmldisassemblerAndXmlvalidatorComponents in it, and you set
"Validate document structure" to true onXmldisassembler.
(It's
Important to know the difference between the two here:Xmldisassembler
Will validate the document structure,XmlvalidatorWill
(Additionally) validate any restrictions specified in the schema ).
Note:
A send pipeline, you can just useXmlvalidator, And additionally
XmlcyclerIf you wish to demote context properties into your sent
Message.

What happens if the document doesn't validate?
In BizTalk
2004, an exception wocould be thrown in the pipeline-if you didn't handle this
Then the message wocould 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 Stephen bouillon's enhancedvalidator, which wowould wrap the xmlvalidator, catch
The validation exception and generate a new message which was placed in
MessageBox. We cocould then write an orchestration or send port which cowould
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
Error Report and dropping this message in the MessageBox (it's important
Realize that an error report is not a new message-it's the received message
With some additional context properties ).

3. Validating in
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
Easiest way of doing this.
For validating in an orchestration, you have
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
Transform in your orchestration, this will also cause the schema to be
Semi-validated-under the covers, BizTalk is usingXsltransformAnd
XpathdocumentClasses, 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
Orchestration-Why write code when it's written for you already in
Xmlvalidator component ??

If you 've
Found another mechanic for validating instances (or I 've missed one) Please let
Me know in the comments, or using the mail icon at the bottom of
Page.

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