Some colleagues of mine called me over for some advice on a problem they were having in a BizTalk orchestration the other day. They were using a message assignment shape to set the bodies and context properties for a multi-part message which contained two parts which were to be sent out over SMTP on a dynamic send port, the second part being an email attachment.

What they were trying to do was similar to the below.

And below is the error message they were receiving.

The problem with this is that all the message parts must be instantiated before context properties can be assigned to the message (note that the properties on the dynamic send port can be assigned at any time, even outside of the construct shape as those are port level properties and have nothing to do with the current message being constructed).

Instantiating a message part can be done in many ways, some which are mentioned below.
•Via a map in the construct shape
•Setting the message part to null (ex. Message.Part = null;)
•Assigning another matching message part to the new message’s appropriate part (ex. Message.Part = AlreadyConstructedMessage.Part;)
•Loading the body from an XmlDocument (ex. varXmlDoc = new System.Xml.XmlDocument();   varXmlDoc.LoadXml(“<Xml construct here>”);   Message.Part = varXmlDoc;)
•Setting the message part to be a new XmlDocument (ex. Message.Part = new System.Xml.XmlDocument();)

What took a moment to sink in (in retrospect this seems obvious, but wasn’t obvious until we thought about it since it isn’t every day that one actually deals with multiple parts in their multi part messages) is that ALL the message parts must be instantiated before context properties can be assigned to the message, not just the body part of the multi part message. Thus the expression shape should really look like the below.