A few weeks ago, QuickLearn Training hosted a webinar with an overview of a few of the new features in BizTalk Server 2016. This post serves as a proper write-up of the feature that I shared. In this write-up, I’d like to drill a little deeper into the things that were discussed and even explore some other aspects that we simply didn’t have time for. In my portion of the webinar, I spoke about using the XslCompiledTransform class in maps. If you missed the full webinar, check it out over on the QuickLearn Training YouTube channel. If you prefer you can just watch the section on the XslCompiledTransform class.
Comparing XslCompiledTransform and XslTransform Performance
There are so many resources comparing these .NET classes against one another that I’m really not sure that there’s anything I can add to the discussion. The best of these resources is the one I cited in the webinar by Anton Lapounov. Simply put, if you put these two classes in a straight-up foot race, the XslCompiledTransform is going to take longer to load, but will blow away the XslTransform class when it comes to the actual time to transform.
Comparing XslCompiledTransform and XslTransform Behaviors
Now, if you’ve closely followed the features of other releases you may think this isn’t actually a new feature, and you would be mostly correct. You see, in BizTalk Server 2013 the mapping engine was changed to utilize the XslCompiledTransform class instead of the XslTransform class that the mapping engine had been using since BizTalk Server 2004. While this change was made to reap the performance benefits of the XslCompiledTransform class over the XslTransform class, it was a change that Microsoft made unilaterally to all BizTalk maps compiled for BizTalk Server 2013. While the intention was pure, this change wasn’t universally welcomed by BizTalk developers. There are several great write-ups exploring issues that arose in existing maps when updated (for example this great blog post from Dan Rosanova, or just the Known Issues for BizTalk Server 2013). In case you’re pressed for time and can’t read those, the issues arise from the differences in behavior between the XslCompiledTransform class and the XslTransform class. The specific differences are:
- If an input XML field is empty or contains a false value, the Scripting functoid will treat the input as a true
- The XslCompiledTransform class only supports calling public methods
- The XslCompiledTransform class does not support returning null
- In the XslCompiledTransform class, function overloads are differentiated by number of parameters rather than types
- The XslCompiledTransform class utilizes the XPathArrayIterator type rather than the XPathSelectionIterator type for looping through repeating records within the Scripting Your script must call the MoveNext() method to advance properly
While these five changes may seem relatively trivial, for some people they presented issues that completely broke their maps. There is a registry setting which allows you to tell the mapping engine to use the XslTransform class, but the change is applied globally to all maps and negates the potential performance gains offered by the XslCompiledTransform.
Setting the Transform Class for a Map
BizTalk Server 2016 now surfaces the option for the transformation class as a UI element. Furthermore, the transformation class isn’t specified globally, but instead we can set it for each map separately. So, any maps I’m upgrading that are negatively affected by the XslCompiledTransform class can target the XslTransform class. This ability to opt-in or opt-out gives us true backward compatibility that was sorely missing in the previous releases.
By default, any new or existing maps that you are upgrading will target the XslTransform class (for backward compatibility), but setting the transform class for the map couldn’t be easier. In your map, if you go to the Properties for the map grid, you will see a new property named Use XSL Transform (the default is True and indicates that the XslTransform class will be used). If you change it to False, the XslCompiledTransform is targeted instead. There is a third option for the property, Undefined. If you choose this option, that map will check the same registry settings used in earlier releases to control the transformation class.
Answering an Unanswered Question
I don’t really want to rehash my test process or results, as you can watch the webinar or download the slides to get all of that. Instead, I wanted to answer a question that was posed in the webinar that I was unprepared to answer. Niyati asked if the increase in performance would have been the same if I were calling the map in an orchestration. This configuration was not part of my initial round of tests, but I cracked open my solution, and created an orchestration so I could definitively show whether it was true or not.
My orchestration has the simplest design possible. It receives the message, runs the map, and sends the transformed message out.
I made one of these babies that runs the XslCompiledTransform map, and another that runs the XslTransform map.
I went crazy in my testing and processed 10,000 instances of each orchestration using my batch file submission method. I’m not going to write a full-blown analysis of the results because I think the numbers speak for themselves.
But That’s Not All
I had a lot of fun exploring transformation classes in preparation for this webinar and I really look forward to the next one. Please be on the lookout for details on that webinar in the coming weeks.
If you need to learn more about measuring and analyzing BizTalk Server performance, tuning performance, or controlling the throttling behaviors in BizTalk Server you really should check out our BizTalk Server Administrator Deep Dive course.