Each of these offers their own benefits depending on your requirements.
Normally your choice will depend on 3 factors:
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.
Download the complete series as a single Microsoft
Word document (1.2MB) or Adobe
PDF document (620kb).
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:
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:
Cons:
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:
Cons:
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:
Cons:
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:
Cons:
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.