This post originated from an RSS feed registered with .NET Buzz by Mark Levison. Original Post: BizTalk Server 2004 - Mapping Best Practices #1 Feed Title: Mark Levison Feed URL: /WebLog/error.aspx?aspxerrorpath=/WebLog/mlevison/Rss.aspx Feed Description: Musings on No Touch Deployment, .NET development and photography Latest .NET Buzz Posts Latest .NET Buzz Posts by Mark Levison Latest Posts From Mark Levison

Where Do I Put My Maps?

I get this question all the time and the best answer I've seen comes from Lee Graber, a veteran BizTalk developer at Microsoft.

“While there are actually some performance related reasons to put your maps in the receive and send ports, there are much better business reasons for doing it outside of your schedule. We tend to refer to mapping in receive and send ports as document normalization. In the case of receive ports, you are normalizing the documents from the format of your customers into an internal standard format. On the outbound side, you are converting out of your normalized format and into the specific format of your trading partner or internal application. If you embed the map in the schedule and the partner changes the format, not only do you have to rebuild the map, you have to rebuild the schedule to use the new version of the map. Also, what happens when you add a new partner with a new format. That is a new map and if you have embedded the map in a schedule, it means a new schedule. This is exactly why we added support for multiple maps (one per source message type) on the receive port so that you could create a single location for all of your partners and easily handle normalize into your internal standard formats. Putting these types of maps in schedules would be a bad idea. There are times when it makes sense to use a map in a schedule. When you need to generate a new message in the schedule and use the modified (mapped) contents of an existing message as the base. When you want to map multiple parts of a message into one outbound message (this type of mapping cannot be done in a receive / send port). There are performance gains which come from doing mappings in receive ports sometimes, but they are mostly around how many persisted messages your scenario generates and it is a bit complicated to explain. The actual mapping technology is the same. To keep your internal business logic from getting tightly couple with the document formats of your trading partners, you should do your document normalization (mapping) in the send and receive ports.”