Freigeben über

Tracking/Auditing Events in a SharePoint Workflows

  • Artikel

When building a solution using SharePoint and Workflow Foundation your requirements are sometimes that it should be possible track what everyone did and when it was done, in other cases you can forget all about the process once it has completed. Another name for this is that the system should support auditing.

This discussion has once more become current as there recently has been some talk in the blogosphere about SharePoint's removal of association between item and workflow, one such post is written by Robert Bogue. So those who have considered tasks and workflow tasks as suffucient tracking may have to reconsider. Before going any further let me say that I have not personally verified which items and associations that are removed.

I can quickly think of five different places which you could store tracking data:

  • Tasks: The task holds information about who was assigned, when it was completed, etc.
  • Workflow History: Custom data logged by a developer, only holds information which the developer chose to log. Can either be used for audting or for "debugging".
  • Event Log: Custom event log used to store audit information.
  • SharePoint Audit Log: Log information to the audit log using the audit API.
  • Custom Audit Log (e.g. SQL Server): Log information to a database or text file which you have control over.
  Pros Cons
Task
  • Built-in functionality in MOSS
  • Deleted during clean-up (as per linked blog post)
  • Not all events you wish to audit are a result of a task, hence this cannot be the only way you audit.
Workflow History
  • Built-in functionality in MOSS
  • Easily created from within a workflow
  • Association to main item cleared after 60 days (can be changed)
Event Log
  • Built-in in functionality in Windows
  • Might be a stretch to log all types of events that are interesting for a complete solution
  • What about search capabilities? Can this be achieved using WMI?
  • Event Log is per machine and normally a SharePoint solution involved multiple WFEs.
SharePoint Audit Log
  • Reuse of standard SharePoint functionality
  • Cannot be easily manipulated
  • Might be a stretch to log all types of events that are interesting for a complete solution
Custom Audit Log
  • Easy access from other applications
  • Any logging needs can be taken care of
  • Need to created and maintain the database / text file
  • Not a standard function

One issue to consider when choosing a tracking mechanism is what kind of proof you will need to show in an audit. Is it sufficient that there is a log or are you required to prove that an entry hasn't been manipulated? Or have entries been removed?

Conslusions

Currently I'm leaning towards using a custom audit log in SQL Server. It can be reasonably protected from everyone except SQL Server sysadmins. But I will also have to further consider the merits of the SharePoint Audit Log.

Comments