Debug BizTalk Orchestration in Production Server
Murphy’s Law: if anything can go wrong, it will. If BizTalk orchestration instance in a production server does not behavior as you expect it, how do you diagnose the problem? Remember, attaching debugger to an orchestration instance is usually impossible in this case.
DebugView is one of my favorite tools for troubleshooting issues in production environment. For many years, I have used it to debug Visual C++, Visual Basic, C#, ASP and ASP.Net web applications. No exceptions, I use it for BizTalk orchestration debug too. The System.Diagnostics.Trace.WriteLine method can be used to output string. Under the hood, it will call Win 32 OutputDebugString method. If DebugView is not enabled, there is no performance penalty. However, this method will hurt performance if you launch DebugView. In case you don’t have this tool, you can download free one here.
Alternatively, the System.Diagnostics.EventLog.WriteEntry method is extremely useful to log trace information. For example, you can insert an Expression shape into your orchestration, then specify Expression.
System.Diagnostics.EventLog.WriteEntry(“My BizTalk Application”, “Call Orchestration”, System.Diagnostics.EventLogEntryType.Warning, 9900);
Some business applications might require precisely control what should be logged at certain level and where to store log data. Instead of reinventing wheel, the Enterprise Library could be used to provide some extra features.
Above two methods are valid and useful but they require you plan ahead by writing trace code. What if you didn’t do that in your BizTalk orchestration, can you still collect trace data? Absolutely, In this case, you can try to enable process and message tracking using BizTalk Administration Console by checking Track Events/Message Bodies/Message Properties. However this is not a best practice recommended by Microsoft due to the performance consideration. Under the hood, BizTalk will copy the content of message to the BizTalk Tracking database during the orchestration execution even if you only need to exam one element. In the next BizTalk release, the BizTalk tracking feature is very likely replaced by BAM. If your organization plans to implement BAM, BAM could provide data for process tracking too. Although BAM is a powerful tracking engine since it’s fast and highly scalable, the drawback of BAM is BAM tools are awkward to use.
As a general rule, I try to avoid any solutions which have performance impact. For instance, some developers add a Send shape in Orchestration to write XML message to a send port just for diagnosis purpose. This is inacceptable because each Send shape in Orchestration will cause an orchestration instance to be persisted to database, which will noticeably slow down orchestration execution.
Personally, I think writing information to system Event Log is a better approach. It allows you easily diagnose execution sequence and information through Event Viewer. The performance impact is negligible. If you develop custom pipeline, custom functoid or .Net class library, you can use the same mechanism to log information. If you have multiple BizTalk servers, you can also takes advantage of MOM ( Microsoft Operations Manager ) or other system management tools such as Argent Guardian to monitor multiple servers. Often, combining two or more tracing methods will provide enough trace information and make it easier and quicker to resolve production issues.