WHY MY WORKFLOW DOES NOT WAKE UP FROM DELAYACTIVITY?

  • Article

Lately working with one of the customer’s I came across an interesting lookout.

Basically customer has created a simple workflow for SharePoint in Visual Studio 2008 and had used a delay activity which seems to be causing the problem.

The problem was that workflow runs perfectly fine but after hitting the delay activity, never wakes up.

My first hunch went to the issue with SharePoint Workflows with delay activities (also noted on SharePoint Product Group blog). But the workflow seems to be too simple to get into any of the known issues.

Now I started looking into the deployment of the workflow and noticed that they have deployed the workflow’s assemblies into the BIN folder of the IIS-App under c:\inetpub.

Well, it does not seems to be the problem as the workflow was starting up fine and going through a few activities and facing issue only when hitting the delay activity.

The workflow architecture training earlier came to my rescue.

Basically workflow in 2 different process.

- W3WP.exe
- OWSTIMER.exe

W3WP.exe is the ASP.net worker process. When you first start the workflow (automatically or manually), the workflow assembly is loaded and workflow started by W3WP.exe process.

OWSTIMER.exe comes into picture when the workflow is persisted into the database and need to be woken up and restored into the memory.

In this particular scenario of the customer, the workflow assemblies were there in BIN of the IIS-Application under C:\InetPub folder. Now W3WP.exe process recognize which locations to scan for and from where the assemblies need to be picked up. But once the workflow hits the Delay Activity and it is saved to the database, to wake it up and restore into the in-memory state and continue execution, OWSTIMER.exe does not know the location of the assemblies, therefore the workflow fails to wake up.

Finally the resolution: 
Once we determined the problem, suggested the customer to sign the workflow assemblies and deploy them to GAC and remove from the BIN folder of the IIS-Application. Once the changes were done and assemblies deployed to GAC, the workflow worked perfectly fine and  completed “as expected”.

Hope this small in-sight helps someone out there with their workflows