Friday, 19 October 2012

Developing Sharepoint workflows using the Windows Workflow Foundation and Visual Studio can be pretty painful.

By far the most painful part I have come across is the dreaded delay activity never waking up problem. This occurs when you place a delayActivity object in your workflow in order to wait for something to happen (for example in a while loop). This is pretty fundamental stuff in a workflow, so you would expect this to be a basic requiredment, but for some reason SharePoint has a HUGE flaw in this department: when you are developing your workflows, they seem to get stuck in the delay and never wake up!

A WWF DelayActivity in a while loop

Workflow history - it never wakes up after delay :(

After much head scratching, I have found a solution. The delayActivity passes control to the SharePoint Services Timer (OWSTIMER.EXE), and this gets confused if you redeploy the wrokflow.

The key part is that now provided I restart the Microsoft Sharepoint Timer service between deploys, it actually completes a delay! So remember to recycle the "Sharepoint 2010 Timer" service before you depoly a new version of the workflow to the farm.

To debug any code that runs after a delay, you have to attach Visual Studio to the timer service (owstimer.exe), not the w3w process. I do this by switching off "auto retract after debugging" in the "Sharepoint" page of the project's properties file and manually attaching to the OWSTIMER.EXE process.