Understanding the BizTalk Mapper: Part 13 – Is the Mapper the best choice for Transformation in BizTalk?

1. Using the BizTalk Mapper
2. Using a custom XSLT file with the BizTalk Mapper
3. Using a separate transformation engine (called from code)
4. Performing transformations in code

Each of these offers their own benefits depending on your requirements.

Normally your choice will depend on 3 factors:

• Performance
• Complexity
• Maintainability

Generally you will get one (or two) of these, at the cost of the third.

For simple transformations, you can get all three with the Mapper using the built-in
functoids.

In order to decide if the BizTalk Mapper is the best choice, we have to look at these
alternatives and compare them.

BizTalk Mapper

The BizTalk Mapper is the de-facto standard for transformations in BizTalk.
With this option I’m including maps created via the Mapper visual designer – I’m not
including maps which reference external XSLT.
Maps created with the designer include those which use:

• No functoids, or only functoids which emit XSLT
• Default functoids
• Custom functoids / Script functoids with referenced assemblies
• Script functoids with inline C#/VB/JScript
• Script functoids with inline XSLT

If you’re creating a map which is relatively simple (e.g. has less than 40 or so links,
and less than 20 functoids) then you could argue that the map is easy to follow and
maintain.
If your map has no functoids, or only uses functoids which emit XSLT, then your map
will likely perform very well.
If you’re only processing a small number of messages (e.g. 20 an hour) then performance
won’t be that important to you.
However, the BizTalk Mapper isn’t really suited where you have hundreds of links/functoids,
or in situations where you need the best performance possible (e.g. thousands of messages
per hour).
If you’re not sure if the Mapper will give you the performance you need, you’re better
off doing a quick proof-of-concept with a realistic map and seeing what performance
you can get.
Pros:

• Can use it with Receive/Send Ports
• Easiest to start using

Cons:

• Easy to create complex/slow maps
• Difficult to do advanced mapping
• Uses the .NET 1.x XslTransform class
• Standard functoids use inline C# code

Custom XSLT with the BizTalk Mapper

Here we’re talking about using the Custom
XSL Path property of a BizTalk Map and specifying an external XSLT file. The contents
of this XSLT file will be compiled into the assembly containing the map.
Note: bear in mind that you can’t use <xsl:include> or <xsl:import> tags
in your external XSLT – the external XSLT file needs to be complete. For more information
on this, see here.

The advantage of external XSLT is that it is very fast – usually faster than using
functoids in a map (depending on the functoids and the XSLT obviously). In you refer
to the speed tests in my previous post, you’ll see that in my tests, external XSLT
was 55 time faster than using inline scripts/default functoids.
If you’re au fait with XSLT and your project has the ability to support external XSLT
then this is the best option to use in my mind. If you use a good external XSLT editor
(e.g. Altova’s
MapForce) then the issues of maintenance and being able to visualise the map should
disappear.

However, using XSLT can be tricky: because the Mapper uses XSLT v1.0 you’re limited
in certain areas (such as string handling, date handling, and mathematical functions).
Additionally, using inherited types can be tricky if you’ve never used them before
in XSLT.
In these cases, you might be better performing your transformations in code.
Pros:

• Can use it with Receive/Send Ports
• Transforms are fast
• XSLT is the best choice for XML structures

Cons:

• Need good understanding of XSLT
• Can be difficult to maintain if not using a good XSLT editor
• Uses the .NET 1.x XslTransform class

External Transform Engine

Because of BizTalk’s ability to execute external code from an orchestration, you can
perform transformations via an external engine.
For example you might choose to use the XslCompiledTransform class
to increase the performance or your existing maps, or use an XSLT v2.0 engine such
as SAXON.
In both these cases, you could even use your existing BTM maps if you wanted (by accessing
the XSLT from the compiled map class).

Note: When using XslCompiledTransform,
using inline C# (or whatever language) in a map will normally be faster than using
an external assembly i.e. using ExtensionObjects.
The reason for this is that with inline script (i.e. using the <msxsl:script> tag)
the compiler can generate direct calls to the compiled script assembly from the transform
assembly, whereas with external assemblies, reflection needs to be used at runtime
to invoke a call. See here for
more information on this.

Using an external transformation engine makes sense if you must use XSLT v2.0 (or
are sharing XSLT v2.0 maps with other projects), or if an external engine gives you
a required feature.

However you can only use these engines from an orchestration (i.e. can’t use them
with receive/send ports), and any performance related caching of classes will be up
to you to e.g. caching one instance of a compiled transform for an orchestration’s
AppDomain.

However you can get substantial performance increases if you use the right engine
and caching strategy.
Plus if your company has an existing maintenance strategy for a given engine then
maintenance of these maps might be a no-brainer.
Pros:

• Transformation can be very fast (if correct engine is chosen)
• Can share engine/transforms between different technologies
• Can use company-standard transforms if present/required

Cons:

• Can’t use it with Receive/Send Ports, only with Orchestrations
• Can be difficult to maintain if not well understood
• Caching is left up to developer
• Performance is relevant to the skill of the developer and engine

Transformation in code

By this I mean transformation involving classes and serialization.
If you’ve read the previous post (Understanding
the BizTalk Mapper: Part 12 – Performance and Maintainability) then you’ll know
that this sort of transformation can be blazingly fast.
However this needs to be taken with a caveat: transformation in code will only be
as good as the programmer writing the code.
If you write C# or VB.NET code which performs badly, then your transformations will
perform badly.
XSLT doesn’t suffer from this problem: because the language is designed to execute
rapidly over XML structures: it’s more difficult to write poorly performing XSLT code
than C#/VB.NET code.

However, using C#/VB.NET can be a god-send in certain situations.
One example is where you’re using inheritance i.e. base elements/types in an XSD (if
any of the elements/attributes in an XML instance have an xsi:type attribute,
then you’re using inheritance).
In these cases, using source code and inheritance can reduce the amount of code you
need to write as you work with the base class without worrying about what derived
class was actually passed to you.

But remember: don’t use C#/VB.NET code to perform transformation simply because you
don’t understand XSLT. For a lot of situations it can be significantly faster to create
XSLT code to perform a transformation than the C#/VB.NET equivalent – and to another
XSLT developer it will be easier to understand and maintain.
Pros:

• Transforms can be fast
• Can be easier to develop/maintain transforms if developer knows C# better than XSLT

Cons:

• Can’t use it with Receive/Send Ports, only with Orchestrations
• Can be difficult to maintain if not well documented
• Performance is relevant to the skill of the developer

Which one should you use?

Well without knowing your requirements that’s a bit like saying “which airline
should I fly with?”
Tell me your requirements, and I’ll tell you the best airline!
[the answer’s always Virgin Atlantic or Air New Zealand, by the way…
;-)]

However (in my own biased opinion) I would suggest that a pure XSLT way is best, followed
by the BizTalk Mapper using default functoids, followed (closely) by doing transformations
in code using serializable classes.

If your performance/maintenance requirements are minimal then it won’t really matter.
If you must have the best performance, then use pure XSLT or transformations
in code.

One thing to bear in mind is this: The BizTalk Mapper creates XSLT.
XSLT is a functional language which uses templates and pattern matching and as such
is very different from a procedural/imperative language, such as Java, C#, C++, or
VB.

It’s quite common for non-XSLT programmers to ask how to create a for/while loop,
or how to do an if/case statement in XSLT.

If you’re asking those questions, you should to go do a basic course on XSLT (or read
a book) as it works in a very different way.

Properly written XSLT is elegant and fairly simple to follow.

OK, so that’s the end of this series of posts.
I hope it’s been useful to you in some way.
I’ll gladly welcome any feedback on the series.

Agree or disagree with what I’ve written? Please let me know.

Have I made any mistakes, or misrepresented a point of view? I’ll happily make corrections
if necessary.

Let me know what you think by leaving comments, or emailing me at bizbertATprobertsolutions.com
(replacing the AT with an @).

Thanks for taking the time to stop by and read.