Often when developing a generic business process, using generic documents makes the most sense.
Consider the core functionality in the ESB project I’m on, we need to take a document of ANY type (type will not be known at development time), and apply a map that will result in a document whose type is not known at development time. Without using generic documents, the only way to do this would be to have a specific mapping process for each combination of input and output documents. However, this is not a workable approach as the numbers of schemas and maps start to grow. Generic documents solve this problem. In fact, for the ESB project I am working on, generic documents are the cornerstone that functionality is being upon.
With BizTalk 2004, you would specify a generic document by creating a new message, and using the type browser to navigate to the System.Xml.XmlDocument class. In BizTalk 2006, System.Xml.XmlDocument has been elevated to a first class citizen status and is now available without needing to browse to it, alongside System.String and System.Boolean.
So, in theory, for my generic mapping requirement, I would receive an inbound System.Xml.XmlDcoument, and apply a map to create an outbound System.Xml.XmlDcoument.
This all works great, and in most cases is enough. However, there is one critical difference between using generic documents like this and using strongly typed documents. In the generic ESB case I was dealing with, the difference is enough to be a show-stopper. The problem is that promoted properties are not promoted in the outbound document if the document is not strongly typed (schema specified at design time).
To understand why, consider when property promotion happens. It can happen in a receive pipeline, once the document type is identified. Promoted properties for a known schema will have been defined in a property schema associated with that known schema. When you create a document of a known type in an orchestration, BizTalk is aware of the property schema associated with the new message and will promote the properties.
However, with a generic document, this does not happen. If you use direct-bound ports (which in my opinion is what all BizTalk developers should be doing in order to create extensible, loosely-coupled and scalable processes, see my previous post) you will find that an exception occurs when the outbound message is persisted to the MessageBox. The exception message is that BizTalk was unable to route the message because no subscribers were found. This will happen even if you have a valid subscription set up that is filtering on a promoted property in the message. This happens despite the fact that the associate property schema was deployed, and you can assign and read the properties in question in your orchestration. If you examine the message that got suspended, and look at the context properties, you’ll see that your values were assigned (so the subscription should have been found), but the property is in fact not promoted, so BizTalk has no way to match the subscription.
Pity, SOOOOO close to generic nirvana. So the question now becomes: is there a way to force property promotion for generic documents? The answer, very fortunately for those of us working with generic documents, is yes, it can be done.
In order to do this, you need to create a correlation set, and initialize it in the send port that is bound to the MessageBox. Although it may seem that you are creating a correlation set that you have no intention of following, but it does make sense as the subscriber(s) you have set up that are looking for those promoted properties are in effect following the correlation. You can create a single correlation type that references one or more message context properties, and they will all be promoted and become available to the messaging engine to do routing.
The punch line: in BizTalk 2006, this is actually now documented in the section dealing with correlation types. However, unless you know and understand the technique, you’d never go looking there. This is the reason I put this post together, enjoy, and happy travels as you do off on your loosely-coupled generic way!