BizTalk Server Best practices, Tips, and Tricks: #15 Using External Custom XSLT files

Published on : Apr 5, 2023

Sandro

Author

Welcome again to another BizTalk Server Best practices, Tips, and Tricks blog post! In my previous blog posts, I discussed some essential tips and tricks for BizTalk Server administrators:

And for BizTalk Server Developers:

Today I will speak about another critical Best practice, Tips, and Tricks, this time for BizTalk Server developers: Using Custom XSLT files inside your BizTalk Server maps.

#15 Using External Custom XSLT files

Personally, I’m not a big fan of using External Custom XSLT files for solving a mapping problem, and I do try to avoid implementing this strategy, except if:

If you are dealing with a huge message and High Performance is one of the primary requirements – and even then, this maybe can be avoided depending on the mapping needs.
Or if you already have an external custom XSLT file provided by another team or from another system that you can reuse in your map. If the wheel is already invented, why try to reinvent it?

You will always find people that may argue that XSLT automatically generated code by the BizTalk mapper compiler cannot perform as well as the personal Custom-XSLT code! And yes, I agree with you, but in most cases, the performance difference it’s ridiculously low, and it also depends on the approach you are implementing to solve the problem.

The real secret is to find the best of both worlds: BizTalk Mapper and custom XSLT together. I can spend many hours discussing this topic, but you can always know more about this topic in my free book: BizTalk Mapping Patterns & Best Practices.

Biztalk custom XSLT

However, I let you with two statements:

In most scenarios, you wouldn’t really notice too much difference between using the BizTalk Mapper and a custom XSLT file;
I can prove to you that using the BizTalk Mapper properly can have the same performance as a custom XSLT file! (of course, that can always be exceptions)

However, if you are using an external XSLT file, at least you should follow some of these best practices:

Always add your custom XSLT files to the solution

You should always add the external custom XSLT files to your solution, if possible side-by-side with the map (same folder) so that:

They can be easily found.
And they can also be added to the source control and be adequately maintained.

Give it a proper name

Don’t call it ExternalXSLT or CustomXSLTCode. Give a proper name to the custom XSLT file. A name that could easily identify and easily associated with the map.

For example: <name-of-the-map>-XSLTFile.xsl

Add Standard XML Comments inside the External XSLT File

You should add standard XML comments: <!– Comment –> inside the external custom XSLT code.

Whenever you think that it is important to explain little parts of the process/code, you should always add comments. This will help you document the transformation and share knowledge between the teams.

...
<xsl:template match="/s0:Order">
   <xsl:variable name="var:v1" select="userCSharp:GetCurrentDateTime()" />
      <ns0:SAPOrder>
         <OrderId>
            <xsl:value-of select="Orderheader/OrderNumber/text()" />
         </OrderId>
         <ClientId>
         <!-- This is a dummy value, in real scenarios we probably get this value
         from an external system or DB base on the client name-->
            <xsl:text>1</xsl:text>
         </ClientId>
      <Dates>
…

Rename the page grid

If you use an external XSLT file, at least rename the default grid page (Page 1) to a name that draws attention to the fact this map is using an external XSLT file, for example:

ThisMapUseAnExternalXSLTFile

At least this way, a new BizTalk developer or an inexperienced developer can easily read and understand that this map uses an external custom XSLT file.

Stay tuned for the following BizTalk Server Best practices, Tips, and Tricks.

Back to Blog