In BizTalk 2004, we can execute maps either in orchestrations, or in ports. So, which place is better? And, are there other considerations besides performance that might lead us one way versus the other? Let's take a look at some best practices, and some recommendations.
First, it's generally accepted that you should map from native formats, to common (canonical) formats, as soon as possible, and from common formats, back to native formats as late as possible. The primary reason for this is that the message instances spend the longest time in a format that more services can deal with. This would lead us to put maps in the ports.
Second, from a maintenance perspective it can be easier to deploy a new map(s), then deploying a map and an orchestration(s).
Third, since we can put multiple maps in the receive port, we get some dynamic mapping behavior, in that BizTalk will determine which map to apply, based on the document type of the incoming message. This is more complex to implement in an orchestration (but dynamic mapping does have it's place), so in this case we lean toward the port as well.
Finally, if we are implementing a classic composite pattern in an orchestration, say we call five other services in the orchestration; it makes some sense to only pass the data that is needed to the other services. In fact, if they are web services, we're going to be constrained as to what we send and what we get back. This means we will probably need to execute a number of maps in the orchestration to transform the messages as required by each of the services being called.
All this being said, what's the impact on performance? We'll I've created a simple project that uses two orchestrations, one with a map, one without a map, and a simple configuration where the same map that is used in the orchestration, is used in the send port with the orchestration with no map. This eliminates any performance increase that might exist by using CBR (content based routing) by eliminating the publish/subscribe hop through the message box to include the orchestration.
Setup
I used a simple orchestration with only a receive port, a map, and a send port for the orchestration mapping test, and then copied the orchestration and removed the transform shape for the test without the map (the map is in the send port).
We bind both orchestrations to the same receive port, and use different send ports for each, one with a map, one without. A sample file is dropped in the in file folder; one file will be written to the out folder, and another to the out2 folder. Any map will probably produce similar results; I didn't go through the effort of determining what impact the map itself has on performance. I did use different file sizes however, to help better understand the effect of file size on performance (as you might expect, it is non-linear.)
Results
I just running this on my laptop, in a virtual machine, but since both of these are occuring at the same time, the numbers should remain correlated and therefore fine for comparison. All of the numbers were extracted from the duration field in HAT.
Interestingly, when the map is executed in the orchestration (at least with this configuration), the output file is in unicode so it is twice as large, but when the same map is used in the send port the file is in UTF8, half the size. Hmmmm... I'll have to look into why that is, could be some configuration issue.
Conclusion
If you need performance, put the map in the port, in this case we saw roughly 50% improvement in performance by putting it in the send port. This also makes deployment simpler, and allows us to change the maps as required, without effecting the orchestrations. Let the receive port do the work of selecting the appropriate map for you. However, when you are consuming a number of services within an orchestration, you may have to use maps within the orchestration, no problem, this works perfectly fine, and performance isn’t always the primary concern anyway.
BizTalk provides a robust and flexible platform for data transformation, understanding the tradeoffs are on of the keys to producing a high quality implementation. Hopefully this entry has helped shed some light on map performance. In a future post I’ll perform the same tests with BizTalk 2006 to see how much performance improvement we can expect from the new platform.