Sunday, August 7, 2011

Part 3 – Delays for Workflow Initiation Action

· Part 1 - Pattern for Building Stateful Workflows with SharePoint Designer 2010
· Part 2 - Custom Action for Workflow Initiation
· Part 3 - Delays for Workflow Initiation Action
· Part 4 - Using Business Connectivity Services (BCS) with SharePoint 2010 Workflow
· Part 5 - Custom Visio Services Reports with SharePoint 2010 Workflow


In the previous part of this blog series I provided an approach for chaining together a bunch of sequential workflows together so that I can create a “state like” workflow without having to use Visual Studio. However one thing I did not go over was a few configurations you will have to do to actually start working with data.

One important issue I would run into with my approach was that workflows would start to trip over each other. For instance I have workflow A and workflow B associated to a list. In this case, workflow A would start workflow B. Every once and a while the workflows would fail for no apparent reason. Digging through the logs I would find errors like this which would not tell me much.

OWSTIMER.EXE (0x0A00) 0x0968 SharePoint Foundation Workflow Infrastructure 88xr Unexpected WinWF Internal Error, terminating workflow Id# 13531682-5bef-4194-aaf6-8cf32b31345d

OWSTIMER.EXE (0x0A00) 0x0968 SharePoint Foundation Workflow Infrastructure 98d4 Unexpected System.ArgumentException: listItemKey at Microsoft.SharePoint.WorkflowActions.WaitForDocumentUnlockActivity.Initialize(WorkflowContext context, Guid listID, SPItemKey listItemKey) at Microsoft.SharePoint.WorkflowActions.WithKey.UpdateItemActivity.Execute(ActivityExecutionContext provider) at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(T activity, ActivityExecutionContext executionContext) at System.Workflow.ComponentModel.ActivityExecutor`1.Execute(Activity activity, ActivityExecutionContext executionContext) at System.Workflow.ComponentModel.ActivityExecutorOperation.Run(IWorkflowCoreRuntime workflowCoreRuntime) at System.Workflow.Runtime.Scheduler.Run()


The solution is simple; if you are going to use the approach that I outlined earlier in this series you will need to introduce some delays into your workflows.

For instance in Workflow A, I put in the following delay before my custom action to initiate a workflow.


Then in Workflow B, I put another delay.


This way I am ensured that if there are any lagging transactions are completed against the list item that both workflows are working on.

You will also have to configure the interval workflow timer job in Central Admin. The default is 5 minutes and I upped it to one minute in my development environment.


There is no perfect configuration however you will need to make the correct configuration to make sure everything works well. You need to introduce enough delays and configure the workflow service to make sure you do not get these locking issues.

No comments: