Developing workflows in WSS 3.0 inside Visual Studio
One of the big features in WSS 3.0 includes their support for workflows (they have a new dependency on Windows Workflow Foundation in the .NET 3.0 framework). This should help make a lot of the scenarios that people were coding in WSS 2.0 a lot simpler and easier to both develop and manage.
If you're new to Windows Workflow Foundation like I am, you can read this excellent MSDN white paper.
To summarize, here is an application of these terms in the workflow life cycle:
- Developer develops a workflow template.
- Server box administrator deploys the template to a site collection.
- List administrator associates a workflow template with a list or content type on that site collection to create a new association.
- User starts an instance of a workflow association on an item (or workflow instance starts automatically on event).
- Workflow executes, perhaps creating some tasks and history items on the Tasks and Workflow History lists specified in the association.
- Workflow owner (the person who started the workflow) or list administrator can talk to a running workflow at any time by modifying it with a modification.
...
It’s not critical understand the low level details of how workflows operate internally to develop workflows, but there are a few the important high level concepts that will help:
- When running workflows reach a point in the code, a.k.a. schedule, where they need to wait for something to happen (such as a task edit), they are serialized (i.e. turned into binary) and dehydrated to the SharePoint database.This means that the workflow object is turned into a string and stored to the database. We can say that the workflow is asleep.
- Dehydrated workflows are no longer in memory.
- When the event the workflow is waiting for happens, the workflow is deserialized and wakes up, or rehydrates, then continues where it left off in the schedule.