This is follow up on a post back in August on Untyped Messages. This also combines information from another post of mine on Promoted Properties.
Ok, so what is the big deal then? Well, I took my untyped message sample and updated it to use MessageContextProprertyBase properties. This eliminates the need to cast the message into a specific type to get access to promoted properties. This greatly reduces the work inside the Orchestration and greatly increases your flexibility!
What exactly are these properties that you are talking about?
Well, let me show you. Here is a screen shot from a BizTalk Property Schema.
The default is MessageDataPropertyBase and those are only available through typed messages.
How do you know what type of Properties you have inside your Orchestration?
MessageContextProprertyBase Properties are White and look like all the other Properties.
MessageDataPropertyBase Properties are Yellow.
CRITICAL: The downside to working with untyped messages inside on Orchestration is they can not be mapped using a Transform Shape.
CRITICAL!: The MessageType property seems to be wiped out by the Send Port. This prevents mapping in the Send Port as well since the Map uses MessageType to determine the inbound document for the map.
The true potential of untyped messages with MessageContextPropertyBase Properties can be seen by looking at a new, updated sample working with Untyped Messages. It will help to download the original version as well.
DOWNLOAD: Updated Untyped Messages Sample
Why not get the information I want out of the XMLDocument using XPath? Well, Promoted Properties allow for greater flexibility because the structure/schema of the XML message is not needed inside the Orchestration. You define in your schema what node represents your desired properties. Furthermore, you can set properties in a pipeline that might never exist in your message.
Take Away: To increase flexibility, promote reuse, and reduce message variables, try to make your Orchestration independent of your Message Type when it makes sense to do so.
Here is an update to mapping in Send Ports with untyped messages from an Orchestration.
Send Port Binding Type:
Specify Now – Send Port Map does not work (MessageType is lost)
Specify Later – Send Port Map does not work (MessageType is lost)
Specify Later inside Scope Shape – Send Port Map does not work (MessageType is lost)
Specify Later with Delivery Notification – Send Port Map does not work (MessageType is lost)
Direct Message Box Binding – MessageType is preserved and the correct output message is received! But, the Orchestration Suspends and gives the following error:
Exception occurred when persisting state to the database.
Exception type: PersistenceException
Source: Microsoft.XLANGs.BizTalk.Engine
Conclusion: From my tests so far, it appears that mapping in the Send Port with untyped messages is not possible.