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!
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.
To fix, follow these instructions.
First run this command on your farm:
stsadm -o setproperty -pn job-workflow -pv "Every 5 minutes between 0 and 59" -url http://yoursite
(http://technet.microsoft.com/en-us/library/cc424946%28v=office.12%29.aspx)
(note apparently doesn’t like being anything but 5 minutes! )
I rebooted my dev box after this but this is probably not required.
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.
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.
To fix, follow these instructions.
First run this command on your farm:
(http://technet.microsoft.com/en-us/library/cc424946%28v=office.12%29.aspx)
(note apparently doesn’t like being anything but 5 minutes! )
I rebooted my dev box after this but this is probably not required.
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.
 |
| OWSTIMER service |
No comments:
Post a Comment