The following summarizes how workflows are executed from start to finish:
- A person or process initiates some action that causes the workflow to begin. In SharePoint 2007, workflows can be:
- Started on demand by a user by using the SharePoint user interface.
- Started or resumed in response to the On Item Created event for an item in a list or document library.
- Started or resumed in response to the On Item Changed event for an item in a list or document library.
- Started or resumed programmatically through the SharePoint object model.
- Started programmatically through the Workflow Web service.
- Once the workflow begins a process is created to execute tasks or actions in the workflow code. Not all workflows use the same hosting process.
- Workflows started from the SharePoint user interface use the W3wp.exe process that is specific to the IIS Web application the workflow was initiate from.
- If the workflow uses DelayActivity code or has a noncatastrophic error when the workflow instance begins then the Owstimer.exe server process is the host process. The Owstimer.exe is the SharePoint timer service process and is used in this context to start workflows when DelayActivity code is used or to try executing a failing workflow again at a later time.
- When an external application (such as a console application, Web service, or Windows Communication Foundation service) creates items programmatically through the SharePoint object model, the process running the code becomes the workflow host.
- The workflow determines what action needs to perform next and executes the code.
- If the workflow needs to wait for a response before it can continue, then the SharePoint event handlers tell the Windows Workflow Foundation Runtime Engine to put the workflow to sleep using the SQL workflow persistence service.
- When a workflow becomes idle the Windows Workflow Foundation Runtime Engine calls the SQL workflow persistence service to save the workflow state into the content database of your SharePoint website.
- The SQL workflow persistence service assigns correlation tokens for the workflow and to each task as that the workflow engine can use unique identifiers to map events and actions to the correct workflow object. Next, the SQL workflow persistence serializes the workflow object turning into a binary string, and then saves it with a unique Workflow Instance ID to the SharePoint content database. This process is called dehydration.
- Once the workflow object is safely stored within the database the memory used to run the workflow is released and the workflow is considered to be put to sleep.
- When SharePoint receives a response to carry out the next action from ones of its event handlers, the Windows Workflow Foundation Runtime Engine wakes up the sleeping workflow using the SQL workflow persistence service. When the new response data and the data from the store workflow object the workflow can run the code to perform the remaining actions.
- When a user or system respond to a workflow action, the unique Workflow Instance ID is passed to the Windows Workflow Foundation Runtime Engine and SQL workflow persistence service finds the workflow object in the SharePoint web application’s content database.
- When the Windows Workflow Foundation Runtime Engine retrieves and deserializes the workflow object from the database, it performs many checks to ensure that the workflow object is mapped to the correct response. The checks ensure the workflow DLL has the correct namespaces, entities, and correlation tokens. The process of retrieving the workflow object is called hydration.
- Once the workflow object is successfully retrieved and passed all its checks the workflow is awake and is able to execute the rest of the action code.
- Steps 3 to 5 are repeated for each action as necessary until the workflow is complete. Once the workflow is complete, the workflow status is updated and the workflow memory and hosting process are released.
To answer your question there are ways that workflows might not make it through the migration process. The following are situations you should consider before migrating your SharePoint 2007 workflows to SharePoint 2010:
- A person or process initiates some action that causes the workflow to begin as a migration occurs: Workflows that are executing code are processing data in the memory of the server. If you begin a migration while the workflow is still in memory it is possible for the information and the workflow instance to be lost. Before starting your migration it is wise to make sure that your SharePoint sites are not able to be accessed by users. This ensures that no new workflow instances are initiated and any workflows that were running are hopefully completed or sleeping within the SharePoint web application content database.
- Identify any custom workflows that use DelayActivity code: The DelayActivity code delays an activate workflow from executing. If a workflow becomes completely idle during the delay and the UnloadOnIdle method is set to true, then the workflow may be unloaded from memory, put to sleep, and then reloaded into memory when the specified delay time expires. If the UnloadOnIdle method is set false then the workflow will remain in the server's memory and may be lost during a migration process. You want to ensure no new workflow instances are initiated and any workflow that were running are hopefully completed or sleeping within the SharePoint web application content database.
- Make sure any external applications do not start workflows during the migration process: If you have external applications in your company interacting with SharePoint you want ensure that no new workflow instances are initiated. The workflow instance could be in memory and could be lost. Again the best strategy is to limit access to the SharePoint environment.
- Ensure all custom workflow code are working correctly before the migration: If your workflow is not working correctly then the Owstimer.exe server process might trying to reactive the workflow action repeatedly. Especially if you are moving content databases to another SharePoint 2010 farm, this workflow instance could get lost. Make sure custom workflow code is in working order by checking the event and SharePoint logs on your server. Once the code is corrected the workflow will either finish or become idle and be saved to the content database.
- Run the pre-upgrade checker to look for potential issues: The pre-upgrade checker reports missing customizations and issues with orphaned sites, and more, so that you can address these issues before you perform your upgrade. The pre-upgrade checker also checks your workflows for the following issues:
- 956447: The ModifiedWorkflowActionsFile rule in Pre-Upgrade Checker can warn that the default declarative workflow actions file has been modified
- 956448: The CustomWorkflowActionsFiles rule in Pre-Upgrade Checker in Windows SharePoint Services 3.0 Service Pack 2 can warn that custom .ACTIONS files exist in the farm
- 956449: The ModifiedWebConfigWorkflowAuthorizedTypes rule in Pre-Upgrade Checker for Windows SharePoint Services 3.0 Service Pack 2 can warn that Web.config files contain modified authorized types for workflow
If the pre-upgrade checker is not run and the issues not corrected it is possible that your workflow will not work correctly. For more information about the pre-upgrade checker that comes with Office SharePoint Server 2007 with Service Pack 2 visit TechNet's Run the pre-upgrade checker article.
- Check to see if the Workflow Auto Cleanup timer has been disabled: If your Workflow Auto Cleanup timer job is disabled in your Office SharePoint Server 2007 environment, make sure that you disable this timer job in your new environment also. If this timer job is enabled in the new environment and disabled in the previous version environment, you might lose workflow associations when you upgrade. For more information about this timer job visit Disable preservation of workflow history.
If you are using out-of-the-box SharePoint workflows do not worry too much. Microsoft developers know how to handle their own solutions and migrate them forward correctly. You will notice in the web.config files of the SharePoint 2010 virtual directories that there are redirect statements so that if code is looking for the SharePoint 2007 DLLs they are redirected to the SharePoint 2010 workflow DLLs. The following are web.config entries for redirecting workflow DLL versions:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
<dependentAssembly><assemblyIdentity name="Microsoft.SharePoint.WorkflowActions" culture="neutral" /><bindingRedirect oldVersion="12.0.0.0" newVersion="14.0.0.0" /></dependentAssembly><dependentAssembly><assemblyIdentity name="System.Web.Extensions" /><bindingRedirect oldVersion="1.0.0.0-1.1.0.0" newVersion="3.5.0.0" /></dependentAssembly><dependentAssembly xmlns="urn:schemas-microsoft-com:asm.v1"><assemblyIdentity name="Microsoft.Office.Workflow.Routing" culture="neutral" /><bindingRedirect oldVersion="12.0.0.0" newVersion="14.0.0.0" /></dependentAssembly><dependentAssembly xmlns="urn:schemas-microsoft-com:asm.v1"><assemblyIdentity name="Microsoft.Office.Workflow.Tasks" culture="neutral" /><bindingRedirect oldVersion="12.0.0.0" newVersion="14.0.0.0" /></dependentAssembly><dependentAssembly xmlns="urn:schemas-microsoft-com:asm.v1"><assemblyIdentity name="Microsoft.Office.Workflow.Feature" culture="neutral" /><bindingRedirect oldVersion="12.0.0.0" newVersion="14.0.0.0" /></dependentAssembly> |
These DLLs likely have code for the old SharePoint 2007 workflow actions and also the new SharePoint 2010 workflow actions. By having two sets of code the old workflow actions can finish correctly and then any new workflows going forward will use the new SharePoint 2010 workflow actions.
When it comes to your custom workflow code make sure all the code is copied on the SharePoint 2010 environment and that any web.config or app.config settings are already in place. When the websites are finished being migrated you want everything to be in place so that workflows can complete their jobs.
If you are moving between farms remember that you want to make sure that your workflows are either completed or sleeping in the content database of your site. Any workflows in memory have the highest risk of getting lost or not finishing as the processes will not be active in your new farm.
I hope I have answered your question and gave you some things to think about. Thank you for submitting your question and good luck on your SharePoint 2007 to 2010 migration. Please feel free to send any additional questions you may have.
参见：http://www.the14folder.com/2010/07/25/migrating-workflows-question/