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!

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:

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:

• Read more of this post