There is a new feature in BizTalk that was released as part of Cumulative update package 2 for BizTalk Server 2013 R2, it is called Use XSL Transform.  Looking at the list of updated on the CU2 page it is not obvious as it is actually slightly mislabeled as below.

3123752 FIX: XSL processing takes longer in BizTalk Server

If you actually open that link the actual heading is “Backward compatibility option to use XslTransform instead of XslCompileTransform is available at map level

Summary: This update introduces a new Compiler property, Use XSL Transform. This property is added to the Grid Properties of the map (in addition to the properties that are already listed here). This is an enhancement that’s intended to better address customer needs.

This change was one to address the issues listed in KB 2954101 Known issues in BizTalk Server 2013 – Known Issues in XSLCompiledTransform.

This change was the one that actually broke the internet BizTalk with the first version of CU2.  If you installed the first version of CU2 you would get the error “BizTalk 2013 R2 CU2 – Failure has occurred while loading a type” as detailed in the blog Bizzy Bloggers.  The issue was that all maps the Use XSL Transform property defaults to Undefined and the run-time did not cope with this default and the only fix was to change it to either True or False and re-deploy the maps. Microsoft then released a new version of CU that fixed this issue.

The three settings are described in KB 3123752 as

There are three possible values for this property:

  • Undefined: This is the default value. It keeps the behavior the same as before you applied this hotfix in order to maintain backward compatibility.
  • True: Forces the map to use XslTransform behavior. This value overrides any other settings in the BizTalk Server environment.
  • False: Forces the map to use XslCompiledTransform behavior. This value overrides any other settings in the BizTalk Server environment.
GridProperties

Use XSL Transform grid property

So why would you want to use XSLTransform versus XslCompileTransform?  Prior to BizTalk 2013 all the maps used the XSLTransform API, with BizTalk 2013 this was changed to use the XslCompileTransform API.  One of the reasons for the change to XslCompiledTransform is for improved performance in mapping as explained in the blog
BTS2013 features explained: XslCompiledTransform, so great, faster performance, what is not to like?   Unfortunately it also caused some issues with inline C# Scripting Functoids, the underlying cause and issues are detailed in The biggest change in BizTalk 2013 and how to undo it, but what it boils down to is that if you tried passing a Boolean value into a C# Scripting Functoid it would always treat it as True.  The latter blog also details a registry setting that allows you to revert to XSLTransform via a registry setting.

It is also possible to configured the BizTalk 2013 Transform Engine to use the older XSLTransform class. This approach is not recommended since the environment will lose the many performance and memory usage improvements provided by the XSLCompiledTransform class. This change can be made by adding DWORD UseXslTransform with value 1 at the following locations:

So time to do some testing.

I created a map where I use the Logical String fuctioid (1) to check to see if the Phone number in the incoming schema is blank or linked to a Scripting functoid (2) with the below code and link it to the destination schema field ScriptingBool.

public string IsStringTest(Boolean isString)
{
 if (isString) 
 {
 return "Yes";
 }
 else
 {
 return "No";
 }
}

Then I copied that Scripting fuctoid (3) and changed the code to accept a string parameter instead of a boolean one and linked that too ScriptingString field.

public string IsStringTest2(string isString)
{
 if (isString=="true") 
 {
 return "Yes";
 }
 else
 {
 return "No";
 }
}

And just for good measure added the same logic using mapping functoids (5 & 6) and a Not functoid (4) and linked them to MappingFunctoids field.

So after that the map looked like.

XSLTransform

Testing Use XSL Transform

So then I created a sample input with two records, one with a Phone Number the other without and tested the map in Visual Studio and below is the output with the setting of Undefined.

<ns0:Root xmlns:ns0="http://Scratch.Schema1">
 <Record>
 <Phone/>
 <ScriptingBool>Yes</ScriptingBool>
 <ScriptingString>No</ScriptingString>
 <MappingFunctoids>No</MappingFunctoids>
 </Record>
 <Record>
 <Phone>12344</Phone>
 <ScriptingBool>Yes</ScriptingBool>
 <ScriptingString>Yes</ScriptingString>
 <MappingFunctoids>Yes</MappingFunctoids>
 </Record>
</ns0:Root>

As expected the ScriptingBool always contained a Yes and the other two fields contained No and Yes as expected. Then I set the property to False and re-tested and got the same result.Finally I set the property to True and tried again, and here unexpectedly, I still got exactly the same results.

So then I created copies of the map, MapXSLTransform.btm with it set to TrueMapXSLTransformFalse.btm with it set to False and MapXSLTransformUndefined.btm with it set to Undefined. I then deployed this to BizTalk and configured a receive port with three send ports listing too it, each with the different map and dropped a file through. This time for the True I got the results I expected as below.

<ns0:Root xmlns:ns0="http://Scratch.Schema1">
 <Record>
 <Phone/>
 <ScriptingBool>No</ScriptingBool>
 <ScriptingString>No</ScriptingString>
 <MappingFunctoids>No</MappingFunctoids>
 </Record>
 <Record>
 <Phone>12344</Phone>
 <ScriptingBool>Yes</ScriptingBool>
 <ScriptingString>Yes</ScriptingString>
 <MappingFunctoids>Yes</MappingFunctoids>
 </Record>
</ns0:Root>

In conclusion

The only reasons to Use XSL Transform is if you are migrating a lot of maps and don’t have the budget or time to check and fix the issue in the Scripting Fuctoids.

Reasons not to use XSL Transform

  1. You might decrease performance and increase memory usage.
  2. You can’t test the maps in Visual Studio

Update:  In the New Capabilities – BizTalk 2016 CTP1.pdf it has the following

  • There are 3 possible values: Undefined, True and False
    • Undefined means registry flag for XslTransform setting is honored
      (For 64 bit BizTalk host instances: HKLM\SOFTWARE\Microsoft\BizTalk Server\3.0\Configuration
      For 32 bit BizTalk host instances and Visual Studio’s Test Map functionality: HKLM\SOFTWARE\Wow6432Node\Microsoft\BizTalk Server\3.0\Configuration)
      Or else, it defaults to XslCompiledTransform )
    • True means, that the map level compilation property is set to XslTransform (Legacy)
    • False means, that the map level compilation property is set to XslCompiledTransform.

This means that the default value of Undefined is subject too registry settings that are server wide.  If you want to avoid maps breaking when someone decides to change this registry setting you may will want to set this to False during development except for those maps that do need XSL Transform (set to True).

Advertisements