BizTalk + Event log = angry admins

Posted: April 4, 2014  |  Categories: Biztalk Uncategorized
Tags:

So, I got a bone to pick up with the developers out there. This is how you use the event log. There are “three types” of BizTalk people (let’s skip architects etc.). BizTalk Developer, Administrators/Operators and DevOps. I’m not saying I’m perfect (none of us are, but I’ve seen my fair share of mistakes, errors and messed up environments, and I’ve done a few of them myself).

So what is the event log, what is the purpose of the event log? First of all it holds information related to different aspects in BizTalk, the one most used by admins is the one regarding “applications”.

When we conduct health checks we check for any spamming of the event log. So what is meant by all this?

In general the event log is not projected for you to write messages to it during the application unless it delivers an actual win for the BizTalk Administrator. So adding an event saying “Message received” or “Message failed” without giving any valuable info is not acceptable and it should not be there.

Recognize that the event log is a vital tool for us to be able to troubleshoot problems with DTC, COM+, Systems, BizTalk Server (not your application). If a message fails to make the error message in the group hub better, if the message is received and we need to know we’ll use BAM or the DTA.

Keep the event log clean and tidy. Writing to the event log is in general not acceptable.

  • kranti

    If we want to debug the call orchestration. we have to write the message to event log Let me know if there is any other way..???

    Thanks

  • Thomas Stevens

    Agree with op, over/mis use of app event logs especially in multi-server environments can be a train wreck.

    What has worked for me is using a logging scheme that offloads logging events through a C# façade (can be used in almost every BizTalk artifact) into to a local msmq. From there we use either a simple windows service or a simple messaging only port to port scheme to deliver the events from the queue to a final destination logging database (or logging file).

    With this degree of indirection you will never have your applications impacted by logging disruptions to writing files or to databases. You have an ample window to maintain logging (take it offline, move it, etc.) without the need to stop any BizTalk applications.

    It’s also dirt easy to develop without adding environment prerequisites like frameworks, server configuration, or, complicated injection schemes.

    Ideally if you are using the tools BizTalk provides you won’t need to log things like “I am here this is my variable value”. With orchestrations debugger, breakpoints, attaching, using subscriptions to syphon message copies you can have a debugging plan that will work in production as well without the need to “let me run it on my machine”

One Platform Operations, Monitoring and Analytics Software
BizTalk360

microsoft biztalk

Learn more

Over 500 customers across 30+ countries depend on BizTalk360

ServiceBus360

Azure service bus

Learn more

Start managing your Azure Service Bus namespaces in minutes

One Platform - Operations, Monitoring and Analytics Software
BizTalk360

microsoft biztalk

Learn more

Over 500 customers across 30+ countries depend on BizTalk360

One Platform - Operations, Monitoring and Analytics Software
ServiceBus360

Azure service bus

Learn more

Start managing your Azure Service Bus namespaces in minutes

Back to Top