在MOSS 2007种利用InfoPath 2007结合Workflow Foundation可以高效的做出非常强大的工作流应用。因为在SDK中这部分的内容有点不流畅，读起来比较费劲。所以我想以我的一点小经验和大家Share下，希望能少走点弯路，然后再结合 SDK 、ECM Starter Kits 和 WSS Workflow StarterKits 快速掌握这个非常棒的功能。
1、我要创建用于 MOSS 的 Workflow 项目。
请下载 WSS Workflow StarterKits，安装后将有个"SharePoint Server"的组，内有 SharePoint Sequential Workflow Library 和 SharePoint State Machine Workflow Library 两个项目模板。利用这两个模板创建的项目，对 Workflow 的开发、部署都很方便。
项目用到的 Microsoft.Office.Workflow.Tasks.dll、Microsoft.SharePoint.dll 和 Microsoft.SharePoint.WorkflowActions.dll 均在装有MOSS 2007的机器的 C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\ISAPI\ 目录下。其中开发时主要注意记得在VS2005工具箱里注册 microsoft.sharepoint.WorkflowActions.dll，就可以从工具箱里拖拉出 MOSS 特有的 Workflow 控件了。
Feature.xml：在 MOSS 中， Workflow 是作为 MOSS 的 Feature 存在的，具体使用时再关联到具体某个 List 或 Library 中并创建实例运作的。因为 Feature.xml 文件就是安装部署时候要把生成的项目 dll 文件作为 Feature 注册到 MOSS 中的描述文件了。刚打开时是空的，只是一些提示，按提示插入 Feature 的 Snippets，就有一段 xml 代码插入。其中 GUID 可通过 VS2005 菜单 Tools 下的 Create GUID 创建一个新的 GUID 填入；中间有个
节点用于关联工作流 xml 描述文件。
Workflow.xml：工作流描述文件。其中有工作流名字Name（该名字在添加 Workflow 关联具体列表或文档库时显示在工作流列表中）；GUID（同样通过 Create GUID 生成填入）；CodeBesideClass和CodeBesideAssembly对应工作流类全名和程序集全称（项目如进行签名，此处需明确PublickToken，同时把 install.bat 中 gacutil 部分反注释掉）；TaskListContentTypeId为工作流使用到的任务列表的 ContentType ID，默认为 Workflow Tasks 的 ContentTypeID，一般不需要修改；AssociationUrl、InstantiationUrl和ModificationUrl一般也不用改，默认创建即是用于呈现 InfoPath 的页面，其中 AssociationUrl 为用来关联 Workflow 和列表或文档库，并设置工作流运行参数的页面；InstantiationUrl为用于当手动启用工作流时呈现给用户的初始化页面。Association_FormURN 和 Instantiation_FormURN 等以 _FormURN 结尾的节点都存放其相应的 InfoPath Form 的 ID（该 ID 可通过设计 InfoPath Form时，打开“文件->属性”窗口即可看到该 InfoPath Form 的 ID）。关于 TaskForm 下面解释。
install.bat：用于安装部署Workflow的批处理文件。根据具体情况注释或反注释命令行，同时配置MOSS地址即可。
Workflow1.cs：工作流设计和代码。
2、我的 InfoPath 表单模版无法正常发布，或者发布后状态为“Installing”而不是“Ready”。
请检查以下几个环节，一般无法正常发布都有可能是以下原因造成。
首先检查表单模版是否与浏览器兼容。设计表单模版状态下，打开 InfoPath 菜单“工具-->检查设计方案”，然后再在右边任务窗格中点“更改兼容性设置”弹出表单选项，把“浏览器兼容性”组里的“设计一个可在浏览器或 InfoPath 中打开的表单模版”勾起来，然后进行检查。
如果表单发布用于 Web Access，可同样打开“表单选项”，在“安全和信任”中把“安全级别”调整为“域”级别。
确认所有的表单最好都不曾发布过。判断依据，把.xsn表单模版文件拷贝到其他地方，打开右键“设计”打开它，如果出现警告错误框提示“此表单已经发布到一个位置，但后来被保存或移动到了另外一个位置。如果确保基于此模板的表单正常工作，请重新发布表单”，那就说明该表单已经发布过，否则则没发布过。没发布过的表单模板，每次保存表单模板时均提示是“发布”还是“保存”，一概“保存”。
如果该 InfoPath 表单有后部 C#或VB.NET代码，即不小心用 VSTA 打开过，那么发布时会要求必须经过管理员审核，也会造成无法正常发布表单。可在“表单选项”窗口中“编程”里，点击“删除代码”即可。
InfoPath 2007是中文版本，但发布到英文版本的 MOSS 中时也会出现发布异常。同样在“表单选项”窗口中“浏览器”里，选择表单语言为“英语（美国）”即可。
3、我在 MOSS 列表中设置 Workflow 为新增一条记录 A 时就自动启动，同时给审批者创建一条任务，该任务用了我自己定义的任务 InfoPath 表单，但该 InfoPath 任务表单中有几个字段是要读取记录A中字段值来显示的。
这个问题的实质就是要把某条具体 ListItem 中的字段值传递给 Task 表单（该表单为 InfoPath 表单），然后再通过Task表单显示出来。这里头有三个子问题：怎样获取和当前Workflow相关的 ListItem、通过怎样方式把值传递给 Task表单、Task 表单最后又怎么呈现。
怎样获取和当前Workflow相关的ListItem：通过SPWorkflowActivationProperties.Item来获取当前 SPListItem。
通过怎样方式传递给 Task 表单。请查看《How to：Access Workflow Task form Data》。例如 taskProperties.ExtendedProperties["ApplyNo"] = this.ApplyNo;。
Task表单最后怎么呈现。察看《Creating the WOrkflow Task Edit Form》的第4、5、6点。主要是要选择绑定 ows_ 字段时，默认是没有 ows_ 字段的“主”数据源，你必须选择“ItemMetadata (辅助)”数据源才能看到ows_字段。
具体范例可以查看 ECMStarterKits中 HelloWorld 经典示例。结合上面注意的几点。
4、我现在已经在 Workflow.xml 里配置了一个 Task Form了（有类似这么一个节点
urn:schemas-microsoft-com:office:infopath:ReviewTaskForm:-myXSD-2005-11-22T23-52-35），这个 Task Form是我第一个 Task 用到的，但我还有第二步，第三步，每个步骤都会建一个任务，我的每个任务都要对应不同的 Task Form 来收集每个阶段的用户录入的数据来运作工作流的。怎么加第二个任务表单？
根据 SDK 《Windows Task Form〉，无疑，增加第二个Task Form的第一步就是在把设计好的第2步用到的 InfoPath 表单模板的 ID(URN) 配置起来。即在
节点下增加类似这么一个节点：urn:schemas-microsoft-com:office:infopath:MultiStage-Initiation:-myXSD-2006-04-28T22-44-03。
真正核心的问题来了，怎么让第2个任务表单和实际工作流中分配的第2条任务关联起来？好，关键就在 SPWorkflowTaskProperties.TaskType 这个属性。TaskType = 0 时就表示这是第一个任务请用第一个任务表单，TaskType=1时就表示这是第二个任务请用第二个任务表单。就是这么简单。:)
你可以打开 ECM StarterKits中的 MultiStage 示例，这个示例是比较实用的例子，务必研读。打开示例中的 WorkflowTask.cs，找个GetTaskCreationProperties（）方法。修改如下：
public SPWorkflowTaskProperties GetTaskCreationProperties(int taskType)
{
SPWorkflowTaskProperties properties = new SPWorkflowTaskProperties();
properties.AssignedTo = this.Participants[0].AccountId;
properties.Title = this.TaskTitle;
properties.Description = this.TaskInstructions;
properties.SendEmailNotification = true;
properties.TaskType = taskType;
properties.DueDate = (DateTime)this.dueDate;
return properties;
}
然后再打开 Workflow1.cs 代码，搜索到这么一行代码 activity.TaskCreationProperties = this.activeTask.GetTaskCreationProperties(); 改为：
activity.TaskCreationProperties = this.activeTask.GetTaskCreationProperties(this.completedStages);
至此，这个 MultiStage 例子就更智能化了。你在增加工作流步骤外，还可以方便控制每个步骤任务用到的 InfoPath 表单了，而不是都用同一个表单。
http://www.developer.com/net/net/article.php/11087_3652346_1
http://blogs.msdn.com/sharepoint/
如何看InfoPath表单是否发布成功：打开SharePoint 3.0管理中心，在应用程序管理有 InfoPath Form Services 一节，进入“Manage Form Template”就可以看到你所有发布的表单。其中看状态 Status 栏，如果为 Ready，则表示该表单已经准备好可以使用了；如果为 Installing，那就是有可能因为前面罗列的各种原因造成表单模板还无法正常发布，这时候你就要检查了。另外，你可以通过URL访问已经发布的表单，地址为类似 服务器/_layouts/formserver.aspx?XsnLocation=urn:schemas-microsoft-com:office:infopath:ReviewTaskForm:-myXSD-2005-11-22T23-52-35，后面 XsnLocation=跟上表单的 ID(URN)即可。
前面提过，在MOSS中，每个Workflow都是作为一个Feature存在，然后具体使用时再关联到某个List/Library中然后创建Workflow实例运行的。在一个Workflow生命周期里，业务数据自然主要就是List/Library中的记录数据SPListItem/SPFile，再辅之任务列表数据；而Workflow过程中需要的一些流程状态数据则被WF提供的服务持久化（术语好像叫“钝化”之类的）起来，供Workflow被启用时再度激活，从而顺利继续工作流的运作。
关于 Task。一开始很多要问为什么（是/要） Task？因为在 MOSS 2007 的 Workflow 中，对于业务流程中人的部分，即工作流中人为参与的部分主要是通过“任务 Task”形式实现的。即要某人来审批或添加些数据时，就在Task列表中创建分配一个 Task 给他，然后这个人过来编辑 Task，完成人为数据的录入采集，使得工作流继续运行。
上贴有提到如果不小心用VSTA打开产生后部C#/VB.NET代码后，发布时变成了需要经过管理员审核才能使用。为什么会这样？这类表单和其他表单还有什么区别吗？答案就在《Office Forms Server 简介》。
SharePoint Desginer 2007 的工作流设计不支持 InfoPath 表单形式吗？是的，很遗憾，SPD2007只支持 ASPX Form形式的 Task Form。所以如果要在 MOSS 2007 里开发 InfoPath + Workflow，还得用前面说过的方法。当然，前面的方法也支持 ASPX Form形式，详细可看 ECM Starter Kits中很经典的 ASPX Form 范例 —— CollectFeedback 示例。
为什么 Workflow.xml 中的 AssociationUrl="_layouts/CstWrkflIP.aspx" 和 InstantiationUrl="_layouts/IniWrkflIP.aspx" 不能换成其他页面？这些页面可以理解为 InfoPath Form 的 Host Page(实际是这些页面内部嵌入了显示InfoPath Form的WebPart)，InfoPath Form Services处理 InfoPath Form后通过这些 xxxIP.aspx 的页面把 InfoPath Form表单以 Web Page形式呈现出来。所以，不能改变成其它页面，否则无法正常显示 InfoPath Form。
不太明白 ItemMetadata.xml 作用，或者说把SPListItem数据传给InfoPath Form并和InfoPath控件绑定显示出来的过程是怎样的？这个一开始确实比较费解。首先根据 SDK 操作一遍后，此时 ItemMetadata.xml 已经作为辅助数据源和资源文件保存在 InfoPath Form里了。记得，此时最好把 ItemMetadata.xml 理解为 InfoPath Form 的“数据源”！然后传递过程是这样的：
把准备传递给 Task InfoPath Form 的 SPListItem 字段值取出来赋值为 SPWorkflowTaskProperties.ExtendedProperties["表单字段名"]。
任务表单接受这些值，然后组织成一份 xml ，也就是你看到的 ItemMetadata.xml：。
InfoPath Form接收这份 xml 数据，因为InfoPath Form中的控件已经绑定过相应的辅助数据源 ItemMetadata.xml 的 ows_字段名，所以可以顺利的从含有数据的 ItemMetadata.xml 数据源中抽取值显示在表单里。
6、先这样吧。总体感觉似乎人们最多问题的居然是 InfoPath！InfoPath、InfoPath还是InfoPath。其实InfoPath并不难，严格说起来个人觉得和Excel差不多（当然要玩深下去，那可深不见底，但常用功能都很简单的），可能是因为不常用原因吧，可惜了这个产品。给几个 InfoPath 站点给大伙看看：
InfoPath:
FormServer:
InfoPath Team: http://blogs.msdn.com/infopath/default.aspx
6、ECM Starter Kits 虽然是 for Beta2TR，但完全可以正常跑在正式版里，当然前提是对里面的个别打不开或跑不起来的项目进行一点修改。
CustomSignatures项目：把相关的 CorrelationToken 由 SignatureWorkflow 改为 SignaturesWorkflow。出现这种现象也不知道该说微软什么了，估计是赶时间推出这个 Sample。
ModificationSample项目：跑到 Workflow1.cs 代码里，找到 updateTask1 代码段，把相关 updateTask1.AssignedTo 等等都在中间加个 TaskProperties 属性，变成 updateTask1.TaskProperties.AssignedTo 这类的。
其他如果还有问题，可以具体看，要么注释，要么做修改，不影响整体代码可读性，大部分也都在正式版里运行正常。
7、我有这么一个场景，我一进去编辑 Task Form 时，该 Task Form 前面列出这条记录的Title等基本字段值，然后下面有“同意”或“下一步”的按钮，还有“拒绝”或“取消”的按钮。我点“同意”或“下一步”不要立马提交，而是转到显示另外一个Form让我填同意后需要处理的一些表单数据。如果我按“拒绝”或“取消”也转到显示另一个Form让我填不同意时要录入的另外一些信息。
这个应用只要你用过InfoPath的视图，就立刻知道怎么实施了。InfoPath的一个表单是允许多个视图的，所以你大可以把包含“同意”和“拒绝”的两个按钮的 Form 当作第一个默认视图，同时再增加一个同意后的视图和一个拒绝后的视图，然后制定这两个按钮的规则（Action里有switch view的这项），点同意就显示同意的视图，点不同意就显示不同意的视图，同时把同意或拒绝的状态值赋值给数据源中某个字段，这样就完全达到了上面的效果。
扩展下思路：你可以用radiobutton排出一队的选项，因为 radiobutton 绑定着一个字段，所以可以判断当用户选定哪个项时来决定我要显示哪个视图。比如，我有“全部公开”、“部分公开”和“不予公开”三个项，我选“全部公开”然后按下一步，就可以跑到全部公开的视图里填写一份政府公文，输入xxxx年xx号和备注后，按提交就完成这个步骤了；以此类推。
额外提下InfoPath，我们知道 InfoPath Form 不用编码本身就可以有一定规则流程的，这些动作包括常用的对输入数据的校验、根据某种条件进行某种动作、执行一些Action等。所以，你可以直接在表单里设置诸如必填字段、进行自动计算、动态增加节点数据、根据输入数据动态调整表单表现或设置数据源字段、根据一定规则执行一定操作等等，而大部分这些操作在发布到 MOSS 中进行 Web 显示时，还是可以正常使用的，使得数据收集这块变得异常方便快捷。
8、MOSS的Workflow历史记录在哪里？
你可以通过右键菜单中的Workflow菜单进去查看该条记录的工作流情况，有工作流的已经运行过的步骤产生的Task链接，也有每步的动作列表。如果想看所有Workflow的历史列表，可以访问 服务器/Lists/Workflow%20History 查看，不过估计那些数据不是人能看懂的。但至少可以保证，工作流从头到尾所有的业务数据和流程数据都是存在的，都可以提供给你去查到你所要的历史痕迹的。
如果你还熟悉Workflow Foundation的 TrackingService，你用了其Sample的 WorkflowMonitor 打算来跟踪查看 MOSS 的 Workflow 时，sorry，结果是无法运行，无法跟踪，无法查看。Why？没错，WorkflowMonitor可以利用Workflow Foundation的TrackingService跟踪监控Workflow，但是 MOSS 的 Workflow 却没有使用 Workflow Foundation 默认的 TrackingService（这个实在让人费解，不知出于什么目的），所以如果你要Monitor，那可以考虑为 MOSS 写一个 WPF Application 的 Workflow Monitor，相信这个 idea 应该还是不错的:-) 那MOSS怎么做历史跟踪，打开Reflector看看 Microsoft.SharePoint.WorkflowActions.dll里的相关类，也许就清楚了。
9、差不多了，这个 InfoPath + Workflow + MOSS 的主题就到此为止，这个主题仅仅是当作辅助参考。最后看了choral 的《如何配置Windows SharePoint Services 3.0的搜索》的文章的后面评论中，有人评论说 MOSS 不值得关注，而我则反过来想告诉大家一句话：请重视或正视MOSS！微软平台上的企业应用开发商/开发人员都必须重视这个产品，而微软的对手们也必须正视这个产品。也许答案在这张图里。
转自：http://blog.joycode.com/liuhuimiao/archive/2007/01/19/91817.aspx
