Implementation of Logging and Instrumentation Application Blocks in MOSS 2007

• Download source code - 1.45 MB

Introduction

The purpose of this article is to illustrate how we can effectively make use of the Application Blocks within SharePoint 2007 Development Tasks.

If you have not read the blog post about the Enterprise Library and its application blocks, you can read it at MSDN.

For example, the Data Access Application block can be effectively used when writing Web Parts to implement the interaction of Web Parts with custom databases, or even the Caching Application Block to implement caching of data within the Web Part.

One of the main time consuming portions while doing development is always devoted to implementing the effective use of exception handling and logging.

A well designed application should always involve exception handling and logging, which involves:

• Carefully implementing try-catch blocks.
• Making use of multiple catch filters to either recover out of a situation or display a friendly error message on screen.
• Implementing finally blocks to release unmanaged memory objects.

Need for Using Structured Logging in MOSS 2007

Exceptions generated by user interface elements like Web Parts and controls can be simply displayed on the screen; however, exceptions generated by services like MOSS timer jobs and workflows can be quite tricky to handle.

They need to log full exception details and stack trace so that users can find out the cause of the exception.

Let's start with configuring the Logging Application Block to incorporate standard logging in MOSS 2007 ULS logs. The ULS logs are, by default, stored in the Logs folder under 12 hive. We will create a simple MOSS 2007 application to demonstrate the simplest logging to SharePoint ULS logs using the Enterprise Library.

Before proceeding, a quick grasp of the design of the Logging Application Block is necessary, which can be found here.

We will see how easy it has become to implement these functionalities with the core functionalities being contained in wrapper classes of the Enterprise Library.

Let's start on with writing a custom Trace Listener, which will trace all our logs to SharePoint logs. Fire up VS 2005 and create a Class Library project. We will create a custom class which implements the interface Microsoft.Practices.EnterpriseLibrary. Logging.TraceListeners.CustomTraceListener. The interface requires the implementation of three methods: TraceData, Write, and WriteLine. The code for the same is shown below:

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Practices.EnterpriseLibrary.Logging;
using Microsoft.Practices.EnterpriseLibrary.Common;
using System.Runtime.InteropServices;
using Microsoft.SharePoint.Administration;
using System.Diagnostics;
namespace Logging
{
    [Configuration.ConfigurationElementType(
       typeof(Configuration.CustomTraceListenerData))]
    public class SharepointTraceListener:TraceListeners.CustomTraceListener
    {
        string assb=System.Reflection.Assembly.GetCallingAssembly().FullName; 
        int level=TraceProvider.TraceSeverity.High;
        string app="Sample App";

        public override void TraceData(TraceEventCache eventCache, 
               string source,TraceEventType eventType, int id, object data)
        {
            if (data is LogEntry && this.Formatter != null)
            {
                this.WriteLine(this.Formatter.Format(data as LogEntry));
            }
            else
            {
                this.WriteLine(data.ToString());
            }
            
        }

        public override void Write(string message)
        {
            TraceProvider.RegisterTraceProvider();
            TraceProvider.WriteTrace(0,level, Guid.Empty, assb,app,app, message);
            TraceProvider.UnregisterTraceProvider();
        }

        public override void WriteLine(string message)
        {
            TraceProvider.RegisterTraceProvider();
            TraceProvider.WriteTrace(0, level, Guid.Empty, assb,app,app, message);
            TraceProvider.UnregisterTraceProvider();
        }
    }
}

If you see the code above, it is awfully simple. It makes use of just one class TraceProvider, which outputs the details of the trace to the log. The implementation of this class is given by Microsoft in the WSS 3 SDK here, so I am not going to repeat it here.

We can just include the same implementation in our project from this location.

Configuring the Logging Application Block for the Custom Trace Listener

To use our custom trace listener, we need to create custom application configuration file. This can be created from the Configuration Tool provided by Microsoft Enterprise Library. Fire up the configuration tool and choose New Application, and add a new Logging Application Block.

Right click the Trace Listeners section and choose New Custom Trace Listener, and select your custom Trace Listener. In our case, it's Logging.SharepointTraceListener. Save the file as App.config.

Using our Configured Logging Application Block in Applications

Now, since everything is ready, we can make use of our custom app.config (along with the Enterprise Library binaries, obviously) in our MOSS development applications like Web Parts, timer jobs, workflows etc.

The steps needed for the same would be:

• Add the custom App.config to the VS 2005 project
• Add a reference to Microsoft.Practices.EnterpriseLibrary.Logging and Microsoft.Practices.EnterpriseLibrary.Common
• Use the LogEntry and Logger classes of the Enterprise Library to output trace to SharePoint ULS logs using CustomTraceListener

Here is a sample SharePoint console application which I built to demonstrate this:

using System;
using Microsoft.SharePoint;
using Microsoft.Practices.EnterpriseLibrary.Logging;
using Microsoft.Practices.EnterpriseLibrary.Common;

namespace SPConsole
{
    class Program
    {
        static void Main(string[] args)
        {
            try
            {
                using (SPSite site = new SPSite("http://madhur"))
                {
                    //write normal code
                }
            }
            catch (System.IO.FileNotFoundException ex)
            {
                LogEntry logEntry = new LogEntry();
                logEntry.EventId = 100;
                logEntry.Priority = 2;
                logEntry.Message = ex.Message;
                logEntry.Categories.Add("Trace");
                logEntry.Categories.Add("UI Events");
                Logger.Write(logEntry); //The log will be written to sharepoint ULS logs
            }
        }
    }
}

In the code above, if the SharePoint site as a specified URL is not found, the exception is directly traced to SharePoint ULS logs. The key thing to note here is that the location where the trace output is logged is completely encapsulated in App.config.

<listeners>
  <add 
    listenerdatatype=
      "Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.CustomTraceListenerData, 
        Microsoft.Practices.EnterpriseLibrary.Logging, Version=3.1.0.0, 
        Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" 
    traceoutputoptions="Timestamp" 
    type="Logging.SharepointTraceListener, Logging, Version=1.0.0.0, 
          Culture=neutral, PublicKeyToken=null" 
    name="Sharepoint Trace Listener" 
    formatter="Text Formatter">
  </add>
</listeners>

By just changing the highlighted line in our App.Config above, we can make the trace to be output to different trace listeners, email, database, flat file, XML file, and so on. This is the real power of the Microsoft Enterprise Library.

That's all! Feel free to analyze it, use it, modify it...