Workaround for the "The part 'part' of message" BizTalk annoyance

Working with BizTalk can be a frustrating experience for many developers. At least, that's the experience I've had with the tool. In any case, my latest annoyance was the dreaded "The part 'part' of message '{Message}' contained a null value at the end of the construct block."

Scouring the web for solutions turned up virtually nothing. And so it began, my journey for a workable solution to this enigma that is BizTalk (again). My first attempts were a simple exercise of attrition. It encompassed recompiling, re-referencing, de-referencing and every other ridiculously simple attempt to resolve the problem. None produced the desired outcome; the message persisted and my patience grew increasing limited.

Thus, my next series of attempted fixes resulted in reassigning the message variable. I'll spare you from the multitude of failures incurred before succumbing to the eventual fix.

The resolution consisted of the following:
1. Declare the outgoing message of type System.Xml.XmlDocument
2. Create an xPath string that will populate said outgoing message with the entire contents of the message to be leveraged.
3. In a message construct/message assignment shape, assign the outgoing message by calling an xpath solution.

Here's a sample of the solution that worked for me:

xPathString = "/*[local-name()='Employees' and namespace-uri()='http://mySpecialSchema']";
MsgOutput = xpath(MsgInput,xPathString);

Leverage the Looping Shape in an Orchestration

So I was tasked with generating a new BizTalk project that would update an email field in a SQL database. Great I thought, a simple orchestration with straight forward mapping ought to do the trick. And there I went, pointing and clicking away until I was thrown a curve by management. I was asked to leverage a stored procedure to update the field. Ordinarily, this isn't a problem, but we leverage a canonical schema from which all people records are derived. To update the stored procedure, I needed to devise a way of updating each record contained within in the canonical, one by one. What I was able to produce was an orchestration that enacted the Looping shape.

The way our canonical is formed, it contains an instance of an employee inside an employees node. The task was to extract each employee node, one by one, and push them out to the stored procedure via a send shape. Unfortunately, my stored procedure schema could only accommodate one record at a time, hence the loop shape.
First item of business was to determine how many records my canonical contained. Well, I needed a variable to hold this value, so I created one called recordCount. Now populating the recordCount required an xpath query to return the value. Now, xpath in BizTalk, can be a little cumbersome, but possible none the less. Taking my canonical schema I created this expression in a standard expression shape:

Now, the fun part. So I created a new Loop shape and entered

recordCount > 0

The next step entailed creating the single Employee message. To do this, you need a Construct Message shape. Within the Construct Message shape, you need to apply an Expression shape and Message Assignment shape. Obviously, the Message Assignment shape will handle the mapping of data from one message to another, but the Expression does the real work here. For this exercise, I created two temporary variables of type System.Xml.XmlDocument. Within my Expression shape, I was able to populate the temp variables with one record from my grand Employees canonical schema as such:

And of course, my Message assignment shape took the single Employee message and created a new message for the send port of the Update Email stored procedure.
Looping within an orchestration can be a clunky process, so I'd recommend you leave it as a last resort. But never the less, it beats writing hundreds of lines of c# code.

Happy Coding!