WEBCAST: Schema Validation in BizTalk 2010

Just posted a new webcast on how to use out-of-the-box pipeline components to validate XML schemas for incoming messages:

http://youtu.be/4-Q9Ddy7-Tg

This is important because by default, BizTalk does not perform schema level validation on incoming messages, or even in map execution. This webcast shows two different ways that validation can be enabled, though.

Note that although BizTalk 2010 is used to demo the methodologies,  both approaches will work in all versions of BizTalk Server from 2006 onwards.

The slide deck for this webcast can be found on my SlideShare page.

Keep an eye on the Brisbane BizTalk User Group YouTube channel as more webcasts will follow!

Solving a Map Reference to a Deleted Schema

Recently a client got into a bit of “hot water” in their BizTalk integration environment because changes to a Common BizTalk application were not deployed prior to one of the dependent applications. This resulted in an error whenever trying to manage the environment’s applications via the BizTalk Admin Console (even when we followed the hint to refresh the console view):

Schema referenced by Map ‘Test.DependentApp.DependentSchema_to_CommonSchema’ has been deleted. The local, cached version of the BizTalk Server group configuration is out of date. You must refresh the BizTalk Server group configuration before making further changes.
(Microsoft.BizTalk.Administration.SnapIn)

The issue was that a new schema contained in the updated Common project was missing. Easy enough to understand, and the steps to resolve it would appear to be simple enough:

  1. Undeploy the dependent application
  2. Redeploy the Common application (using the new version)
  3. Redeploy the dependent application

However, the error above thwarted us at the very first step: we could not delete the dependent application either through the Admin Console or via BTSTask! Read more of this post

Duplicate Namespace Issue with Schema Validation in Pipeline Components

Today I was tasked with enabling XML schema validation for an existing WCF receive location in BizTalk. The client was already using the out-of-the-box XmlReceive pipeline, so I figured this would be short work, finished by lunchtime after all the regression tests had been run. Little did I suspect that I would run into a snag that would enlighten me to a new BizTalk “feature”.

Because of a compressed time schedule, we wanted to avoid having to add a new custom pipeline to the solution, even one as simple as containing a standard XmlValidator component. So instead, I opted to use port-based configuration by enabling validation within the XmlDissembler component in the existing XmlReceive pipeline. Of course, this does require specifying the list of specific schemas in the DocumentSpecNames property on the port instance:

SchemaValidation-Settings

The trick here, of course, is to ensure you get these specifications correct, as they need to be fully qualified assembly (FQN) references. Moreover, if you are expecting multiple message types, you need to separate the entries with a pipeline (“|”) delimiter, something not so obvious if you don’t read the Microsoft documentation. Even less obvious is how to deal with multipart schemas that contain multiple root nodes (at least this blog post sheds some light there).

Read more of this post

GOTCHA: Changing the Namespace on an Envelope Schema

Today I had to change the target namespace for an envelope schema to resolve a conflict that caused XML validation issues in the pipeline. I also had a few other changes to make and for various reasons I did not use the BizTalk Schema Editor tool, but instead opened the schema in the standard Visual Studio XML(Text) Editor mode.

After having dutifully made the change, tested all the maps, ensured the project compiled properly, and successfully run all the unit tests, I deployed the solution.

However, the first integration test failed because on receipt of the message with a pipeline error similar to this one:

There was a failure executing the receive pipeline: “Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35” Source: “XML disassembler” Receive Port: “XmlValidationReceivePort” URI: “C:\BizTalk\Folders\XML_VAL_IN\*.xml” Reason: This Disassembler cannot retrieve body nodes using this XPath: “/*[local-name()=’MyEnvelopeSchema’ and namespace-uri()=’http://XmlValidationTest.EnvelopeSchema’%5D/*%5Blocal-name()=’ChildSchemas’ and namespace-uri()=’http://XmlValidationTest.EnvelopeSchema’%5D”.
/*[local-name()=’MyEnvelopeSchema’ and namespace-uri()=’http://XmlValidationTest.EnvelopeSchema’%5D/*%5Blocal-name()=’ChildSchemas’ and namespace-uri()=’http://XmlValidationTest.EnvelopeSchema’%5D

Only then did I realise that in updating the target namespace of the schema, I forgot to update the BodyXPath value – which of course has the namespace all through it!

EnvelopeSchema-BodyXPath

Solution is to refresh the BodyXPath property by clicking the ellipses (…) button on the property grid and reselecting the node just above the repeating node you want to debatch:

EnvelopeSchema-Debatch

The good news is that when you use the Schema Editor to change the target namespace, this synchronisation is taken care of for you automatically. And if fact, you cannot change the BodyXPath property by typing in the property grid – you have to open the Body XPath dialog as shown above.

Moral of the story is: beware of circumventing the built-in editors and tools unless you are really, really careful. The tools are usually designed to help keep you out of trouble. 😉

Using BizTalk xpath() Function to Retrieve Optional Nodes

I often suffer a bit of trepidation when trying to retrieve values for optional XML nodes using the built-in xpath() function in an orchestration, as I wonder if it will result in an exception of some kind if the node isn’t found in the message.  This concern is heightened by reading Microsoft’s own documentation of the xpath function on MSDN:

The engine is not schema-aware, so you can only read values from or write values to a node that exists in the containing message (the complete path must exist), or the engine will raise an exception. This is true even if you supply a default value.

The conclusion from this is that if the node doesn’t exist in the message instance, you’ll get a runtime error trying to read from it using xpath(), right?

Wrong! In fact, as Leonid Ganeline proved in an older blog post, you will either get an empty string or “null”, depending on whether you wrap the XPATH expression in a string() function or not:

John Glisson - Geek of the Cloth

Thoughts on integration, technology and what-not...

prashantbiztalkblogs

My BizTalk Experiences

The CRUCIBLE

THINK: It's not illegal....yet.....

paulbouwer.com

life and technology

Abdul Rafay's BizTalk Blog

My experiences with BizTalk related to architecture, development and performance in my enterprise.

Mike Diiorio

Connected Systems and other thoughts

BizTalk musings

Issues, patterns and useful tips for BizTalk development

EAI Guy.net

Enterprise Applicaiton Integration and SOA 2.0

Connected Pawns

Mainly BizTalk & Little Chess

Man Vs. Machine

Why can't we all just get along?

Adventures inside the Message Box

BizTalk, Azure, and other tools in the Microsoft stack - Johann Cooper

Biz(Talk)2

Talk, talk and more talk about BizTalk

Richard Seroter's Architecture Musings

Blog Featuring Code, Thoughts, and Experiences with Software and Services

Sandro Pereira BizTalk Blog

My notes about BizTalk Server 2004, 2006, 2006 R2, 2009, 2010, 2013 and now also Windows Azure BizTalk Services.

BizTalk Events

Calendar of BizTalk events all over the world!

Mind Over Messaging

Musings on BizTalk, Azure, WCF, and Enterprise Integration

The WordPress.com Blog

The latest news on WordPress.com and the WordPress community.