I believe that there is a right way and wrong way to instrument your solutions. Good code review should make sure that developers do not set up inappropriate tracking or debugging. The purpose of this blog article is because I believe the following quote taken from https://code.msdn.microsoft.com/BizTalk-Server-Moving-0dc0400d is the wrong way to instrument your solutions. “Many time in BizTalk developers like to write informations that will help them tracking and debuging there orchestrations like: •Message received •Message successfully Transformed •Message sent to external system ….. What the Admin should do? Let the developer by happy by writing in the Event Viewer… But take back the control of your environment by easily creating or using PowerShell script”
Why would I want to run this clever Powershell script on my environments? Why would I want to give my BizTalk Host user elevated privileges to write in this manner to the event log? I would rather write to a log file for diagnostics tracing and only write to the event log if it requires business action and not debugging information. I once carried out an audit and discovered that some Muppet had written every action as above into the event log as an informational message. The event rolled around so quickly with all these informational messages such that you never saw the error messages! I think that developers should just not do this period.
Code instrumentation has always been crucially important in complex software solutions. Rich tracing and logging enables collecting detailed telemetry and diagnostic information to understand application behaviour and facilitate troubleshooting. While BizTalk Server provides out-of-the-box a decent level of logging, it is recommended that further instrumentation is implemented in to the applications so that troubleshooting production issues can be performed without any code changes. The BizTalk CAT Instrumentation Framework is a high performance tracing/logging framework for BizTalk that builds upon the Event tracing for Windows (ETW) infrastructure. It was created by Microsoft’s BizTalk Customer Advisory team (CAT). Microsoft used essentially the same framework to instrument BizTalk itself, as well as many of the adapters. I believe this framework is useful for all BizTalk server solutions, and can be expanded to be used by other tools. A controller for the framework can be found here. For many years now the development teams that I have worked with have instrumented our BizTalk solutions as recommended above and we have found this to be immensely valuable. Any developer that tried to write tracing diagnostics to the event log would be counselled by a senior developer. As an example I have changed the expression code in the example to use the CAT Instrumentation framework
callToken = Microsoft.BizTalk.CAT.BestPractices.Framework.Instrumentation.TraceManager.WorkflowComponent.TraceIn(); Microsoft.BizTalk.CAT.BestPractices.Framework.Instrumentation.TraceManager.WorkflowComponent.TraceInfo(“AnnoyingTordAndMark”, “Hello Tord and Mark! Incoming message… Scanning.. Receiving operation connection to ” + “data base.. MESSAGE RECEIVE!”);
Microsoft.BizTalk.CAT.BestPractices.Framework.Instrumentation.TraceManager.WorkflowComponent.TraceInfo(“AnnoyingTordAndMark”, “Just an update Tord and Mark! Message successfully Transformed”);
Microsoft.BizTalk.CAT.BestPractices.Framework.Instrumentation.TraceManager.WorkflowComponent.TraceInfo(“AnnoyingTordAndMark”, “Finally Tord and Mark! Message sent to external system”);
Microsoft.BizTalk.CAT.BestPractices.Framework.Instrumentation.TraceManager.WorkflowComponent.TraceOut();
I think this should be how a BizTalk developer sets up debugging or tracing.
