Dynamic mapping is the concept of specifying the map to be used for a transform at runtime inside the orchestration. That means no Transform Shape is used to specify the map or input and output schemas.
The help guide talks about dynamic mapping. It is under the heading “Assigning to Transforms Dynamically”. The help guide does not go into any detail as to when or why you would want to use dynamic mapping. In fact, the help guide makes the topic seems more complex then it really is.
Dynamic transforms can be used any time you have the same business process that needs to have the same or different message types sent into it but they need to have different maps based on some parameter.
Example: We are receiving a standard invoice from multiple locations for the same vendor. The schema is exactly the same but the mapping of the vendor data to the base schema (date formats, currency conversion, etc.) is slightly different based on the vendor location.
Why not map on the Receive Port? This is the most common solution to this type of scenario. This uses document normalization to transform all your messages into the same type before it hits your business process. This is a great solution but what about exceptions?
Exceptions in maps on the Receive Port can be hard to react to and even harder to orchestrate a retry or recovery process. That is when mapping inside an Orchestration and Dynamic Maps come into play.
Calling maps inside an Orchestration provide a mechanism for exception handling, reprocess, and error notification. Dynamic maps allow for greater flexibility by allowing countless maps to be called without a Transform Shape.
With dynamic maps, the map name can be stored inside an attribute in the message, read from the SSO, or read from some other custom component. Then, it is as simple as creating a System.Type with the strong fully qualified map name.
This would look something like this:
tMapType = System.Type.GetType("DynamicMaps.Map_A, DynamicMaps, Version=1.0.0.0, Culture=neutral, PublicKeyToken=faed587cb93de4ea");
construct Out_Xml
{
transform (Out_Xml) = tMapType(In_Xml);
}
If the map is inside the same assembly as the Orchestration, the full strong name is not needed. On that note, your maps usually are always inside a separate assembly...
It is important to point out this code needs to be inside an Expression Shape. The help guide says a Message Assignment shape. But, that will give a build error. If you want to use the code inside a Message Assignment shape just remove the Construct key word.
Sounds too good to be true? This does have one major drawback. If the message type of the input message does not match the message type expected in the map you get a blank message contracted. This can be seen in the sample below by running the RunMapType_ConstructBlank.xml message. So, it is import to check for this after the map.
I have put together a sample the shows dynamically calling maps inside an Orchestration both in the same assembly and inside another assembly.
Download: Dynamic Maps Inside an Orchestration
It is also common to see dynamic maps used with untyped messages (that is messages received as XmlDocuments).