BizTalk debugging with DebugView

First of all, happy new year 2008 :D

It's been a while since i did the the last blog.
But now since the current project is in the user testing phase, i guess i can post some articles about the interest things i found lately ;)

Since I moved to the new company, I have been working with BizTalk 2006, Oracle9i. So you will find more things about these 2 in my following posts ;)

Let's start with BizTalk debugging. One thing about developing biztalk application is that we will likely to spend more time in the testing rather than creating the orchestration. And the tricky part of it is that the debugging part is not as easy as we have in other .net application types.

Previously, I worked before with BizTalk 2004 about 1+ year ago, we used the file or event log to dump all the debugging output.
But now, life is much easier since i found DebugView. It will output all the trace and debug into the output window of the tool, which makes easier to debug/trace compared to the other methods (file - have to refresh/reopen the file, eventlog - have to move up and down to see each trace/debug item). And please note that this tool can be used for any type of applications, not only for BizTalk.

Below is the sample flow :
I put several debug / trace in the web application, BizTalk orchestration and the web services.
For example :

System.Diagnostics.Debug.WriteLine(varXMLSOAPHeader.OuterXml, "ConsumeWSOrchestration");

System.Diagnostics.Trace.WriteLine("Finish constructing WS message", "ConsumeWSOrchestration");

As you can see in the debugview screen shot below, it will output each debugging / tracing in the output window when the application is running.

How to decide whether using Debug or Trace?

• Debug : dump everything and as many as you want in the orchestration , such as message content, variables, etc.
• Trace : to monitor the orchestration flow, put the information as simple as possible. For example, we have a decide shape with 3 branches, i will use trace to inform me which branch the instance is actually going into.

Do we have to remove all the debug & tracing manually when deploying the orchestration to production? NO :

1. By default debug & trace will be enabled in the Debug compilation mode, and only trace will be enabled in the Release compilation mode. (you should be able to change this in the project build properties).
2. Make sure that you compile the DLLs with Release mode for production (so the debug symbols will not be included).

Design Consideration :
It will be better if instead of calling the System.Diagnostic class directly, you encapsulate the debug / tracing method with a helper class.

The benefit :

1. Maintainability
2. You can control the behaviour of debug / trace. E.g : add output to other channels such as file, event log

I have a helper class with a static method below which will handle the debug / trace logic

public static void Log(string appName, string orchestrationName, string body, LogType lt)
{
//LogToDebugView(appName, orchestrationName, body, lt);
//LogToEventLog(appName, orchestrationName, body, lt);
LogToFile(appName, orchestrationName, body, lt);
}

So i just need to call the method to debug / trace like this :

Logger.Log("appName", "orchestrationName", "This is a debug", Logger.LogType.Debug);

Normally, in production, we will use file / event log output not the debugview for administrative purposes.

Direct Link to download the DebugView :
http://download.sysinternals.com/Files/DebugView.zip

Overview of DebugView :
http://www.microsoft.com/technet/sysinternals/Miscellaneous/DebugView.mspx

No installation needed, just unzip the file and you are ready to go ;)

Note : Some of my friends got often hang issue with their PC when starting the debugview v4.73, after downloaded and using the newer version v4.74, they haven't encountered any hang issue since then and they are "attached" to the tool like I am :P

**Update : A nice feature of DebugView is Remote Monitoring. This is quite useful to monitor the applications when deployed in the DEV, SIT, UAT servers, so you don't even have to login to the server itself to see the dumps.