ISCLogConnection/ISCLogEntry

Last updated on: 5/13/2013 4:35 PM 
Created on: 11/2/2016 2:22 PM 

An overhead item that is usually tedious and unpleasant is the recording of details and events to one of various locations of logs. Several open source solutions exist but a customizable and more scalable solution was sought. The SC-7 framework handles the recording of event logs through its RecordEvent() method. The framework also contains pre-created implementations of this interface for the Window's Event log and file-based event logging. However in the event that a customized form of event logging is required all that is needed is a custom implementation of this interface.

The ISCLogConnection needs to implement 3 virtual methods. The first is OnOpen() which needs to perform all initialization code and verify that the ability to record events to the physical event log is available at any time an event needs to be recoded. Returning an error code from this method will set the connector's internal validity state to invalid and prevent events from being recorded to the underlying media. Likewise, when the framework no longer needs to record events the OnClose() method will close and cleanup any resources that were obtained during the OnOpen() call. The third method is the OnWriteEntry() method. This one must be implemented as it is marked pure virtual and if the validity state is set to valid, this method is responsible for generating the log entry and calling any resource specific methods (API) to have the entry logged. The parameter to this method is a pointer to a class that implements the ISCLogEntry interface.

Because log entries may require additional information that isn't standard to other log entries that are being made, this interface provides the basic implementation needed by the framework's event logging handler. The only method required for custom implementation is the BuildEntryText() method. This method accepts one parameter which will contain the string representing the current user that caused the event to be generated. The interface contains a member string m_strMessage which can be parameterized in any way needed to properly convey the event. BuildEntryText() must perform the formatting of this string. It is safe to assume that shortly after the call to BuildEntryText() returns, the formatted string will be grabbed and placed in the event logs by the event logging handler.

The framework's event logging handler is designed to be platform specific and performs most of the event logging with out additional overhead. As a result of this, implementing connection classes from the ISCLogConnection is a task that is normally not required. It is expected to be more common to create a series of classes derived from ISCLogEntry to perform proper formed, precise messages to be recorded to the event log. The framework's event logging method accepts the ISCLogEntry implementation is the parameter allowing instances of these entry classes to exist only within the currently executing scope reducing the amount of physical resources required during the execution cycle of the framework.