One of BizTalk’s greatest strengths is that messages are not lost. Even if there is an error processing a message we still get a suspended message that an administrator can handle manually. Sometimes though that is not the preferred way of handling errors. When working with web API’s it is common to let the client handle any errors by returning a status code indicating if the request was successful or not, especially if the error is in the client request.
There is a standard pipeline component included in BizTalk that can validate any incoming XML message against its XSD schema, however if the validation fails the request will only get suspended and all the client receives is a timeout message and an administrator will have to handle the suspended message even though there is not much to do about it since the client connection is closed.
One way of handling this is to do the validation in an orchestration, catch any validation errors and create a response message to return but writing an orchestration for just handling validation doesn’t make much sense with the performance implications and all.
A better solution would be if we could:
HTTP 400status code to indicate to the client that the request was bad.
Since the receive pipeline is the earliest stage we can inject custom code in, a custom pipeline component would be the best fit.
The pipeline component would need to execute the standard XmlValidator component and catch any validation error thrown by the validator. We could of course log any validation errors to the event log if we still would like some error logging.
If a validation error was caught, we need to create a new message with the validation error details so the client understand what is wrong.
The context property OutboundHttpStatusCode should be set to 400 so that the adapter knows to return the message with a status code of 400 bad request.
To prevent any further processing of the message and indicate to BizTalk that the new message is the response to return to the client, a number of context properties related to request response messages need to be set. Correlation tokens are copied from the request message to make the response go through the same receive port instance.