How Windows SharePoint Services Processes Workflow Activities
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
It is worth understanding how Windows SharePoint Services processes Windows SharePoint Services-specific workflow activities in a running workflow instance.
Windows SharePoint Services runs the workflow until it reaches a point where it cannot proceed because it is waiting for some event to occur: for example, a user must designate a task as completed. Only at this "commit point" does Windows SharePoint Services commit the changes made in the previous Windows SharePoint Services-specific workflow activities. Those changes are batched into a single SQL transaction. This approach has two major advantages:
Batching the changes into a single SQL transaction is less performance intensive than committing each change as it occurs as a separate transaction.
If any of the changes fail when committed, Windows SharePoint Services rolls all the changes back to the previous "commit point." This greatly decreases the amount of work developers have to do when creating exception handlers and compensation handlers for Windows SharePoint Services-specific workflow activities.
When the event for which the workflow is waiting occurs, Windows SharePoint Services resumes running the workflow. Again, the workflow runs until another event is reached or the workflow ends, at which point Windows SharePoint Services commits any changes made by Windows SharePoint Services-specific workflow activities subsequent to the last commit point. This continues until the workflow reaches its conclusion or is stopped by the user.
This approach can affect workflows in which you have interspersed Code activities with Windows SharePoint Services-specific workflow activities. Although the write operations for the Windows SharePoint Services-specific workflow activities are batched and not committed until a commit point is reached, any write operations you include in Code activities are committed as they occur. Also, Code activities do not have the implicit rollback functionality of Windows SharePoint Services-specific workflow activities; if you want error handling for them, you need to write exception and compensation handlers for those activities.
See Also
Concepts
Workflow Activities for Windows SharePoint Services Overview