BizTalk Mapper–Inline XSLT Templates–Tracking Profile Editor Limits

Hi Guys,

I hit a limit with the Tracking Profile Editor where I needed to tracking aggregate results from repeating fields in the incoming message within an orchestration. So I decided to try edit the .btt file directly and see if I can fool the BTTDeploy command. However it did not work, it detected my XPath was too fancy and rejected it. Since you can edit .btt files and get away with some minor fancy xpathing.

So the solution was to create an intermediate message to serve as the profiling message source. Hence an orchestration that has an additional construct shape that BAM profiling can consume.

As usual, the BizTalk mapper makes a mess of things when you want to loop through records and frankly I was not in the mood to use the Table Extractor/Looping “functoid” for simple sums. So Inline XSLT here we come.

In fact 90% of my time I will opt for xslt than the biztalk mapper, purely due to the mapper is reserved for very simple mappings. XSLT’s are by far easier to read than the BizTalk Mapper when it comes to complex conditions.

So, below is a message constructed that BAM TPE can consume easily without hacking the .btt file.

image

It is a bit odd to create a message that does nothing in the orchestration at first look, but it serves as an invaluable source of information for BAM profiling.

I opted for a BizTalk Map to create the BAM message, to keep maintenance of schema’s visible and no dirty XmlDocument.Load statements in the orchestration Smile Yes you know who you are!

Here is the sample MAP that takes input message and creates a BAM message for TPE to consume:

image

The Scripting Functoids will then have the following for calculating Annual Sums.

Notice that Param1 is the Input element relative to the Script Functoid, this is usefull, so I can grab a subset of the xml data to pass into the scripting functoid, in this case Benefits.

<xsl:template name="AnnualTotalPremium">
<xsl:param name="param1" />
    <xsl:variable name="Premium" select="sum(//*[local-name()='Premium' and namespace-uri()='urn:Romiko.Submission']) * 12" />
 <xsl:element name="AnnualTotalPremium" >
          <xsl:value-of select="$Premium"/>
 </xsl:element>
  </xsl:template>

Below is a more interesting one that takes record counts as a second parameter for average benefits per policy premium.

<xsl:template name="AveragePolicyAnnualPremium">
<xsl:param name="param1" />
<xsl:param name="param2" />
    <xsl:variable name="Premium" select="(sum(//*[local-name()='Premium' and namespace-uri()='urn:Romiko.Submission']) * 12) div $param2 " />
 <xsl:element name="AveragePolicyAnnualPremium" >
          <xsl:value-of select="$Premium"/>
 </xsl:element>
  </xsl:template>

So, I hope this inspires anyone needed to collect data for BAM that is a bit too more for TPE to handle and you do not want to implement custom BAM Interceptors.

Advertisements
Uncategorized

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s