Visual Message Instance Creator - BizTalk Needs One!

Scott Colestock has highlighted an important point that often causes me consternation with BizTalk: creating a new message instance from scratch in an orchestration. I generally hard code the skeleton xml and load it up in to an XML document then assign the attributes using promoted properties or xpath (see Scott's post on how it is done).

What would be really nice however, is to have a visual way to construct message instances. Here we are dropping shapes on to orchestrations in a very visual way only to disrupt this harmony by having to handcraft xml and embed it within an expression shape!

But what I find really frustrating is that BizTalk is so close to having a visual message instance creation tool already available out of the box; its the mapper. If Microsoft could just tweak the mapper, as explained below, it would be so easy and a far more natural way to create message instances.

1. It should be optional as to whether a source schema is required on the left hand side. In many cases when creating a new message you just don't need one
2. There should be a new functoid to access message context properties. Drop one on to the pallete, indicate which context property you want and then link it to an element on the destination schema
3. There should be a new funtoid to access orchestration variables. This would be used in a similar way to the context property functoid above
4. Some other functoids would be useful such as "static value" functoids where a value can be hard coded in to it

This way it will be possible to visually construct a new message instance without the need of having a source message instance to seed it. These message instance definitions should not be stored in a separate xml file, as the maps currently are, but stored within the orchestration xml file instead. This would help to keep them self contained within the orchestration and reduce the number of files created in your project. Even better would be a new orchestration shape to represent them. Simply double click it and your message instance creation definition would open up.

Because BizTalk is managing the definition it can also do error checking on it. So when you change the destination schema BizTalk would know about it and flag it up as an error. This would at a stroke eliminate those awkward hard to find bugs when using handcrafted xml.