Yossi Dahan [BizTalk]

Google
 

Monday, August 15, 2005

Calling .net assemblies from custom xslt

It shouldn't have, but it took me a while to figure this one out, so for the small chance I can shorten the process to someone else I've put this here.

If you've read my previous post about custom xslt you know by now that I'm doing more and more custom xlst work rather the standard drag-this-to-there mapping. (you also know that by far I'm not an xslt expert so feel free to comment on this post)

I've been doing this succesfully for a while but then I got to a point that I needed to call a custom .net component I've developed from inside my xslt.
(This is a configuration component, by embedding it in my xsl I can avoid putting static data inside my map that may change in the future - for instance when moving to production)

I've had experience with calling assemblies from a map using the scripting functoid in different ways, but until now did not need to do so from custom xslt.
I found out that the way to do it is exactly the same way you'd do it when calling from a custom xslt script functoid.

First I've created an ExtensionObjects xml from the example in the ExtendingMapper SDK sample - this xml defines the objects that will be called from the xslt - assigning a namesapce to a stongly named assembly and specifying which class should be called.

The sdk samle for this file looks like this:

<ExtensionObjects>
<ExtensionObject Namespace="http://myScriptorAssembly" AssemblyName="Microsoft.Samples.BizTalk.ExtendingMapper.MapperClassLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f2aaad746c3d94f5" ClassName="Microsoft.Samples.BizTalk.ExtendingMapper.MapperHelper"/>
</ExtensionObjects>


This xml is saved and then the map's Custom Extension XML property points to it.

To call the xslt I followed closely the exapmle in the ExtendingMapper sdk sample project, there's a map named Scriptor_InlineXsltCallingExternalAssembly.btm that shows how to call an assembly from inside an xslt script functoid, what I found out (which now seems so obvious of course) is that it is exactly the same approach only in my custom xslt rather then in a script functoid.

In my xslt I created a variable and assigned to it the return value of the call to a public method in the class specified in the extension object xml:

<xsl:variable name="v1" xmlns:myScriptPrefix="http://myScriptorAssembly" select="myScriptPrefix:myConcat($param1, $param2)" />


myScriptPrefix is as alias pointing to the same namespace as defined in the extension xml. and then myConcat is a public method in the class configued.

After that poit I can then use <xsl:value-of select="$v1"/> to get the result of the method call.

Very simple indeed, and nothing that is not already in the sdk only that I'm not using any links and functoids on the map but custom xslt file.

I don't know if it possible to call .net assemblies in xslt outside BizTalk but this is a very nice example of how even when you decide to resort to custom xslt to get more flexibility you can still use the great features provided by the BizTalk engine.

3 Comments:

Post a Comment

<< Home