Developing Workflows in VS: Part 5 - Code Your Workflow

Step 3: Code Your Workflow

With your data in place, write your workflow logic.  It’s pretty straightforward, but here are a couple pitfalls that you should watch out for:

Pitfall: Re-using non-serializable SharePoint objects after rehydration
Many non-workflow specific SharePoint objects, like SPListItem, are not serializable, so when the workflow dehydrates, these items become invalid.  So if you try to use them when the workflow wakes up, you will get an error.  To avoid this, refetch items if you’re using them after a workflow rehydrates. 

Pitfall: Forgetting to make custom classes serializable
When creating your own class in a workflow, don’t forget to add the “Serializable” attribute to the class.  If you don’t do this and declare a variable of that class in the workflow’s scope, the workflow will fail when it tries to go to sleep and serialize the class.  If you notice that the workflow “completes” when it isn’t supposed to, this may be the culprit.

Pitfall: Updating locked items
If a document is open or locked, updating the item will throw an exception.  If you need a workflow to write to a column on the item, you can try to:  a) Have the workflow poll for the lock and executing the update only when the lock is released, or b) use item.SystemUpdate() to “burn through” the lock.  Note that for option (b), the user who has the document open will blow away the workflow’s changes if he saves the document.

FAQ: How do I set a custom status for my workflow?
The SharePoint SetState activity does this.  See WSS SDK for details.

 

Next time: Deploy and Debug Your Workflow