SharePoint workflows ... not your regular workflows

Posted by Gitte Vermeiren on Oct 21, 2009

Workflow Foundation (WF) is a great new technology added to the .Net 2.0 Framework. It enables you to construct workflows using pre-build activities. Working with WF is made easy within the Visual Studio environment, where a point and click interface can be used to construct your workflows. 

In SharePoint the same workflow mechanism can be utilized to write workflows that target SharePoint sites, webs, lists, … There are also extensions available for your Visual Studio environment that add extra specific project types for SharePoint workflows and extra activity types. A great way to work with SharePoint, using a tried and tested environment … Or so we thought… This post will give an overview of some of the specific things you need to think about when writing workflows for SharePoint.

1. Do NOT use SPList objects (or anything else SharePointy) as private datamembers!!
2. Do something funky with Guids (but don’t be too funky or things will break)
3. Sleeping is not recommended

So first: why shouldn’t you use any SharePoint types as private datamembers? The answer is simple, because they cannot be serialized when your workflow puts itself to sleep. A workflow will often put things on hold when it is waiting for some kind of response or event. For instance, you want to react to the fact an item in a list is changed. There is no point in keeping your workflow up and running while you are waiting for this to happen. The workflow will persist itself (no need to add extra coding for this, persistence is present out of the box) and will wait for an event. After the event, the workflow will revive and continue working. Now, for this persisting, everything contained within the workflow, needs to be able to be persisted as well (read: needs to be serializable). And, halas, SPList, SPSite, SPWeb, … objects are NOT serializable. The fun thing is, you only notice this after a lot of trial and error and a lot of time spend on forums, figuring out why yur workflow dies on you.

Second, the funky thing with Guids: Your workflow will function on one or more SharePoint lists. As mentioned before, it needs to be persisted from time to time and it needs to be revived. To be able to do this successfully each list needs to know which workflow is attached to it. Further more each item in a list sometimes needs to know as well which workflow is connected to this, especially when you want to react to events of listitems. For this Guids are used. You need a Guid for the overall workflow. And, if you want to react to listitem events, you need a different, separate, not the same (!!!!) Guid for the events you connect to the listitem. Oh, and did I mention that these two Guids should NOT be the same? Why do I stress this? Because I want to save you loads of headaches, that’s why!

And finally, don’t sleep … Or better, don’t let your workflow sleep. There are some known issues when using the delayActivity in a SharePoint workflow. It might delay your workflow … forever. So to avoid this, make sure you have all the latest updates installed on your SharePoint server. Also, be aware that SharePoint revives only every 10 minutes, so setting a time lower than 10 minutes on your delayActivity will be of no use (or will look funny, because it will only revive after 10 minutes). I also found there could be an issue with one of the SharePoint services when delaying doesn’t work as expected, but this was not the case when we tried this out.

There, I hope that with this post we can save you some workflow headaches. Once you know these three issues, implementing SharePoint workflows is (almost) like a walk in the park.