用 SharePoint Server 2007和Windows Workflow Foundation开发工作流解决方案(三)
保存工作流状态更新工作流的程序集
SharePoint服务实现了工作流自身持久性服务在SharePoint内容数据库的Workflow表里。SharePoint服务通过系列化工作流实例并压缩它，与二进制形式（BLOB）存储在图片列表中来创建持久性工作流实例。
你会发现写一个简单的应用程序获取二进制（BLOB）值，通过System.IO.Compression.GZipStream类（或者通过流的形式保存为.gz文件和通过程序如WinZip提起内容）解压二进制值，或者用记事本打开它看二进制内容引发的持久性工作流的引擎。如果你这么做，请注意，所以二进制文件都在这里，持久性状态包含下列相关内容：
- 强名称程序集，包含版本名称和公钥。
- 每个工作流活动的实体（例如StateActivity，EventDrivenActivity，和IfElseAcitivity）
- 在系列化时你定义的所有私有变量和内容的实体。
有时，你必须修复工作流的bug或者添加新功能。除了一些不重要的修复以外其他更改可能需要添加新的StateActivity, StateTransition, IfElseBranch, 或者CodeActivity活动（或者其他继承于Activity的活动）。或许你需要自定义一个私有变量或者移除不再使用的私有变量。
通过检查以二进制保存的状态和执行一些小实验，我们确定工作流系列化引擎特别关注保存状态的程序集版本和相关代码的匹配。首先要检查工作流版本，接着在检查相关代码的执行。
你可以试着不改变程序集的版本，这能使工作流轻松的通过强名称和版本的检查。然而，工作流引擎可能会通过新程序集导入旧的持久性状态。如果新程序集包含代码结构的任何更改，由于错误搭配了保存的和预期的实体导致了工作流引擎无法加载持久性状态。你可以查看ULS日志的IndexOutOfRange异常或者在工作流状态页面中查看错误信息“工作流运行失败”。当你更改Layout下面的代码和准备重新部署时你必须编译工作流程序集。
每个工作流的关联都是通过强名称来注册程序集的，意思就是说如果你重新部署新版本的工作流程序集，你也必须重新部署新版本的Workflow.xml文件，重新激活工作流的Feature，和重新创建或添加工作流关联，目的是让Windows SharePoint Services连接到新版本的工作流程序集。
下面讨论更新和编译工作流的的三种方法：
选项1：移除所有新站点的内容和重新部署执行不完成的工作流
创建新网站，将新版本的工作流程序集注册到该网站，迁移工作流关联的列表和文档库项目，删除完整的工作流。对于有即将发生的工作流项目，重新执行它。
这一选项不是最主要的，因为它要求将旧SharePoint站点的数据迁移到新SharePoint站点上。如果工作流是固定的也可以修改下面站点（例如新的列表项）的格式，这样迁移就很重要了。此外，你必须重新执行你的工作流，如果不这么做，会增加已经准备移除工作流的用户的负担。
选项2 ：利用工作流代码继续或重新启动所有工作流内部的进程
状态机工作流，设计状态转换流程的选项是为了以后重新启动流程。工作流进程可以把相同状态的信息保存在列表项和文档属性里，状态信息一般是放在列表或文档库的栏上。工作流启动时流程可能需要包含初始化状态值。已运行的工作流通常有不同的内部进程状态值。
如果你编译任何状态值（不是初始值）的工作流，在启动时跳到执行该状态的代码，你可以删除完成的或正在运行的工作流，移除旧的工作流程序集的关联，添加新的工作流程序集的关联，然后重新执行所有将要运行的工作流。
自然，你作为开发人员在工作流开始时添加许多条件“re-entry/re-route”，这种做法会增加你的负担。你可能不想做额外的工作，或者你不能完全地测试所有re-entry的脚本。这种设计只能适合状态机工作流。
选项3：用旧的程序集运行旧的工作流和新的程序集运行新的工作流
你可以更改“没有新工作流”（开始时停止新工作流但是允许存在完成的工作流）的工作流关联的模式。把旧的工作流关联到“没有新工作流”模式中和添加新的工作流关联，这样你能同时运行多个版本的工作流程序集。
例如，你有个叫作“MyCustomWorkflow V1.0.0.0”的工作流关联，它是在“没有新工作流”模式中关联到1.0.0.0版本的工作流程序集。然后，你可以添加与工作流1.0.1.0版本有关的“MyCustomWorkflow V1.0.1.0”。
这不是理想的解决方案，例如，如果你旧的工作流程序集有个未确定的Bug，那么继续运行工作流程序集就起不了作用了。如果“On Item Change”事件启动新的工作流关联，每次旧的工作流更改该项目时，它会启动新的工作流实例。在某些情况下这种做法仍是最有效的。
现在，没有删除旧版本你想部署新的工作流程序集。更新命令Stsadm.exe，它能替换旧的解决方案包，当旧的解决方案包被删除时在GAC中旧的工作流程序集也会被删除。
部署新工作流解决方案包覆盖旧的
- 更新工作流程序集版本
- 在Workflow.xml文件中Workflow节点的CodeBesideAssembly属性里更新工作流程序集版本
- 在工作流项目中的manifest.xml文件里更新解决方案的ID。
- 更改通过packaged.ddfor生成的.wsp解决方案包名称，重命名生成的.wsp文件。
- 部署新的解决方案包，然后将新版本的工作流程序集注册到GAC中。
- 执行iisreset命令。
- 将旧的工作流关联添加到“没有新工作流”模式中。
- 手动或编程方式确保新的工作流关联与旧的工作流关联名称不同。
创建活动的用户界面
在SharePoint Server上，用户和工作流交互可以通过下列两种活动表单：
- InfoPath表单（InfoPath或Microsoft Office Forms Server 2007）部署到SharePoint站点的表单库里
- 自定义ASP.NET表单部署到每个前端Web服务器上并展现在SharePoint站点上，表单放在Layouts虚拟目录下面。
InfoPath表单和Office表单服务
InfoPath表单和表单服务提供了一个强大的平台，用于创建和部署整个企业的业务表单。通过内置的功能如数据源和表单控件，你可以轻松地创建用户熟悉的内部或外部在线业务应用程序的复杂表单，不需要写代码。
主要：
你也可以扩展InfoPath表单的功能，通过写代码调用InfoPath API和使用Microsoft Visual Studio Tools应用程序开发工具。但是这方面的介绍不再本文中。
Microsoft Office 2007系统中的应用程序，如Word和Outlook完全集成到InfoPath中和宿主到InfoPath表单里目的是用户可以更新任务无需离开应用程序。
SharePoint 服务提供了一个可扩展平台创建自定义InfoPath表单当设置好的用户界面不符合业务需求时更新任务。
注意：
用InfoPath表单收集数据启动自定义工作流时需要Microsoft Office SharePoint Server Enterprise系列号。
您不需要企业版的Key来提交工作流任务InfoPath表单。
使用InfoPath设计任务表单时，辅助连接（MetaData.xml）需要添加到表单作为辅助数据源。每个控件都要帮定到在xml文件各自的节点元素中。代码如下：
<?xml version="1.0" encoding="utf-8" ?>
<z:row xmlns:z="#RowsetSchema" ows_taskInstructions="" ows_taskComments="" ows_taskStatus="" />
在工作流代码中，你可以访问通过SPTaskProperties.ExtendedProperties属性集合注册到MetaData.xml文件的元素。
注册工作流表单，添加URN（<Task0_FormURN>,<Task1_FormURN>,等等）到Workflow.xml文件里。代码如下：
<Task0_FormURN>
urn:schemas-microsoft-com:office:infopath:SampleApprovalTask:-myXSD-2007-06-05T03-26-26
</Task0_FormURN>
<Task1_FormURN>
urn:schemas-microsoft-com:office:infopath:SampleChangeManagementTask:-myXSD-2007-08-01T20-18-49
</Task1_FormURN>
在任务列表里使用表单，你指定任务表单，通过设置SPWorkflowTaskProperties的属性TaskType，在Workflow.xml文件中从零开始自定义表单的索引，例如：
TaskType = 0；//指向Task0_FormURN，
TaskType = 1；//指向Task1_FormURN。
private void CreateChangeManagementTask_MethodInvoking(object sender,
EventArgs e)
{
//Creates a new Task for Change Request Change management.
changeManagementTaskID = Guid.NewGuid();
changeManagementTaskProperties =
new Microsoft.SharePoint.Workflow.SPWorkflowTaskProperties();
changeManagementTaskAfterProperties =
new Microsoft.SharePoint.Workflow.SPWorkflowTaskProperties();
changeManagementTaskBeforeProperties =
new Microsoft.SharePoint.Workflow.SPWorkflowTaskProperties();
changeManagementTaskProperties.TaskType =
1; //Specifies form with URN in <Task1_FormURN>
changeManagementTaskProperties.Title =
string.Format("New Change Request: {0} for deployment",
workflowProperties.Item.Title);
changeManagementTaskProperties.AssignedTo =
changeRequest.changeManagementGroup;
changeManagementTaskProperties.Description =
string.Format("Please schedule this Change Request: {0} for " +
"deployment. Mark Task complete when change has been completed.",
workflowProperties.Item.Title);
changeManagementTaskProperties.ExtendedProperties["taskInstructions"] =
string.Format("Please schedule this Change Request: {0} {1}, {2} " +
"for deployment. Mark Task complete when change has been completed.",
workflowProperties.Item.Title, workflowProperties.Originator,
itemChangeRequest);
changeManagementTaskProperties.SendEmailNotification = true;
}
在Layout目录下自定义ASP.NET表单
你可以使用ASP.NET表单关联工作流，在WSS3.0和moss中，ASP.NET表单是简单的ASP.NET页面，是用.NET FrameWork开发的Web应用程序。
您可能已经注意到很多SharePoint管理页面在_layouts 虚拟目录下。你也可以把你的ASP.NET页面拷贝到虚拟目录下，当运行时，他们作为SharePoint页的上下文和其他SharePoint站点的一部份。
当ASP.NET工作流成为SharePoint站点的一部分时，工作流可以和站点交互，通过SharePoint对象模型编程或间接地修改工作流项目属性，触发“On Item Changed”事件和处理工作流的运行。
开发ASP.NET表单，你可以选择用内部代码来实现你的业务逻辑或利用代码隐藏文件（.aspx.cs或 .aspx.vb），下表列出了应当考虑部署选项：
| ASP.NET活动页面代码的类型 |
开发和部署注意事项 |
| 所有.aspx文件的内部代码 |
|
| 代码隐藏文件
.aspx 和.aspx.cs/.aspx.vb 代码隐藏文件的部署 |
|
| 代码隐藏文件
部署被编译成程序集的所有隐藏代码文件 |
|
展现在Layout虚拟目录下的ASP.NET表单，首先创建ASP.NET页面，可以使用代码也可以不使用，然后通过解决方案包将表单部署到前端Web服务器上。最后指定.aspx和隐藏代码文件的子目录是在C:"Program Files"Common Files"Microsoft Shared"web server extensions"12"TEMPLATE"LAYOUTS下（例如：C:"Program Files"Common Files"Microsoft Shared"web server extensions"12"TEMPLATE"LAYOUTS"MyCustomWorkflow"MyActivityPage.aspx）。
你可以通过_layouts/MyCustomWorkflow访问ASP.NET页面，例如http://developmentserver/sites/workflowtest/_layouts/MyCustomWorkflow/MyActivityPage.aspx
了解工作流的类型：顺序和状态机
WF提供了两种工作流类型，分别是顺序工作流和状态机工作流，你的选择取决于你需要完成的任务。
使用顺序工作流
顺序工作流执行为了完成任务而预先定义好的一系列步骤。顺序工作流是个很好的业务流程，它可以按顺序来执行，没有太多的循环和回退步骤，或突然启动。例如：顺序工作流可以很好的工作在下列环境中：
- 开支报表的多级审批
- 更改管理应用程序通过Dev，QA，IT和Ops连续审批
- 通过层次扩展Helpdesk应用程序
- 显示图形表示的进程是非开发的
使用状态机工作流
状态机工作流是工作在事件驱动中。一个状态机工作流包含两个或更多的状态，即状态是在任何时间给定的活动状态。每个状态可以表示业务任务的分配；任何状态都可以转换成其他状态。状态机工作流中复杂的，非线性的，分支的模型可以有简单的true/false或批准/拒绝等业务流程的交互。例如：状态机可以工作在下列环境中：
- 复杂销售报价高级流程，很多审阅者和审批者必须提交描述信息（有超过一次的）和报价可以通过多次的拒绝和审批前批准。
- 大的房地产合同，多个文件可能独立地依赖于个别的工作流；他们构成通过法律审核，合同谈判，修改，代管之前签署和归档的建议。
在Visual Studio中选择工作流的编程模型
Visual Studio 2008已经内置了（Windows Workflow Foundation），新建项目的对话框中提供了下列新的工作流选项：
- 顺序工作流（代码） 定义顺序工作流和用户代码在同一个代码文件中
- 顺序工作流（与代码分开） 定义顺序工作流的XAML和用户代码在单独的代码文件中
- 状态机工作流（代码） 定义状态机工作流和用户代码在同一个代码文件中
- 状态机工作流（与代码分开） 定义状态机工作流的XAML和用户代码在单独的代码文件中
无论你选择哪种工作流类型，你都必须把它打包成SharePoint Feature
用SharePoint Server开发工作流解决方案
用SharePoint Server开发工作流WF解决方案是最好的方式，可以使用本地的和虚拟机运行Windows Server 2003，SharePoint Server和其他开发工具。开发的机子必须包含下列选项：
- Windows Server 2003 or Windows Server 2003 R2
- Windows Server 2003 Service Pack 2
- Web Role (ASP.NET) enabled
- .NET Framework 2.0 SP1
- .NET Framework 3.0 SP1
- Windows SharePoint Services 3.0 and SharePoint Server 2007
- Windows SharePoint Services 3.0 Service Pack 1 and SharePoint Server 2007 Service Pack 1
- Any post-SP1 SharePoint updates to Windows SharePoint Services and SharePoint Server
- All Windows Server 2003 and SharePoint Server 2007 hotfixes from Windows Update or Microsoft Update
- Visual Studio 2008 with Visual Basic, C#, and Web Development installed
OR
Visual Studio 2005 with extensions for .NET Framework 3.0 (Windows Workflow Foundation) and Visual Studio 2005 extensions for Windows SharePoint Services 3.0
当你在配置一个独立的开发环境，你可能要把数据库放在另外一台服务器上。在相同的开发服务器上，你必须安装下列选项：
- Microsoft SQL Server 2005
- SQL Server 2005 Management Components
- SQL Server Service Pack 2
- SQL Server Cumulative Update 5 or later
有利于开发的其他工具：
- .NET Framework SDK tools
- Platform SDK tools
- Windows webugging tools
- Windows Resource Kit tools
- Windows support tools
- SysInternals utilities
- .NET Reflector
- File comparison tools (such as WinDiff)
- A compression utility (such as WinZip) to look inside WSP and STP packages
为开发人员推荐测试场配置
虽然SharePoint服务器上的所有组件都认运行在任何一台服务器上，但是这种配置在生产环境中是很少见的。开发SharePoint服务器上的解决方案时，你必须配置一个与最终生产环境相似的一系列开发和测试环境。这样你可以保存在你的解决方案开发过程中的各种 SharePoint 角色中的服务器之间的复杂交互的详细信息的问题。
通过Microsoft Virtual PC 和 Microsoft Virtual Server创建一系列机器来关联本机的域或部署一个测试域，模拟生产环境，这是最常见的方式。
例如，你需要用下列的虚机部署一个域控，邮件服务器，数据库服务器，开发服务器，中型的测试场和一个客户端测试机子：
- 1 domain controller/DNS/DHCP server
- 1 development server (application/index/front-end Web/query/database/POP3/SMTP server with all development tools)
- 测试场:
- 1 个数据库服务器
- 1 应用程序/索引服务器
- 2 前端Web/查询服务器
- 1 邮件服务器 (运行 Microsoft Exchange Server 或 Windows with POP3/SMTP)
- 1 客户端 (Windows XP or Windows Vista with Office)测试web站点的访问
用Visual Studio 2005开发
当Microsoft发布Windows SharePoint Services 和SharePoint Services时，Visual Studio 2005工作流开发只有一个选项。现在Visual Studio 2008这一选项也能使用，同时扩展了VS2005的功能。针对不同版本的 .NET Framework 的 Visual Studio 2008 可能混合和匹配 SharePoint 项目，如网站定义和 Web 部件 (.NET Framework 2.0) 和工作流 (.NET Framework 3.0 和 3.5) 在相同的解决方案中。
然而，如果你不选择vs2008用vs2005可以也可以开发。
总结
用SharePoint 产品和技术，创建简单的或灵活复杂的业务流程，本文讨论了经验丰富的开发人员可以使用 Visual Studio 创建模型复杂的工作流和各种外部系统集成的代码驱动工作流的方式。
其他资源
- Microsoft SharePoint Products and Technologies Team Blog: "So You Want to Develop Custom Workflows in Visual Studio..." - The Blog Series
- Advanced Workflow: Enabling Tricky Scenarios
- Microsoft .NET Framework 3.0 Community (NetFx3) (Windows Workflow Foundation)
- Windows Workflow Foundation Overview
- SharePoint Server 2007 SDK: Software Development Kit (includes templates for workflow development)
- WF How-To: Building State Machines with Windows Workflow Foundation
- Nikhil's Blog: SharePoint Workflow Feature in Visual Studio 2008
- Nikhil's Blog: SharePoint Workflow Feature in Visual Studio 2008 (Part II)
今天终于把它翻译完了，呼呼。真开心！