The main logging framework used in Titan is the ASP.NET Health Monitoring API. Since we very rarely need Trace type logging, this was a good fit for us as it is easy to configure via changes to web.config. Error events are always raised to the Event Log.
<system.web>
<healthMonitoring>
<providers>
<add name="CmsEventLogProvider" sourceName="CMS Data" logName="NWSCMS" type="NorthwoodsSoftwareDevelopment.Cms.Logging.CmsEventLogProvider,CmsLoggingSupport"/>
</providers>
<profiles>
<add name="Default" minInstances="1" maxLimit="Infinite" minInterval="00:01:00" custom=""/>
<add name="Critical" minInstances="1" maxLimit="Infinite" minInterval="00:00:00" custom=""/>
</profiles>
<eventMappings>
<!-- add name="My Event" type="NorthwoodsSoftwareDevelopment.Cms.Logging.NwsTraceEvent,CmsLoggingSupport"/ -->
<add name="My Errors" type="NorthwoodsSoftwareDevelopment.Cms.Logging.NwsErrorEvent,CmsLoggingSupport"/>
</eventMappings>
<rules>
<!-- To get trace logging, uncomment the two My Event entries -->
<!-- add name="CmsEventLogProvider" eventName="My Event" provider="CmsEventLogProvider" profile="Critical"/ -->
<add name="Nws Errors" eventName="My Errors" provider="CmsEventLogProvider" profile="Critical"/>
</rules>
</healthMonitoring>
</system.web>
Application Layer
Custom web services and components can make use of CmsLoggingSupport to write Trace and Error events to the NWSCMS event log.
Components
When creating a custom component, make use of the Logging framework by creating an EventSource.
private static EventSource _eventSource = new EventSource(EventLogConstants.CmsComponents, "YourDLLName.YourClassName");
Then in your methods, raise Trace Events before and after the actual work to capture input parameters and return values.
TraceCallEnterEvent.Raise(_eventSource, "MyClass", "MyMethod", "param1 {0}, param2 {1}", param1, param2);
TraceCallReturnEvent.Raise(_eventSource, "MyClass", "MyMethod", "Return {0}", retVal);
Avoid logging error events at the component level. Instead let them bubble up to the WCF service that called them.
WCF Services
When creating a custom WCF service, make similar use of Logging framework by creating an EventSource
private static EventSource _eventSource = new EventSource(EventLogConstants.CmsWcfServices, "IMyService");
This time, in addition to logging trace events, use try/catch blocks to trap errors and raise error events. Typically, we want the error to continue up the call chain to report to caller.
catch (Exception ex)
{
ErrorMessageEvent.Raise(_eventSource, String.Format("Error calling function {0}", ex.StackTrace), ex);
throw (ex);
}
Web Layer
The CmsLoggingSupport class is available to use in in web-layer code. In the Wkst and Display code, we very rarely make use of it, but the pattern is the same. – create an EventSource and raise Trace/Error events.
If you want simple logging for errors only, StateData exposes two methods for writing error messages to the NWSCMS Event Log.
public static string LogError(string errorMessage)
public static string LogError(string errorMessage, Exception ex)
Both methods log to an Event Source labeled “CMS Application” for the class “State Data”. The other benefit to using these methods is the error message parsing.
public static string ParseErrorMessage(string errorMessage)
This method can be used to get a simple message from a detailed ASP.NET exception message for possible reporting to the display.
Database Layer
The database layer isn’t typically thought of for logging, but there is an Audit Log for tracking operations in the workstation. If you write stored procedures that make changes to content or configuration (via external processes or background jobs), consider including adding a call to audit the changes in the WorkstationAudit table using internal_WriteWorkstationAuditEvent.
/*
@eventID UNIQUEIDENTIFIER,
@userCN NVARCHAR(200),
@action NVARCHAR(64),
@description NVARCHAR(MAX),
@docXML XML
*/
EXEC dbo.internal_WriteWorkstationAuditEvent @eventID, @userCN, N'calling proc', @description, @docsXML;