XPathUpdateException when assigning value to constructed messages · Gobbledygooks by @riha78

A random pile of .NET, BizTalk and integration focused scribbles by @riha78.

A bit more about me and a few projects I am currently spending time on.

XPathUpdateException when assigning value to constructed messages


Ever had a "use of unconstructed message" error message in your orchestrations? Then you know that messages has to be constructed before one can use them within orchestrations. Basically messages in orchestrations are created in ports or when executing a map in a construct shape. However there is also the possibility of creating messages in expression shapes using code. Matt Meleski does a great job explain the different approaches in his Constructing BizTalk 2004 XML Messages (In an Orchestration) - Choices blog post.

However there are some pitfalls when constructing messages from scratch within orchestration (a part from the fact that there really isn't a clean way of doing it ... Scott Colestock has some ideas in this post).

A common problem is XPathUpdateException. Say one has a mapping that looks like the one below where one node isn't mapped. This will create a message without the ElementB element. This doesn't have to be in a mapping, it could also happend when constructing a message using code in a expression shape. A common scenario is that we add code for constructing the bone structure of the XML message, then change the schema without updating the construct code. Ergo a message will be constructed without that element (could be both valid or invalid XML then depending on the Min Occurs value)!


When we then try to add a value to the element that hasn't been created the exception will be thrown!

One way around when using a map is to make sure to have a default value on every element to force them be constructed. Adding the following to map will make it work.

It's a one time mistake but it's good to know what to look for when the XPathUpdateException in Microsoft.XLANGs.Core.XSDPart.SetDistinguishedField (if it's a distinguished field that is) shows up in the event log.