BizTalk 2004 to 2006 Upgrade XSLT issue

I have been working on a BizTalk 2004 to 2006 upgrade and encountered an interesting issue when testing. It was an XLANG error with the relevant part of the error message log being:


Unable to cast object of type 'MS.Internal.Xml.Cache.XPathDocumentNavigator' to type 'System.Xml.IHasXmlNode'


The reason for this is that in one of the XSLT maps there was some custom c# code that made a cast. The cast involved the XPathDocumentNavigator class from the System.Xml.XPath namespace. The XSLT engine loaded the version in MS.Internal.Xml.Cache first.

To fix this issue I just made sure the references to XPathDocumentNavigator were fully qualified.

The lesson learned was that it always pays to fully qualify your references to classes in embedded .net code in XSLT.

HAT Query Problem: 'ActiveView.ColumnAxis'

If you receive an error message when running a HAT query that looks something like this: "The following error occurred while executing your query: 'ActiveView.ColumnAxis' null or not an object" then chances are that you don't have the Office Web components (OWC) available here or here.

Promoting Context Properties

Sometimes there is a context property on a message in BizTalk that for some reason by default does not get promoted. If you want to route the message based on this property (say in a send port), then follow these steps:


1) Create a Correlation Set and Type based on the property you want to route by in your orchestration.

2) In the Send Port properties that sends the particular message you want to route, set the Correlation Set to initialise. This is achieved through Orchestration Designer.


I found out step one via this Addictive News post. Step two is there for clarification.

There is also a custom pipeline component available that allows a bit more dynamism.

BizTalk Scripts

There is a fantastic resource for various vb scripts for BizTalk admin and development tasks that can be found at gotdotnet.

Some of the scripts could be very handy for prepping a prod/preprod/test server for deployment.

A Simple Yet Deceptive Trap

This is something that caught me today. It seems like a pretty simple thing, but had me frustrated for about fifteen minutes.

When compiling a BizTalk project with orchestrations enclosed you may occassionally get a "cannot find symbol" or "invalid reference" message when compiling. This seems like a simple enough problem, just reload your references and things should be fine?

Well occassionally we make silly mistakes. In this instance it turns out that I did not put double quotes around the value propertyof an orchestration variable. It turns out the Intial Value property of an orchestration variable is a live property in that it accepts referernces to objects and other variables. So if you want just a string literal you need to explicitly make Visual Studio aware that what you are entering is a string (quotation marks).

Of course it may be better to design your solution so that the initial value property is pulled from a variable elsewhere, perhaps in an XML file or database somewhere instead of hardcoding inside your orchestration!

Tech Ed 2006 Retrospective, Windows Server 2008

It was still called longhorn back then, but essentially the same product.

So Tech Ed 2007 has just been and gone, which I sadly missed, but I'd like to share a little bit of belated news about last years festival.

One of the tidbits that the evangelists and gurus from Microsoft told us in Sydney was that apparently everything you can do in a GUI you will be able to do from the command line.

Take a moment to let that sink in.

Coming from a systems integration perspective, that is pretty great news. Some of the more recent projects I have been working on require some fairly complex deploy operations. SQL Server databases, DTS pacakges, various BizTalk artifacts, .NET assemblies to be gacked and lots of security settings. This has the potential to simplify things grandly.

If anyone has any thoughts on this please leave a comment.

BizTalk Large Posters from Microsoft

Microsoft have provided some great BizTalk posters to print out. The BizTalk Server Team Blog has the low down.

Oracle Import Error: Could not validate configuration of Primary Transport of Send Port

I have been attempting to import some binding information for a BizTalk application I've been working on for a couple of weeks. The specific problem has to do with the OracleDB adapter bindings.

When I tested out my deploy script on the test servers I received an error quite similar to this:


TITLE: Import Error

Failed to import "pathtomsifile".
Location of the log file is provided in the Results page.

ADDITIONAL INFORMATION:
Change requests failed for some resources. (mscorlib)

Unable to process create change request for BizTalk binding "BindingInfo.xml". Import bindings (overwrite) failed. (Microsoft.BizTalk.ResourceManagers)

Failed to update binding information. (mscorlib)

Could not validate configuration of Primary Transport of Send Port 'portname' with SSO server.
Specify user name and password (Microsoft.BizTalk.ExplorerOM)

Specify user name and password (Microsoft.BizTalk.ExplorerOM)


A solution to this can be found here. A later verson of Microsoft.biztalk.adapters.bizutil.dll is required in the GAC than the one I had! It needs to be dated 14th Sept 2006 or later.

BizTalk Server Pattern Wizard

Available here is a freeware type tool called the BizTalk Server Pattern Wizard. It claims to help capture and reuse your BizTalk projects best practices.

Oracle Adapter Error

Was running into an issue with the Oracle Adapter that comes with the "Microsoft BizTalk Adpaters for Enterprise Applications" bundle. At run-time event log was reporting three errors messages, including "Runtime Error : Unable to load DLL (BAUtil.dll)."

After a bit of googling I found the following solution on the Microsoft Knowledge Base site.

This solved the problem, however it may be worth noting to check the security settings for the "C:\Program Files\Common Files\Microsoft BizTalk Adapters for Enterprise Applications" folder. You need to make sure the BTS host(s) that will be utilizing this adapter have Read/Write permissions there.

Deploy Failed, "A file load exception occurred while attempting to install the assembly into the Global Assembly Cache."

Occassionally when deploying a BizTalk resource from Visual Studio you will receive the following error message:


Error 16 Failed to add resource(s). Change requests failed for some resources. BizTalkAssemblyResourceManager failed to complete end type change request. Unable to install the "C:\Documents and Settings\foc18bs\Local Settings\Temp\BT\PID1188\BizTalkAssembly\c94a039fff06502b4de07ec61b983b9c\EPS.Schemas.dll" assembly into the Global Assembly Cache.
Exception: A file load exception occurred while attempting to install the assembly into the Global Assembly Cache. This error may occur if the assembly is delay signed, or if assembly was renamed after creating/signing.


I encountered this problem today and after a bit of exploring found out that it was happening because the assembly in question was still in use by a process. Sometimes it can get difficult to track down what process is using the file so I consulted the free Microsoft utility, Process Explorer and found out that some mmc process had a handle on it.

I killed all the non devenv processes that had a handle on the dll. I was then able to successfully redeploy.

Edit: You may have to kill some of the handles that devenv.exe has as well. Spefically those that have a handle on the instance of the dll in the GAC directory.

Multiple Hosts on a Single BTS Server

Some of you may have come across the BizTalk Server Best Practices Analyzer. You can run this tool against a BTS server and it will spit out a quite verbose listing of currently existing configuration issues and helpful recommendations.

One of the more interesting recommendations it makes is about the use of multiple hosts. Using a separate host and host instance for receive ports, send ports, tracking and orchestrations allows for some significant flexibility. From an infrastructure point of view it makes upgrading your single machine installation to a multi-machine or farm a far easier task. There should be performance increases as you are separating the workload amongst a group of processes instead of one. A discussion is brewing over at topxml.

Debatching

Recently I have been working on a BizTalk project that receives large messages at a fairly regular interval. Whilst BTS 2006 does implement an enhanced messaging engine that touts improvements to transformation carried out on large messages, in practice I have found the increase to be noticeable but not enough when dealing with increased traffic as well.

There is a great article of debatching inbound messages from the sql adapter over at Richard Seroters blog.

If any of you run through this, something that caught me out was not setting the Body XPath attribute on the schema designated as your envelope. This attribute, which is found in the Parse section of the your desired route node tells BizTalk where to start looping for child messages. So if you need to go three or four layers deep before you want to start looping you can get around having to create an intermediary schema by using this. If you don't set this property it is very unlikely that the debatching process will work for you.

Mismatched Hosts, Binding Drama and BTS 2006 Reconfiguration

Recently, for a frustrating reason, I had to unconfigure a BizTalk server located in the development environment at a client's site. Later, when reconfigured, I came accross an interesting error when I tried to redeploy some of the orchestrations:

Error 6 Failed to add resource(s). Change requests failed for some resources. BizTalkAssemblyResourceManager failed to complete end type change request. Failed to update binding information. The following items could not be matched up to hosts due to name and/or trust level mismatches: Item: 'APS.Search.GetChildDetails.Orch_GetChildDetails' Host: 'BTS_APS' Trust level: 'Untrusted'You must do one of the following:
1) Create hosts with these names and trust levels and try again
2) Re-export the MSI without the binding files and have a post import script apply a suitable binding file.

The symptom of my problem seemed basic enough- when the assembly was attempting to deploy to the BTS server it was utilising a prior binding file that was not configured properly to interact with the reconfiguration. I googled and google-grouped the error and came up with nothing. I assume that the binding file is embedded in the assembly somewhere, but where I do not know! What I did work out was how to solve the problem.

Presumably if you googled the error you just want the damned solution, so here it is- changed the strong key associated with the project and rebuild. This seems to remove whatever binding file was associated with the assembly and allows for smooth deployment, all things being equal.

So if you have any idea where this binding file is actually located, please comment as I'd love to know.