Here at codit.eu, we are always eager to try and do things as fast as possible and as efficient as possible. Lately, there has been several cases at clients/prospects, where I had to make a case for the “Codit” way of working and more specifically, how we make a BizTalk mapping… Some experienced BizTalk developers tend to look at me with an awful look of disgust, when I tell them we do not use the BizTalk mapper for mappings… at all. Yes, at Codit, we always use custom XSLT in our BizTalk mappings. And this blog post will try and explain why! First, let me talk to you about the difference between the BizTalk mapper and custom XSLT…
What is XSLT?
- XSLT or Extensible Stylesheet Language Transformations is a language for transforming XML documents into other XML documents, HTML, plain text or xsl-fo.
- XSLT is, in contrary to most programming languages, declarative instead of imperative. It’s based on pattern matching. Rather than listing an imperative sequence of actions to perform, templates define how to handle a node matching a particular XPath-like pattern.
- XSLT uses XPath.
- XSLT was not made for BizTalk Server, it is BizTalk Server implementing XSLT 1.0. To this day it still remains on this version, including BizTalk Server 2016 CTP2! XSLT 2.0 has been out for a long while now, but BizTalk remains at 1.0, due to the fact that .NET does not offer support for XSLT 2.0. With XSLT 3.0 out last year, one might wonder if XSLT 2.0 support will ever come…
What is the BizTalk mapper?
- The BizTalk mapper is a, very nifty, visualisation tool, created to visualize a mapping between a source and a target schema.
- The BizTalk mapper is quite easy to use, especially since it uses a drag-and-drop mechanic to map one field to another.
- Using functoids, a developer can loop/modify/adapt/select certain data before putting the result in the resulting output.
- Using more than one cascading functoids, one can easily chain up these operations to allow a more complex mapping.
- The BizTalk mapper generates XSLT 1.0!
- The BizTalk mapper facilitates complex mappings, by using pages in the grid view
Let’s compare!
Comparing one to the other is always hard, especially if you are in favor of one in particular. Let’s try to be as objective as possible anyway… Let me know in the comments if you find otherwise!
| Performance – winner: XSLT | |
| XSLT: SCORE | Mapper |
| Custom XSLT is – unless you are working with really easy maps – almost always better performing. The reasoning behind this is that the mapper will for – example – create too much variables for every substep. Any developer optimizing a mapping will see straight away that these might be optimized. | The mapper is a tool which generates XSLT. For easier mappings, the XSLT will be as good as anyone can write it. The moment it gets more complex, you would be able to tweak the generated XSLT code to perform better. |
(So far: XSLT 1 – 0 Mapper)
| Ease of use – winner: Mapper | |
| XSLT | Mapper: SCORE |
| For some reason XSLT is something special. People tend to be afraid of it when they do not know it. As it happens, not many people tend to easily write XSLT, so there is a certain threshold to get over. For people already knowing XSLT, it flows naturally. | The mapper is built to be intuitive and easy to use, for the untrained BizTalk professional and the seasoned BizTalk veteran. There are hundreds of scenarios you can tackle easily with it, only for some there is a need for a custom functoid or some custom XSLT. |
(XSLT 1 – 1 Mapper)
| Source Control – winner: XSLT | |
| XSLT: SCORE | Mapper |
| If you use a custom XSLT file, you need to add it to your solution and also to your source control. For every check-in you perform, you get a perfect version history: you can clearly see each and every byte of code that was changed, since it’s just text, like any source code you write in .NET. | The mapper is more complex for source control versioning. Your .btm file contains representations of the graphical links you made by dragging and dropping. It contains codes for every page, functoid, etc… and it’s location on the grid. Updating a mapping can affect a whole lot more code than just your small change. |
(XSLT 2 – 1 Mapper)
| Maintainability – winner: draw | |
| XSLT: SCORE | Mapper: SCORE |
| It might take some time to ‘dive’ into a mapping when working with XSLT. But the same can be said from the mapper. Making small changes can be as easy as searching for the node(s) you need to change and updating the code. |
It might take some time to ‘dive’ into a mapping when working with the mapper. Especially when working with multiple pages and complex links and functoids, in several cases it might even take longer. However, just like in XSLT, it depends how you structure your map. |
(XSLT 3 – 2 Mapper)
| NEW Interoperability – winner: XSLT | |
| XSLT: SCORE | Mapper |
| XSLT can be run anywhere and there is support for it everywhere. Visual Studio, Notepad++ (XML Tools plugin), Altova, Eclipse, oXyGen, etc… It can be run on lots of editors, can be run from .NET/Java/etc… XSLT is a standard, here to stay, proven and tested. Be sure however, to keep yourself to XSLT 1.0! Try to avoid inline c# code or extension objects or your interoperability is also gone! | Unfair competition for the mapper. The mapper is available in the BizTalk Developer Tools for Visual Studio. Your existing mappings will however be transferable to Logic Apps, with existing functoids. But this is nowhere near as interoperable compared to XSLT. |
(XSLT 4 – 2 Mapper)
| Debugging – winner: draw | |
| XSLT: SCORE | Mapper: SCORE |
| XSLT can be debugged from within Visual Studio. Open your XSL file and click Debug. Easy. | The mapper can be debugged, just like XSLT. You can step into functoids. Just as easy. |
(Winner: XSLT 5 to 3)
This is how we (Codit) do it
At Codit, it is custom to do practically everything in custom XSLT. However, we are not ignorant of the mapper. It is a great tool and not using it for what it does best, would be such a waste. So this is our way of working:
- Create your mapping file (.btm) and select the source and target schemas.
- Link the fields you need in your specific mapping, using the BizTalk mapper, but do not use any functoids.
- Validate your mapping in Visual Studio, locate the XSLT and place it in a ‘xsl’ subfolder, using the same filename as your btm file.
- Assign the XSL file to your BTM file and make sure to delete all of the links in your grid view. This ensures any future developer looking at the code, that no mistakes can be made: it’s all in the custom XSLT.
- Edit your custom XSLT and enjoy your freedom!
Some XSLT tips & tricks
Here are some additional tips a tricks I like to tell our developers which are starting off their integration career:
- Use proper spacing in your XSLT! Empty lines between stylesheets, empty XML comments before and after a <xsl:for-each/> make your structures stand out so much more.
- Use proper, clear and descriptive variable naming. It make such a difference.
- Write and use comments for “future-you”! Don’t give “future-you” any reason to hate “past-you”, because you will regret that extra 5 minutes you neglected to spend on comments while you still ‘got it’.
- Don’t do math in XSLT! Don’t tell anyone, but it’s not very good at it. Use extension objects or specific math functions.
- Avoid inline C# code in your XSLT code at all costs. We have seen that inline C# code in your mapping may result in memory leaks if you call your mapping from a custom pipeline component for example.
- Stylize the first line of your stylesheet. Put all namespaces on a separate line for example, for easier readability.
Conclusion
XSLT is the way to go! Although it does mean you need to invest in yourself. XSLT 1.0, XPath 1.0, etc… these are things you will need to learn. However, consider this is a good investment! Knowledge of XSLT can be used in several fields, from front-end design to PDF generation, it is something you will need at some point and it is very easy to learn! Also consider this: as a BizTalk / integration consultant: people using the mapper will not easily be able to handle an XSLT-file. People who know XSLT, can do both, since any BizTalk map can be converted to XSLT in a few seconds. Also this: whenever things get really complex, the developers which favor the mapper, still might need to copy/paste some of that custom XSLT in their scripting functoids to make their mapping work.
If you are interested in learning XSLT, please check the reference material provided at the end of this post. Also, be aware that Codit offers quite an extensive XSLT training, designed for integration products like BizTalk Server, Logic Apps, etc…
Please let me know if you have any remarks/comments. I’ll be happy to elaborate further or to review some sections, given enough feedback.
For now:happy XSLT-ing!
Reference material
XSLT W3 Schools Tutorial – http://www.w3schools.com/xsl/
Note: this post also appeared on https://pvandenheede.wordpress.com/2016/09/20/the-case-for-xslt/
Subscribe to our RSS feed