BizTalk Web Admin – Part 1

It’s been awhile since I’ve done any BizTalk development since my last project got canceled. However, we are still using BizTalk, and with that comes administration. One of the more tedious tasks is responding to suspended messages. There are a couple of common tasks that I do when I see that a message has been suspended.

• Resume because a destination location that was unavailable is now available (i.e. Customer Web Service)
• Terminate instance because it’s not a critical message and do nothing else
• Terminate instance, then fix and resubmit message

While BizTalk provides the BizTalk Administration tool in BizTalk 2006, which is a much needed improvement over the tools in BizTalk 2004, it leaves something to be desired. What I would like is a web based tool to manage my suspend queue, with some additional logic for filtering messages, so I can quickly determine if I need to terminate or resume. I’d like a web based tool, because I don’t have direct access to the SQL server that BizTalk uses as it’s in a DMZ. A web tool would allow me to manage the suspend queue from anywhere, even from home.

After a bit of searching, I didn’t find anything else out there that fit my exact needs. There was a project on CodePlex that looked like it might have been a good start, but didn’t look like it had suspend queue management (but it did look like it had support for configuring the various artifacts, like ports, orchestration, etc). I decided to write my own, as with most endeavors, it would serve as a good learning experience.

While searching for an already made tool, I found several references to Microsoft.BizTalk.Operations for getting messages out of BizTalk. After playing around for a bit I got something working that returns me a list of suspended messages.

using Microsoft.BizTalk.Operations

...

Operations operations = new Operations("localhost", "BizTalkMgmtDb");
List<BizTalkMessage> suspended = new List<BizTalkMessage>();

foreach(BizTalkMessage in operations.GetMessages().Cast<BizTalkMessage>())
{
  if ((msg.MessageStatus & MessageStatus.SuspendedAll) != 0)
  suspended.Add(msg);
}
return suspended;

I found out that I needed some other Dll’s as well:

• Microsoft.BizTalk.DBAccessor (pulled from GAC)
• Microsoft.BizTalk.Operations (%Program Files%\Microsoft BizTalk Server 2006\)
• Microsoft.BizTalk.Pipeline (%Program Files%\Microsoft BizTalk Server 2006\)
• Microsoft.BizTalk.Tracing (pulled from GAC)
• BTSDBAccessor.dll (non-managed code. Add to project and set to copy to output directory)

Since I’m using BizTalk dll’s that are only available by installing BizTalk sever, I won’t be able to redeploy those, so you’ll have to add them your self and rebuild the project. So yes, eventually I’d like to release the source for this little project.

After I was able to get references to the suspended messages, that left inspecting the messages to get various information, like why it was suspend, and the actual message body, and finally executing the resume or terminate command.

Resume and terminate are really easy, as once you have the message, you can just use it’s InstanceId property and pass it to operations.ResumeInstance or operations.TerminateInstance. Getting the message body is a little more difficult, but not that bad.

public static string GetMessageBodyAsString(BizTalkMessage message)
{
   string body = string.Empty;
   using (System.IO.StreamReader reader = new System.IO.StreamReader(message.BodyPart.Data))
   {
    body = reader.ReadToEnd();
   }
   return body;
}

Ok, so it wasn’t that easy. When I went to run my code I got the following error when trying to access the Message.BodyPart property of BizTalkMessage: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B) – Microsoft.BizTalk.Pipeline. I thought that maybe I had an incompatibility between RTM and R2 versions of the various DLLs. Well, I fixed that but the error persisted. It was at this time I realized that the unmanaged code (BTSDBAccessor.dll), might not be compatible with my 64bit operating system. So I tried running this on a 32 bit box, and got another exception that indicated that I was most likely missing a dependency for BTSDBAccessor. Finally, I ran the code on a 32 bit box that had BizTalk installed, and it worked fine.

So you might be asking yourself, why wouldn’t you run this on the BizTalk box? Well I want this to be accessible via the web, and our BizTalk box does not do any front end web hosting, that is handled my a separate set of machines in another zone. I also wasn’t planning on installing BizTalk on the front end web servers either, so I needed to come up with a work around that avoided a BizTalk install. Using ProcessMonitor, I was able to come up with a list of dll’s that my application was accessing, which I have listed below. These dll’s reside in %Program Files%\Microsoft Biztalk Server 2006 on 32 bit systems, or in a bin64 sub-folder on 64 bit systems. Some of the dll’s need to be registered using regsvr32.

• BTSCache.dll (regsvr32)
• BTSDBAccessor.dll
• BTSErrorHandler.dll (regsvr32)
• BTSMessageAgent.dll (regsvr32)
• BTSPerfCounters.dll
• BTSSchemaCache.dll

So now I have my test app running on a 64 bit install of Server 2008, just like my web front end servers, and I am able to query messages, find the suspended messages, and terminate those messages that are suspended. My next step, and topic of part 2 will be turning this into some type of web based application. I haven’t decided if that will be Asp.Net, Asp.Net MVC, or Win Forms using WCF web services.

UPDATE:

I was having some problems registering the unmanaged DLL’s on another Server 2008 machine (error code 0×80070005), which seems be an access denied error. I should point out that I was using a batch file to register all of the dll’s, which I also tried doing a run as Administrator. That failed, but with a different and even less helpful error message. I eventually opened up a command prompt as an administrator and manually ran regsvr32, and that seemed to work.