BizTalk Mapper Rant

In the spirit of full disclosure, I want to declare that this post is a
rant. Specifically, it is a nerd-rant around the BizTalk mapping tool.
If you have no interest in either rants nor the BizTalk mapper, feel
free to stop reading now. With that taken care of, let the ranting

I have just finished another week working on a client’s BizTalk system
and once again I find myself horribly irritated at the BizTalk mapping
tools. One of the fundamental tasks of any integration platform is the
transformation of data from one format to another and this is typically
done using some sort of mapping tool. What bothers me is how archaic the
BizTalk mapping tool looks and behaves, and how it turns a simple
mapping job into a Sisyphean task.

From a user-experience perspective, the BizTalk mapper looks and feels
clunky and outdated. For simple straight-across mapping, it gets the job
done, but for more sophisticated maps it tends to make mapping harder
than it needs to be. For starters, the inability to cut/copy/paste map
artifacts is ridiculous. There is no good reason that I can think of as
to why this is not permitted. Modern development is typically undertaken
in an iterative fashion. With the BizTalk mapper the only option for
doing iterative map development, say if you want to move some mapping
artifacts to a new tab, is to delete the artifacts from the original
tab and recreate them in the new tab
. That would be rough equivalent
of saying that in order to move code from one class to another it would
require you to delete the code from the original class, and re-type the
code into the new class. In a large EDI implementation using BizTalk,
this equates to a lot of wasted time and developer productivity.

This leads into my next gripe. What was the point of integrating the
BizTalk mapper into Visual Studio and making it so complicated that only
a trained developer can use it? As an integration consultant, I want to
help my clients architect and build integration solutions. I do not want
to sit there cranking out data maps. With other integration platforms
mapping is an activity typically done by business analysts. But with
BizTalk my clients would be forced to purchase an expensive Visual
Studio license just for BizTalk mapping. Instead mapping is assigned to
a developer who already has a VS license. If that was not enough, the
mapping experience in BizTalk is so sub-par, that in many cases it is
easier to skip the visual tools altogether and write an XSLT script
instead. ^[1]^ Again, I would love to hand mapping tasks to a business
analyst but since any non-trivial mapping task will require the use of
either XSLT or .NET scripting I can not reasonably expect the business
analysts to have the programming background necessary to accomplish the

This brings me to my final complaint. Why has the BizTalk not been
updated in the past four releases? ^[2]^ I realize that over time
Microsoft has added new functoids to mapping toolbox, but fundamentally
the mapper has seen little love over the past four years, and remains
relatively unchanged in the public beta for BizTalk 2009. If Microsoft
is going to continue to punish developers with the current mapper
architecture, the least they could do is update the XSLT and XPath
processors to support the current version of these technologies. At
least that would provide some relief to the friction involved in BizTalk
map development.

It is obvious with the release of .NET 3.0 and 3.5 that Microsoft is
working on building a new foundation for integration. The release of the
Windows Communication Foundation and Windows Workflow Foundation, and
upcoming technologies like Oslo and Dublin look to be the building
blocks for the next generation of integration technologies on the
Microsoft platform. What I have a problem understanding is why are these
new technologies not being incorporated into the upcoming release of
BizTalk 2009? SurelyMicrosoft could leverage the newer releases of the
.NET Framework to provide a better mapping experience to the BizTalk
developer community. In fact it makes one wonder if Microsoft’s
reluctance to update the tools in BizTalk is a signal that the product
is going to be discontinued. There is also the possibility that BizTalk
is undergoing some sort of radical change, so Microsoft is unwilling to
invest more resources into the current version. Either way it does not
fill me with confidence for the future of BizTalk.

With that I am going to bring this rant to a close.

[1] In fact, I now typically recommend to my clients that they learn
XSLT and skip the visual mapper altogether.

[2] The first version of BizTalk I have used is 2004. I do not know what
the mapper was like in previous versions.