integrating your business

In an XSLT mapping I wanted to convert the node with its child nodes to a node with attributes. 
I noticed that the source schema contained more than 60 child nodes and most of them could be optional. The transform of this mapping would result in a big piece of code for some logic that perhaps could be made in a better way.

This process could be optimized by creating the attributes in a dynamic way. 

For illustration, I am using this small piece of XML:

<Contact>
	<Name>Reception</Name>
	<Phone>+32 9 247 32 65</Phone>
	<Mobile>+32 475 36 45 78</Mobile>
	<Fax>+32 9 247 32 66</Fax>
	<Email>reception@company.be</Email>
</Contact>

This is the desired output:

<Contact Name='Reception' Phone='+32 9 247 32 65' Mobile='+32 475 36 45 78' Fax='+32 9 247 32 66' Email='reception@company.be' />

The Problem

I am looping through each child node with the query Contact/* (there is no namespace for simplicity reasons). The function name() is able to give the name of the node. I store this name in the variable $attributeName, for later usage.  When we know the name of the current node, this should be easy to create an attribute dynamically:

<Contact>
    <xsl:for-each select="Contact/*">
            <xsl:variable name="attributeName" select="name(.)" />
            <xsl:attribute name="$attributeName">
              <xsl:value-of select="'value'"/>
            </xsl:attribute>
         </xsl:for-each>
     </xsl:for-each>
</Contact>

Although, it is impossible to define special characters in the name parameter of the attribute definition.
Visual studio gave me the error “the ‘$’ character, hexadecimal value 0x24, cannot be included in a name.”  

The Solution

The name argument is not able to perform a query or do some piece of logic. This problem can be solved by working with attribute value templates. Attribute value templates will evaluate the expression and convert the resulting object to a string.

I replaced $attributeName with {$attributeName}

This is the final result:

<Contact>
    <xsl:for-each select="Contact/*">
            <xsl:variable name="attributeName" select="name(.)" />
            <xsl:attribute name="{$attributeName}">
              <xsl:value-of select="'value'"/>
            </xsl:attribute>
         </xsl:for-each>
     </xsl:for-each>
</Contact>

 More information about attribute value templates can be found on the website of W3C.

Additional Notes

The same trick can be used to create elements in a dynamic way in XSLT or for using variables in arguments.
Note that when the source schema will be changed and some child nodes are added, this mapping will also add those attributes, even if this is unknown by the destination schema. This can be positive or negative.

One of the most asked change requests seems to be changing a part of a schema accompanying the modification of a mapping. Since a mapping from BizTalk can be made in the BizTalk mapper or in XSLT, it is always a bit of a surprise, how difficult this can be. It is interesting how the translation of The BizTalk mapper is done under the hood and how we can improve the performance. In this article I will concentrate  on the cumulative concatenate functoid found when working with the BizTalk mapper.

Project sample

An external schema contains a report about orders that have been processed. Each order line contains a validation code.
In our internal schema, we would like to use one node to know if the whole order has been processed or not. We can solve this by using the looper functoid, but in this case I will use the Cumulative concatenate functoid. 

The BizTalk mapper 

First we cumulate all the status values using a cumulative concatenate, afterwards, a find functoid will tell us if there is a status "NOK" (not ok) is present. Then we will determinate depending on the index if the status will end up in a true or false. This is a piece of cake.
 

The change

The change regarding this mapping, which should now be extended, the external schema can now have multiple statuses that tell us if a line has not been processed. ("NOK","NIS", "NA").  I won't implement this change, but I will concentrate in how to keep this mapping clean. 

Using an external xslt file

I will use an external XSLT schema for applying this change. It seems to be that if we will use another few functoids, our mapping will become a big mess. I simply generated an XSLT  from the existing mapping by right clicking the map in the solution explorer and selecting "Validate map". BizTalk will output two links, one of them will be the XSLT file. Save this file to disk and and refer from the mapping property "Custom XSLT Path" to the external XSLT file.

The first thing that strikes me is the fact that this XSLT file is nearly unreadable, or at least difficult to understand.

Under the hood, BizTalk is using at least one variable for each functoid you use. Since we cannot change the values of a variable in XSLT , BizTalk uses a script block with inline c# code at the bottom of the document for cumulating each value of the node Status.

 This is the generated code for the IsValid node. 

<xsl:variable name="var:v1"
select="userCSharp:InitCumulativeConcat(0)" /> 

Initialize the Cumulative array: The 0 refers to the fact that this is the first cumulative concatenation we are using in our mapping. This is the Key for our cumulative concatenation function. On that way, we are able to reuse the c# code multiple times again.

<xsl:for-each select="/s0:ExtOrderReport/Lines/Line">
        <xsl:variable name="var:v2" select="userCSharp:AddToCumulativeConcat(0,string(Status/text()),'1000')" />
</xsl:for-each>

Loop for each node we would like to concatenate, and give the value to the function "AddToCumulativeConcat". Note that we also use the 0 here.

<xsl:variable name="var:v3" select="userCSharp:GetCumulativeConcat(0)" />

Ask to the c# code to get all our values (again with the key 0)

<xsl:variable name="var:v4" select="userCSharp:StringFind(string($var:v3) , 'NOK')" />

Find a "NOK" value and returns an index result.
 

<xsl:variable name="var:v5" select="userCSharp:IsValidOrder(string($var:v4))" />
<IsValid>
	<xsl:value-of select="$var:v5" />
</IsValid>

Call our internal c# code to decide if this order is valid or not. 

Optimalizations

This seems to be a lot of code, for such a piece of logic, isn't it?

We might could manual optimize this, for performance reasons: 

<xsl:variable name="var:v1" select="userCSharp:InitCumulativeConcat(0)" />    
  <xsl:for-each select="/s0:ExtOrderReport/Lines/Line/Status"> 
      <xsl:variable name="var:v2" select="userCSharp:AddToCumulativeConcat(0,string(text()),'1000')" />   
   </xsl:for-each> 
     <xsl:variable name="var:v3" select="userCSharp:GetCumulativeConcat(0)" />    
  <IsValid>       
 <xsl:value-of select="not(contains($var:v3,'NOK'))" />  
    </IsValid>

I limited the for-each function only to the node we need, in that way, we only need to loop this node, not the whole line node.

I replaced the c# search function by the build in XSLT search function, since built-in functions are always faster than loading custom c# code.

After that, I limited the variables were possible. 

XML profiling

After this manually intervention, I would like to know what the result is of my improvements.

Visual studio offers by default XML profiling. When comparing these results, I could say that we did an improvement of nearly 50%

Conclusions

For long term maintenance reasons it is smarter to write your own xslt, and not use the built-in BTM (BizTalk mapper).

It's always possible to convert convert a BTM to an XSLT.

The BTM might be fast for easy mappings, but even for this, BTM will always generate a less readable and less performance XSLT file.

You can manually improve the mapping speed by yourself.

Yesterday we discovered something about the use of custom extension objects in custom XSLT.
Imagine that you need a counter value in your mapping. Since variables in XSLT can only be set once, you need to use custom code for this.
In our case we wrote a small helper class that has a counter variable.

public class Counter
{
    private int _counter = 0;

    public int GetCounter()
    {
       return ++_counter;
    }
}

I just called this in my map and tested it. It worked perfectly.

But then I fired a few concurrent calls to our BizTalk process, resulting in the map being executed multiple times in a very small time frame.
We noticed that the counter value wasn't correct anymore. After some analisys it seemed like the instance of the Counter class was shared over multiple executions of the map.
Our assumption that BizTalk creates a new instance of the class every time the map is called, was wrong.

We came up with a quite simple solution for this. Instead of just having 1 counter, we created a Dictionary that can hold multiple counter values.
The key for this Dictionary is a Guid (as string) and the value is the actual counter. Each map has it's own Guid that makes it unique.

public class Counter
    {
        private Dictionary _counter;

        public Counter()
        {
            _counter=new Dictionary();
        }

        public string NewGuid()
        {
            return Guid.NewGuid().ToString();
        }

        public int GetCounter(string guid)
        {
            return ++_counter[guid];
        }
    }

So this is how our class looks like with this Dictionary. At the top of your map you just create a variable that holds the Guid, and you use it every time you call the GetCounter method.

<xsl:variable name="Guid" select="Counter:CreateGuid()"/>

<xsl:value-of select="Counter:GetCounter($Guid)"/>

 We are still not quite sure how long BizTalk keeps this in memory. But to be sure we added a method to the class that deletes one row in the Dictionary at the end of a map.

 Tim D'haeyer, CODit