BizTalk Server 2004: Using the mapper for complex transforms - don`t!!

In all these months of living in BizTalk 2004 land, it is only recently that I have had occasion to do something serious with the BizTalk mapper - and I am not impressed.   I had a requirement to transform an input consisting of multiple records which use attributes to capture field values into an output where, for each input record, the transform creates two similar, but different, records, and then an arbitrary sequence of additional records for those fields in the input which have a value.   Bit of a mouthful, that, but the point is that the output structure was quite different to the input structure.

I merrily created a map to do the work.  I worked out I needed to employ the Table Looping and Table Extractor functoids.   After a bit of playing around, I began to get the desired results for a subset of the record attributes.   The last thing I needed to do to complete my map was to repeat a part of my functoid design that implemented some conditional logic for about 20 or so remaining attributes in the input.

Disaster struck.  On adding a 32nd functoid to my map (is this number significant), Visual Studio began to take several minutes to compile the map.   As I added more functoids, the time went up dramatically until, very soon, the compiler would run for half an hour or so and then simply report an out-of-memory exception.

A quick visit to the Microsoft knowledgebase confirms that this is currently a known problem with complex maps.  There is a hotfix apparently, and the issues should go away in a future service pack release.   However, in this case, the problem turned out to be a blessing in disguise.   When I looked at the XSLT created by the mapper (you can find this under the temporary folder in your profile) I got a shock. For my complex map the XSLT is truly awful!  You just don`t want stuff like this is your nice, carefully crafted BizTalk solution.   I understand why the XSLT is so bad.   The mapper is precisely what it says it is - a mapper between records, fields and functoids.  It doesn`t directly represent the XSLT template-based pattern-matching world to the developer, and is constrained in how well it can exploit XSLT.  It is simply not suited to complex scenarios, especially where the output has a significantly different structure to the input.

I re-wrote the map using raw XSLT (you can use a hand-crafted XSLT to define a BizTalk map).  I know XSLT well, and it took me significantly less time to do this that it did to work out how to use the mapper to get the same results.   The XSLT is compact and efficient (the map works significantly faster than the original incomplete map created via the mapper), and is frankly easier to maintain, even though I have no graphical representation any longer.   The moral of this story - even if Microsoft fixes the problems with the mapper, don`t use it for complex transforms.