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:
xmlDoc.LoadXml("<ns0:BizTalkSampleS3 xmlns:ns0="http://BizTalkSample.Schemas.BizTalkSampleS3"> <SomeElement></SomeElement></ns0:BizTalkSampleS3>"); 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 a hassle.)
Instead, why not embed the template xml documents as assembly resources? For those unfamiliar with that process, I have a short tutorial here (& a helper class.)
sampleUsingTemplate = BizTalkSample.Components.EmbeddedResourceCache. GetXmlDocResource("BizTalkSampleS3_output.xml"); // 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 XmlDocuments.
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.