Someone pointed out the other day that I had not made a blog entry for quite some time and the last one I did actually write was simply to inform the World of some neat new site that provided a consolidated property for sale on a map service.
Yes, I agreed. What with the entire furore over the Ready To Go “release” of SQL 2005, Visual Studio 2005 and BizTalk 2006 there were plenty of other people out there blogging about BizTalk 2006 who are a lot closer to the action than I am – the product team for one. I will leave it for them to discuss what this occasion means to us all, if anyone that reads this blog occasionally doesn’t actually know.
So there was no point in me writing about that, what about the BizTalk 2006 work I am currently involved in? Well, there is nothing ground breaking there either. It has been a time of migration really, simply attempting to move some functionality written in BizTalk 2000 into 2006. This has involved attempting to use new functionality provided by 2006, but eventually meant writing a custom adapter and (at present) a rather business process heavy map. This is not a project whereby you have much leeway to change the boundaries unfortunately.
The custom adapter was an interesting exercise in that it meant I spent more time on writing one of these. In the past I had obviously written some prototypes, but the only time the client had actually required a custom adapter to be written I had been spending a considerable time on scalability testing – not something that tends to be a quick exercise, believe me.
I have to admit that once you have got your head around the conceptual information about adapters and then decided to download the Adapter Wizard along with the excellent documentation bundled in everything fits into place quite quickly. Note that this version is for BizTalk 2004; you simply have to start the wizard in an old version of Visual Studio and then convert. There are obviously some guidelines you should follow when constructing an adapter and it just so happens that there is some useful information available here.
Aside from custom adapters I have also started to write some maps that are purely XSLT and make calls to external .NET assemblies. Again, nothing here that is BizTalk 2006 specific and hence the lack of blog entries. I am sure there are plenty of other posts out there that cover both of these topics in great detail, so I will not try to replicate here. Suffice to say this was the first time I had written XSLT directly to call an external assembly and found the experience, well, pleasant! It worked first time and did exactly what I expected. The trick is to make sure you set-up the “Custom Extension XML” and “Custom XSL Path” properties on the map correctly and then writing the custom extension XML an example of which is shown below:
<ExtensionObjects>
<ExtensionObject Namespace="MyNameSpace Here" AssemblyName="MyAssemblyNameHere, Version=1.0.0.0, Culture=neutral, PublicKeyToken=MyPublicKeyTokenHere" ClassName="MyClassNameHere" />
</ExtensionObjects>
My only gripe at present is related to the current XSLT spec whereby there does not appear to be a formal way of converting a result tree fragment into a node list. I know of means to achieve this using MSXML, but considering that this does not follow standards (and dropped) it would not be the sensible way forward. If anyone out there has any idea on how to achieve this I would be more than receptive.
The only thing directly related to BizTalk 2006 is that if you do happen to write on of these assemblies that get called from XSLT and you test it using the “Test Map” option in Visual Studio, it appears that you must close and restart Visual Studio each time for any updates to the assembly to take effect. Now I haven’t tried to replicate this in BizTalk 2004 and I haven’t upgraded from the beta 1 version of BizTalk 2006 on my development machine yet. So I am not sure if this is actually an idiosyncrasy since 2004, has been fixed in a later release or a genuine bug. Microsoft are looking into it for me, but it is merely an irritant.
Anyway, until next time…