A huge issue around workflows in general is tracing and error handling. When a workflow encounters an error it will simply state "Error Occurred" within the workflow status column. The data is then written to the SharePoint log file.
Previously, I was using the Unified Log Viewer from CodePlex which I do recommend, but at times I found it hard to get on a live server's central administration site to do this.
To get around this, I am writing the error information straight to the workflow history list.
I have also added a method to ensure that the automatically inserted workflow column gets removed, as this can confuse end users and can be added within a separate, non-default view.
Method for logging errors to history list:
1: /// <summary>
2: /// Logs a message to the history list of the workflow instance.
3: /// </summary>
4: /// <param name="workflowProperties">The <see cref="SPWorkflowActivationProperties"/> to extend this functionality to.</param>
5: /// <param name="message">The message to log to the history list.</param>
6: public static void LogToHistoryList(this SPWorkflowActivationProperties workflowProperties,
7: string message)
8: {9: try
10: { 11: workflowProperties.Workflow.CreateHistoryEvent( 12: 0,13: null,
14: null,
15: string.Empty,
16: message,17: string.Empty);
18: }19: catch
20: {21: return;
22: } 23: }Method for removing status column:
1: /// <summary>
2: /// Removes the workflow status column from the default view.
3: /// </summary>
4: /// <param name="workflow">The activity to extend this functionality to.</param>
5: /// <param name="properties">The <see cref="SPWorkflowActivationProperties"/> from the workflow instance.</param>
6: public static void RemoveStatusColumn(this Activity workflow,
7: SPWorkflowActivationProperties properties) 8: {9: using (SPSite site = new SPSite(properties.SiteId))
10: {11: using (SPWeb web = site.OpenWeb(properties.WebId))
12: { 13: SPList list = web.Lists[properties.ListId]; 14: SPView view = list.DefaultView; 15: 16: SPField field = list.Fields[properties.TemplateName];17: field.Hidden = true;
18: field.Update(); 19: 20: try
21: { 22: view.ViewFields.Delete(field); 23: view.Update(); 24: list.Update(); 25: properties.LogToHistoryList(26: "Workflow status column removed from default view on list.");
27: }28: catch (SPException)
29: {30: //Does not exist.
31: return;
32: } 33: } 34: } 35: }If anyone knows of a better way of checking if the field exists already (the field name is completely random) then please let me know as this would be far better than letting the code throw an error on line 22. I have created an item template for Visual Studio 2008 that includes refactored, commented code and uses the two methods mentioned above.
2 comments:
One of the issues my company opened with Microsoft was closed with a work-around that says: Don't pollute your workflow history list with lots of trace information. Having more than 2000 entries in a workflow history list (especially one shared by multiple instances of the same workflow in the same list) is "not a best practice". It lead to what we now call the "stuck workflow" problem. I now write the bare miminum of trace information to the workflow history log and write my trace entries to a dynamically created Discussion Board topic. The problem with writing to the workflow history list is worse because workflow history lists are hidden by default and cannot be "pruned" to keep them below the recommended 2000 or less entries.
Thanks for the information. This practise, however, is not intended for tracing but for adding unhandled exception details only into the history log, which would occur when the workflow encounters a breaking error, causing it to terminate.
I would not recommend using this for trace information - any information that is not directly usable to an end user should go into a real trace file, not the history list.
Post a Comment