How to stop applications from unloading inBizTalk 2004

Recently we developed a time sensitive BizTalk application where a simple set of processing steps were invoked via a web service.

The external calling application (the application calling the BizTalk process) had just 5 seconds to complete its task. Since the BizTalk part was not very complex or resource intensive, we were achieving response times of 1 second, well within the 5 second margin.

During testing, though, we were getting intermittent timeouts because the BizTalk application was unloading itself from memory and causing the calling application to timeout. Basically it took more than 5 seconds for the unloaded BizTalk application to start itself up again and caused a failure.

BizTalk relies on a configuration file to store its application information. This config file contains settings for unloading an application from memory and is located at \Program Files\Microsoft BizTalk Server 2004\BTSNTSvc.exe.config. Full documentation can be found at Microsoft’s website but here is a working example you can download.

By default BizTalk has 2 shutdown settings which are:

SecondsIdleBeforeShutdown = 1800 (seconds, or 30 minutes)
SecondsEmptyBeforeShutdown = 1200 (seconds, 20 minutes)

The link below is a sample config file that never shuts down. We are isolating these “hot” processes on a separate server from the “cold” processes (processes that can safely unload). You can run hot and cold side by side as well but that requires more changes in the config file. If you set the SecondsIdleBeforeShutdown and SecondsEmptyBeforeShutdown to -1 they will always stay in memory.

Note that this is increasing the load on the server but for time sensitive situations this could save you a rash of intermittent errors in production. Note also that you shouldn’t do this unless you really need to, unloading saves resources and with most integration scenarios the few seconds it takes to start up are minor.

You can backup your current file, download this BTSNTSvc.exe.config zip file and extract it, then stop and start your BizTalk host to see it work.

Fully qualified name differs for XSD’s withmultiple root nodes in the Business Rules Engine

One of the most common problems that exist when using the business rules engine is forgetting to use the fully qualified name from a schema in definition of the rule.

Posts like this on Google Groups can clarify what I mean if what I am talking about is not clear.

I have discovered something new regarding the fully qualified name which caught me out this morning and I thought I’d mention it here in case you have the same problem.

If you are using the fully qualified name of a schema with multiple root nodes in the BRE, the fully qualified name must include the name of the root node. When you go to your orchestration and try to feed a rules shape your XSD you will find it won’t recognize it (no drop down appears).

For example you can have a schema with multiple root nodes with a fully qualified name such as schma_name_fully_qualified which, with a single root node, would work just fine. But if the schema has multiple root nodes you must append the specific root node to this qualification for the orchestration to recognize the rule.

So if you had the fully qualified name schma_name_fully_qualified, look at your orchestration view, click on the message you are using and look at the message type: you will find that you must use something like schma_name_fully_qualified.header to properly identify the schema when creating your business rules. Changing this should then allow you to select a message type in your orchestration.

"multiple schemas match the message type"may be caused by web services

I was stuck recently with what seemed like a pair of contradictory errors.

I had an application deployed which was exposed as a web service. To test the application we built a test harness which picked up a flat file and called the web service for us and then dumped the result on the file system to see the result.

This testing system worked fine until I needed to use that same deployed schema to do some additional messaging. I wanted to route a message via a receive port and have a send port subscribe to it, then map the message to a new format and deliver it to a destination. Pretty simple, right?

Well, no. When I have my project deployed I got the following error when routing:

There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive" Source: "XML disassembler" Receive Location: " D:\dat\FileReceive\RoundTrip\*.xml Reason: Cannot locate document specification as multiple schemas match the message type "http://BO.Get.EV2#Method".

That error left me scratching my head. It means I probably have the schema deployed twice, right? I didn't, so I thought. When I undeployed the application the messaging engine could no longer match my message type:

There was a failure executing the receive pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive" Source: "XML disassembler" Receive Location: "D:\dat\FileReceive\RoundTrip\*.xml"
Reason: Finding document specification by message type "http://BO.Get.EV2#Method" failed. Verify that the schema is deployed properly.

When I deployed the project with the schemas, everything suddenly worked fine. That means that, somewhere, the schema was again deployed.

So I looked thru the BizTalk Server Assemblies viewer and discovered that the web reference which existed in my test harness was the culprit. The messaging engine recognized the web reference as a second deployment of my schema. This was technically accurate but rather frustrating to find. I've seen so many of these errors posted on the newsgroups that I thought I'd mention this as a possible cause.

If you are using test harnesses coupled with web services be aware that your schema is actually deployed twice.

Easier way to add a DLL to the GAC

Often in BizTalk you’ll need to add assemblies to the Global Assembly Cache. In the past I had used a shortcut on my Quick Launch toolbar which opened the GAC, then I’d drop the assembly inside, but there is an easier way.

A registry key can be created which allows you to right click the DLL and “GAC it” in one click.

The text for the key is below; simply copy/paste it into notepad and save it as a registry file (.reg). Then double click the file to add it to the registry.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\dllfile\shell\gacutil\command]
@="c:\\windows\\Microsoft.NET\\Framework\\v1.1.4322\\gacutil.exe /i \"%1\""


You can also download the Gacutil right-click key as a zip file here.

BizTalk exception handling with web services

Recently I needed to include exception handling in a web service call to an external party. I learned a couple of things and thought I’d highlight them here.

Exception handling doesn’t always behave the way you expect when you are trying to catch exceptions when calling a web service. While using one is very useful some things must be considered or you will not get the result you wanted.

Here is one way to do it as well as a few things to keep in mind when you want to set one up:

• Include the external web service call (both send and receive shapes) in either a non-transactional scope shape or a long running transaction.
• Decide if you need to catch any specific exceptions, if you don’t, using the General Exception will suffice. If you need to catch specific errors, you can use multiple catch exception blocks.
• It may sound obvious to say this, but make sure your orchestration doesn’t have a timeout that is the same length (or shorter) than the timeout of your scope transaction.
• Most important: in your send port which holds the reference to the web service, make sure you are not using any retries (unless, of course, you explicitly need to). If the web service fails with an error such as “There is an error in XML document (5, 10)” and you have retries enabled you will only see warnings in your event viewer (which means the exception block won’t be activated until the SOAP timeout).

Solving BizTalk "error X2044"

I encountered a strange compilation error recently in BizTalk 2004 when importing a web service.

While I can’t put my finger on the exact cause yet, I do have a fix that works.

When you see an error message like:

C:\Project\Web References\ExtRef\MyOrch.odx(445,23): error X2044: symbol '@@@@' is already defined; the first definition is in assembly @@@.dll : It may be possible to disambiguate by using fully qualified names.

The way to fix this error is to do the following:

• Open the orchestration in Notepad (In my case MyOrch.odx)
• Do a find (Ctrl+F) for “#endif // __DESIGNER_DATA”
• Delete all the code below that line
• Save your file in Notepad
• Say yes when Visual Studio asks if you want to update your file
• Recompile

Note: The code will not be regenerated until you edit an expression shape, etc. Add a “//” or something and you will then see the code re-appear when you open it in Notepad again.

I hope this may serve to save someone time, it took a while for me to figure it out.

Passed the BizTalk 74-135 certification

Randal and I have passed the BizTalk Server partner exam (74-135) "Developing E-Business Solutions Using Microsoft BizTalk Server 2004". It, as many have commented, was a rather difficult exam that has no real preparation materials to help get thru it.

For anyone interested in taking the exam it's recommeneded that you have lots of hands on experience with BizTalk.

Please note, this exam is designed for Microsoft Certified Partners, so unless you work for such a company the exam is not available.