There have been several folks who have discussed how to create messages "from
scratch" within an Orchestration context - you can read
Matt's thoughts and check out a BizTalk
documentation excerpt. This is a common question, and I had an
additional technique I thought I would share...
Background: When you have a schema that has many promoted properties (or
distinguished fields), or many elements that can be set via xpath expressions
easily, it can be useful to simply start with a "template" document instance
and populate the element content that you are interested in.
In this situation, you will often have a "Message Assignment" shape that looks
something like this:
someMsg = xmlDoc;
someMsg.SomeElement = "some content";
// (or xpath(someMsg,someElementXPath) = "some content" if we don't have a
// distinguished field.)
One disadvantage of loading up "template" xml documents from either expression
shapes or code (via XmlDocument.LoadXml) is that those xml fragments can get
easily "lost", and are hard to update early in the development cycle when
schemas may still be in flux. Loading the template files from the file
system is problematic because the question arises "where should I store these
files, so that I can find them in any environment I deploy to?" (Solvable, but
Instead, why not embed the template xml documents as assembly resources?
For those unfamiliar with that process, I have a short tutorial here (& a
// Populate the "rest" of the message with distinguished fields, promoted
// properties, xpath expressions, etc.
sampleUsingTemplate.SomeElement = "foo";
The class I have supplied will cache the loaded resources in a hashtable for
performance sake, and allow you to load resources as both strings and
A last thought: Many people ask, "Why can't I just create a message using a new
operator or a default constructor of some sort?" Well, because few XSD schemas
sufficiently constrain the set of valid instance documents enough for that to
be useful - what form would a "default message" take? (Would it have the
optional elements you need? Some elements that you don't want?)
Enjoy - feedback appreciated!
Scott Colestock lives, writes, and works as an independent consultant in the Twin Cities (Minneapolis, Minnesota) area.