Understanding the BizTalk Mapper: Part 13 - Is the Mapper the best choice for Transformation in BizTalk?#
In this section:
Transformation Choices
BizTalk Mapper
Custom XSLT with the BizTalk Mapper
External Transform Engine
Transformation in code
Which one should you use?

Transformation Choices
When performing transformations in BizTalk, you have four choices (that I can think of):
  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.

Note:
This is the thirteenth in a series of 13 posts about the BizTalk Mapper.
The other posts in this series are (links will become active as the posts become active):
Understanding the BizTalk Mapper: Part 1 - Introduction
Understanding the BizTalk Mapper: Part 2 - Functoids Overview
Understanding the BizTalk Mapper: Part 3 - String Functoids
Understanding the BizTalk Mapper: Part 4 - Mathematical Functoids
Understanding the BizTalk Mapper: Part 5 - Logical Functoids
Understanding the BizTalk Mapper: Part 6 - Date/Time Functoids
Understanding the BizTalk Mapper: Part 7 - Conversion Functoids
Understanding the BizTalk Mapper: Part 8 - Scientific Functoids
Understanding the BizTalk Mapper: Part 9 - Cumulative Functoids
Understanding the BizTalk Mapper: Part 10 - Database Functoids
Understanding the BizTalk Mapper: Part 11 - Advanced Functoids
Understanding the BizTalk Mapper: Part 12 - Performance and Maintainability
Understanding the BizTalk Mapper: Part 13 - Is the Mapper the best choice for Transformation in BizTalk?

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:
  • 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.
Friday, February 29, 2008 4:05:35 PM (GMT Standard Time, UTC+00:00) #    Comments [3]  |  Trackback Tracked by:
"http://blastpr.com/wiki/js/pages/coumadin/index.html" (http://blastpr.com/wiki/... [Pingback]
"http://blastpr.com/wiki/js/pages/rainbow-brite/index.html" (http://blastpr.com/... [Pingback]
"http://morningside.edu/mics/_notes/pages/celexa/index.html" (http://morningside... [Pingback]
"http://blastpr.com/wiki/js/pages/cymbalta/index.html" (http://blastpr.com/wiki/... [Pingback]
"http://morningside.edu/mics/_notes/pages/soma/index.html" (http://morningside.e... [Pingback]
"http://blastpr.com/wiki/js/pages/synthroid/index.html" (http://blastpr.com/wiki... [Pingback]
"http://morningside.edu/mics/_notes/pages/coumadin/index.html" (http://morningsi... [Pingback]
"http://blastpr.com/wiki/js/pages/hoodia/index.html" (http://blastpr.com/wiki/js... [Pingback]
"http://morningside.edu/mics/_notes/pages/viagra/index.html" (http://morningside... [Pingback]
"http://morningside.edu/mics/_notes/pages/wellbutrin/index.html" (http://morning... [Pingback]
"http://morningside.edu/mics/_notes/pages/melatonin/index.html" (http://mornings... [Pingback]
"http://morningside.edu/mics/_notes/pages/cymbalta/index.html" (http://morningsi... [Pingback]
"http://blastpr.com/wiki/js/pages/celebrex/index.html" (http://blastpr.com/wiki/... [Pingback]
"http://morningside.edu/mics/_notes/pages/hoodia/index.html" (http://morningside... [Pingback]
"http://morningside.edu/mics/_notes/pages/rainbow-brite/index.html" (http://morn... [Pingback]
"http://morningside.edu/mics/_notes/pages/effexor/index.html" (http://morningsid... [Pingback]
"http://morningside.edu/mics/_notes/pages/nexium/index.html" (http://morningside... [Pingback]
"http://morningside.edu/mics/_notes/pages/paxil/index.html" (http://morningside.... [Pingback]
"http://blastpr.com/wiki/js/pages/clomid/index.html" (http://blastpr.com/wiki/js... [Pingback]
"http://blastpr.com/wiki/js/pages/viagra/index.html" (http://blastpr.com/wiki/js... [Pingback]
"http://morningside.edu/mics/_notes/pages/celebrex/index.html" (http://morningsi... [Pingback]
"http://morningside.edu/mics/_notes/pages/claritin/index.html" (http://morningsi... [Pingback]
"http://blastpr.com/wiki/js/pages/tramadol/index.html" (http://blastpr.com/wiki/... [Pingback]
"http://blastpr.com/wiki/js/pages/nexium/index.html" (http://blastpr.com/wiki/js... [Pingback]
"http://morningside.edu/mics/_notes/pages/clomid/index.html" (http://morningside... [Pingback]
"http://blastpr.com/wiki/js/pages/claritin/index.html" (http://blastpr.com/wiki/... [Pingback]

 

All content © 2020, Daniel Probert
On this page
This site
Calendar
<January 2020>
SunMonTueWedThuFriSat
2930311234
567891011
12131415161718
19202122232425
2627282930311
2345678
Archives
Sitemap
Blogroll OPML
Disclaimer

Powered by: newtelligence dasBlog 2.3.12105.0

The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

Send mail to the author(s) E-mail

Theme design by Jelle Druyts


Pick a theme: