MOSS 工作流开发入门学习！

出处：http://www.cnblogs.com/wanghao-3/archive/2007/06/28/799238.html

找到好的资料，必须Share出来，这个是我做人的宗旨！希望大家能够受益。

理解Windows SharePoint Services和 2007 Microsoft Office System 中的工作流

版本：1.0，7/11/06

作者：David Chappell, Chappell & Associates

翻译：Derek Wang, http://www.vicroinfo.com

© Microsoft Corporation 2006. 版权所有.

目录

人员工作流的价值.......................................................................................................................................................... 3

技术基础........................................................................................................................................................................... 3

Windows Workflow Foundation.............................................................................................................................. 4

Windows SharePoint Services................................................................................................................................... 5

工作流和Windows SharePoint Services Version 3............................................................................. 7

合并 Windows Workflow Foundation和Windows SharePoint Services......................................................... 7

Windows SharePoint Services工作流：示例.......................................................................................................... 8

设计工作流................................................................................................................................................................ 9

建立文档库/列表与工作流的关联........................................................................................................................... 9

发起工作流................................................................................................................................................................ 9

与工作流交互.......................................................................................................................................................... 12

总结流程.................................................................................................................................................................. 14

创建Windows SharePoint Services工作流........................................................................................................... 16

使用Visual Studio 2005 和WF Workflow Designer创建工作流......................................................................... 17

使用Office SharePoint Designer 2007创建工作流............................................................................................... 19

工作流和Office SharePoint Server 2007................................................................................................... 22

合并Windows Workflow Foundation, Windows SharePoint Services以及Office SharePoint Server.... 22

Office SharePoint Server工作流：示例................................................................................................................ 23

创建Office SharePoint Server工作流................................................................................................................... 28

使用Visual Studio 2005 和WF Workflow Designer创建工作流......................................................................... 28

使用Office SharePoint Designer 2007创建工作流............................................................................................... 29

选择技术......................................................................................................................................................................... 29

结论.................................................................................................................................................................................. 30

资源.................................................................................................................................................................................. 30

关于作者......................................................................................................................................................................... 31

人员工作流的价值

企业的业务依赖于企业的业务流程，而这些业务流程常常与软件系统关联，在很多组织中，最重要的流程依赖于人工。把流程中人员的交互操作实现自动化可以大大改善流程的功能，提高流程效率并降低出错的几率。使用支持此类人员工作流的软件能够使组织更加高效的运作。

在各种组织中，有很多流程可以实现自动化，并且获益。举例如下：

n 审批流程：以人为导向的业务流程最常见的一种就是需要多个参与者进行审批，审批的内容可以多种多样，从次年的销售计划的Word文档到参加会议的差旅费用报销，不管是那种审批，都需要多个人检查，或许要补充备注意见，然后标明是同意还是否决。

n 协调团队工作：比如，答复产品需求、文档多语言翻译管理，抑或是其它，这些流程都需要多个人员进行团队合作。把这些流程的各个步骤实现自动化，可以使团队工作得更加高效，而且流程本身也更具预见性。

n 问题跟踪：很多业务流程都会有遗留问题，我们可以设计一个自动化的工作流来维护这些遗留问题，把遗留问题分派给胜任的人员，然后跟踪问题的解决状况。

正因为此，微软推出能够运行人员工作流应用的Windows SharePoint Services version 3，以实现上述此类业务流程的自动化。这些工作流的应用基于Windows Workflow Foundation (WF)开发，可以通过浏览器与人员进行交互，当然，如果需要，也可以和其它软件进行交互。要开发这样的工作流应用，开发人员可以使用WF’s Workflow Designer 和 Visual Studio 2005，信息工作者可以使用全新的Office SharePoint Designer。

作为2007 Microsoft Office system 的一部分，Microsoft Office SharePoint Server 2007为基于Windows SharePoint Services构建的工作流应用添加了更多功能。这些产品可以使用InfoPath2007创建的自定义表单作为工作流的执行界面，并且与其它Office产品，如Word 2007 和Outlook 2007进行用户交互。Office SharePoint Server同时还包含了多个预定义的工作流，信息工作者可以使用它们创建审批或其它常用流程。

Windows Workflow Foundation 和Windows SharePoint Services version 3 都将成为Windows的一个标准部分，而Office SharePoint Server是另外单独授权的产品。所有这些技术以及使用这些技术创建工作流的工具，预计将会在2006年底发布。本白皮书介绍这些工具和技术的作用和使用方法，目的是为开发人员和信息工作者展示微软在Windows SharePoint Services 和 2007 Office system提供的工作流支持。

技术基础

要了解微软对人员工作流的支持至少需要掌握2种基础技术Windows Workflow Foundation 和 Windows SharePoint Services，本节将对这2种技术进行简要介绍。

Windows Workflow Foundation

我们常看到各种软件部署有一些流程，这些流程以预定义好的顺序一步一步地执行。既然我们经常用到这种做法，为什么我们不直接提供创建这样的应用的工具呢？Windows Workflow Foundation 正是实现这样的目的。使用WF构建的应用包含一个或者多个工作流(workflow)，而每个工作流都包含多个活动(activity)，工作流中的每个活动都由WF的运行时引擎执行，而执行顺序由工作流本身决定。WF为以流程为导向的应用提供了直接支持，使得流程应用的创建和维护变得更加容易。

下图展示了WF的主要组件。通过活动构建的工作流使用运行时引擎执行。这个执行过程依赖于一套WF提供的运行时服务，运行时服务可以保留工作流的状态，跟踪工作流的执行过程，以及其它功能。所有的运行时服务在一个宿主程序中运行，这个宿主程序可以是任何Windows线程，如，一个简单的桌面应用，或者是一套可扩展的服务器系统。为了适应不同的宿主程序和不同应用的需要，我们可以在必要的时候替换WF运行时服务。

如图所示，我们可以使用WF Workflow Designer创建工作流，Workflow Designer运行于Visual Studio 2005之内，提供了一个图形环境，用来组织工作流中的活动。一个活动就是一个类 ，所以，我们也可以纯粹是用代码来创建工作流，也就是说图形工具不是必须的。开发人员可以使用各种活动，WF也提供了一个基本活动库(BAL)。BAL包含很多基本的活动，如：

n IfElse：用来执行以条件规则执行的、包含2个或者多个可能路径的活动。

n While：只要条件满足，可以执行一个或者多个活动。

n Sequence：以定义好的顺序一次执行一组活动。

n Parallel：以并行方式执行2个或者多个活动组。

n Code：执行预定义的代码块。

n Listen：等待某个事件，当接收到该事件后，执行一个或者多个活动。

n InvokeWebService：调用Web service。

n Policy：使用WF提供的规则引擎定义和执行业务规则。

WF内置提供了2种类型的工作流：

n Sequential workflows，顺序工作流，即以定义好的顺序执行活动的工作流。顺序工作流可以包含IfElse，While，和其它活动。

n State machine workflows，状态机工作流，即传统的有限状态机。这类工作流也可以包含IfElse，While和其它活动，但是它取决于其它活动，如代表状态和交易的State活动。

我们要理解WF本身并不是一套完整的工作流应用，这很重要。相反，它为开发人员提供创建工作流软件的基石，因为WF可以任何其它Windows线程为宿主，所以它可以和其它技术一起提供工作流服务。Windows SharePoint Services version 3 正是如此，所以理解微软为人员工作流提供的支持的下一步就是理解该技术的基础。

Windows SharePoint Services

现代生活的一个重要部分是共享信息。不管是在我们的工作中，比如志愿者组织的一部分，或是其它地方，我们都经常需要与他人共享文档和信息。作为Windows Server 2003的一个标准部分，Windows SharePoint Services能把这种共享变得更为容易。

如下图所示，Windows SharePoint Services的用户可以创建站点，每个站点都包含文档库和列表。每个站点中的信息，包括文档和列表项，都保存在SQL Server中。使用Internet Information Services (IIS)，用户可以从Microsoft Office应用程序或者Web浏览器，如Internet Explorer，与站点进行交互。用户也可以使用Web Part定制站点界面，每个用户都可以创建自己最适合的站点外观。

Windows SharePoint Services Version 3还添加了对内容类型，content types，的支持。内容类型是对文档或者列表项进行定义的架构(schema)。默认情况下，文档库中的文档都具有相同的架构，列表中的列表项也是如此。把内容类型附加到一篇文档或者一个列表项就可以为其单独指定不同于其它文档或者列表项的架构。除此之外，还可以给内容类型附加策略，我们可以用策略来指定比如文档长度等属性需要保留，这些策略可以用应用到任何附加了此策略的文档或者列表项。

Windows SharePoint Services Version 3还可以让多台运行Windows SharePoint Services的机器使用同一个SQL Server数据库，或者访问以站点分区的一组数据库。这种方式可以提高Windows SharePoint Services的扩展性，满足更多的用户访问同一个站点的需求。值得指出的一点是，尽管这些站点逻辑上是分开的，而且对于用户来讲不同的，但事实上所有的文档和列表项表面都是类似的，多仅仅是SQL数据表中的记录而已。文档和列表项有一些差别，文档可以签入签出，而列表项不能 ；除了这点外，他们之间的差别还包括用户看到的外观不同。

Windows SharePoint Services依赖于其它标准的Windows技术。例如，它使用Active Directory识别用户和用户界面，包括使用ASP.NET 技术创建的Web Part。因为它是Windows的一个标准部分，也同时因为它能够解决很多常规问题，Windows SharePoint Services已经成为非常流行的技术。很多组织使用Windows SharePoint Services共享各种各样的信息。但是，直到Windows SharePoint Services version 3出现之前，Windows SharePoint Services缺少创建工作流的内置功能。那么，version 3是如何做到这点的呢？请看下文。

工作流和Windows SharePoint Services Version 3

虽然WF和Windows SharePoint Services各有各的用处，但创建Windows SharePoint Services的以文档为导向的人员工作流应用会更有价值。 Windows SharePoint Services version 3使得这变为可能。Windows SharePoint Services version 3使用WF技术构建，并且会包含在Windows的下一个版本“Longhorn”中，Windows Server 2003的用户可以通过Windows Update免费获取。

合并 Windows Workflow Foundation和Windows SharePoint Services

如前所述，WF运行时引擎可以任何Windows线程为宿主，Windows SharePoint Services version 3使用的正式这种机制，作为WF运行时引擎的宿主。每台Windows SharePoint Services version 3服务器都可以安装一个或者多个工作流模板，而每个工作流模板都包含一个特定工作流的代码。安装好之后，就可以在某个文档库/列表/内容类型和某个工作流之模板间创建关联。这样，Windows SharePoint Services宿主的WF运行时引擎就可以加载并运行工作流模板，即创建工作流实例。如下图：

同所有的WF工作流一样，基于Windows SharePoint Services version 3的工作流同样依赖于WF运行时服务。但是，为了更好地支持Windows SharePoint Services宿主的工作流，version 3替换了某些内置服务。比如，WF标准的persistence服务经过了修改，以允许存留的工作流的状态能够链接到文档或者已经关联工作流的列表项。

对这些部件是如何连接在一起有一个架构上的了解是非常有价值的，这是对了解Windows SharePoint Services version 3中的工作流是至关重要的。不过，最好的了解方式是看一看使用该技术的典型案例。在下一节中，我们将了解一个使用Windows SharePoint Services 工作流的简单例子。

Windows SharePoint Services工作流：示例

在大多数的组织中，最常见的人员工作流是各种各样的审批流程，即：多个人员批准或者否决某些文档，并且添加一些备注信息，以标明他们为什么做此决定。下面的例子将展示使用Windows SharePoint Services部署的审批流程如何运作。在我们继续之前，我们先定义一些用户角色，如下：

n Workflow author：工作流创建者，创建工作流模板的开发人员或者信息工作者。

n Windows SharePoint Services administrator：Windows SharePoint Services系统管理员，安装工作流模板并在工作流模板和文档库或列表之间建立关联的人员。

n Workflow initiator：工作流发起者，运行工作流的人员，即使用某一工作流模板创建一个工作流实例。

n Workflow participants：工作流参与者，即与工作流实例进行交互的人员。

如下文所述，这些角色在工作流的创建、安装、实例化和使用过程中都扮演不同的角色。

设计工作流

Microsoft提供了2 种创建Windows SharePoint Services工作流的方法：开发人员可以使用Visual Studio 2005和WF Workflow Designer，信息工作者可以使用Office SharePoint Designer提供的稍简单的基于角色的方法。不管那种方式，最终都需要把工作流模板部署到运行Windows SharePoint Services的服务器上。本白皮书的后面部分将会详细描述如何创建工作流，所以现在，我们先假定工作流模板已经创建好了。

建立文档库/列表与工作流的关联

在使用工作流之前，必须首先把其安装到Windows SharePoint Services系统，然后将其关联至某一文档库、列表或者内容类型。这样，我们才可以 从文档库中的文档或者列表中的列表项发起这个流程。对于所有的列表项和文档，工作流的运行方式都是一样的，所以，我们既可以把工作流模板附加到文档库/列表，也可以把工作流模板附加到文档中的文档/列表中的项，尽管我们可以创建只与某一文档或者某一列表项相关联的工作流模板。由于不能直接从内容类型启动工作流，所以，与内容类型相关联的工作流可以从附加了此内容类型的文档或者列表项触发。

使用Office SharePoint Designer 创建的工作流，其安装和关联操作都是自动完成的，而用WF Workflow Designer和Visual Studio设计的工作流必须由Windows SharePoint Services服务器的系统管理员进行安装。安装完毕后，将工作流关联至某个文档库、列表或者内容类型，可以由权限低于系统管理员的某些角色完成。创建关联的人可以为关联指定一个唯一的名称，以备用户以后引用。或者，工作流的创建者可以授权创建关联的人员设定工作流的行为，比如指定参与流程的固定人员列表。一个工作流模板可以关联至多个文档库、列表或内容类型，可以根据需要自定义每个关联。关联创建好之后， 工作流发起者就可以创建工作流的实例。

发起工作流

在Windows SharePoint Services中，有3种方式可以发起流程，这3中方式每次都从头发起流程。(事实上，如果从某一关联发起的一个工作流实例正处于运行中，我们是不可能从相同的关联发起另外一个流程实例的。) 他们是：

n 由Windows SharePoint Services用户手工发起；

n 当有文档或者列表项发生更改时自动发起；

n 当有文档或者列表项被创建时自动发起；如，Microsoft Word用户将一篇新Word文档保存到站点的文档库中，这就触发与此文档库关联的工作流生成一个工作流实例。工作流发起者可以使用Microsoft Word 2007或更老版本，甚至也可以使用非Microsoft应用发起流程。

本示例使用第一种方式：手工发起流程。下面的截图显示文档库中的一个文档是如何呈现给Windows SharePoint Services用户的。要发起一个流程实例，用户只需要点击文档然后从菜单中选择Workflows即可。

选择后，将呈现下面的界面：

Start a New Workflow下面显示的是此文档可以发起的所有流程。在本例中，有2个流程—Approval 和ollect Feedback—如果系统管理员把其它的工作流也关联到此文档库，那么其它工作流的名称也会显示在这里。现在，发起者选择Approval，接着会看到下面的屏幕：

同前面看到的所有屏幕不一样，这个屏幕是工作流自己定义的。当流程启动时，可以选择性地显示一个屏幕，让用户指定一些相关信息。对于此处的Approval流程，这些信息包括审批者的名称、每个审批的审批期限，以及通知方。当用户提供这些信息后，点击屏幕右下方的Start 按钮，现在这个流程就会被执行，按照审批者的名称顺序依次发给审批者进行审批。

流程发起后，也可以有选择地给发起人一份邮件。类似地，当流程结束时也可以通过邮件通知发起人。在本例中，Approval工作流会在流程完成时通知发起人。也可以 在流程需要参与的时候通知流程的参与者，在本例中是指审批者。

与工作流交互

人员与工作流的交互是通过任务的方式进行设计的。一项任务是分派给某个人的任务的单元。在本例中，每个审批者都会被分派一项任务，要求他们对文档进行审批。Windows SharePoint Services维护每个站点的任务列表，每个运行中的工作流都可以向任务列表中添加任务，指定每项任务该由谁执行。站点的每个用户都可以通过Web浏览器或者通过同步站点任务列表和Outlook 2007任务列表看到那些待办事项。下图显示了通过浏览器方式访问任务列表的方式。

对于Windows SharePoint Services用户而言，待办任务仅仅是一个列表。如上图，用户从屏幕左面的选项中选择Tasks。当前用户只有一项待办事宜，即审批文档。用户可以通过屏幕右面的Link列访问文档。用户点击任务名称，弹出如下屏幕：

流程如何与参与者交互可以各种各样，因此，这个屏幕也是由流程本身定义的。在本例中，为流程参与者提供了输入备注信息的文本框以及选择同意或者否决的按钮。还有其它选项，如将任务转发给另外的用户或者发给发起者进行更改。在这里，用户输入备注信息，然后点击Approve 按钮，工作流接下来会在下一个审批者的任务列表中创建一项任务。等所有的参与者都执行完任务，流程就结束了。

Windows SharePoint Services工作流还提供了其它选项，包括：

n 流程发起者可以检查流程的状态。例如，在此处描述的示例中，发起者可以查看审批流程已经进行了多少。

n 流程执行过程中可以修改流程。允许修改哪些部分是由流程的设计者决定的。举例来说，此处的Approval工作流可以在执行过程中添加审批者。能够修改执行中的流程是非常重要的，因为这是人们真正的工作方式的反映。随时修改业务流程是不可避免的事实，所以Windows SharePoint Services工作流提供了这样的功能。

总结流程

Windows SharePoint Services工作流中有很多活动的部分，下图显示了工作流是如何工作的：

总结：安装工作流模板并把工作流模板关联到文档库、列表或者内容类型之后，并没有显示流程的任何一步，站点用户可以创建流传实例。流程的发起者选择文档和关联的工作流模板后，流程开始。这是第一步。然后流程发起者从关联创建工作流实例，这是第二步。然后定义流程实例并开发这个流程，这是第三步。

接下来，运行中的工作流实例在每个流程参与者的任务列表中添加任务。这是第四步。(虽然本例中使用的approval流程按照顺序派发任务，但实际的工作流也可能同时将任务派发给多个参与者，以并行方式执行任务。) 流程参与者可以通过检查任务列表查看任务，这是第五步。然后每个参与者与流程进行交互，完成任务，这是第六步。在本例中，即要求审批者审批文档，实际的工作流可以是流程创建者选择的任何操作。

值得注意的是，工作流所运行的文档本身并没有在人员中进行传递。相反，文档依然保存在站点中，每个流程都为参与者提供了对此文档的链接。事实上，工作流没有必要使用与其相关联的文档或者列表项。另外一点需要强调的是，在第一、二、五步中，流程发起者和参与者看到的界面是由Windows SharePoint Services本身定义的，而在第三、六步中使用的表单则是由流程创建者定义的。这就允许流程创建者控制用户如何与工作流进行交互。

除了提供了一个创建人员工作流应用的平台外，Windows SharePoint Services version 3 还提供了一个预定义的Issue Tracking工作流，最终用户可以拿来就用这个工作流。该工作流能够将活动的问题派发给参与者，然后跟踪问题的解决进度。发起Issue Tracking流程后，问题首先变为Resolved状态，表明该问题已经被相关的流程参与者解决了，然后再变为Closed状态，表明流程发起者已经接受了解决方案，并且关闭了该问题。

理解使用 Windows SharePoint Services工作流的基础是掌握该技术的一个重要部分，还有助于了解工作流的创建者如何创建工作流。下面的部分我们将讨论创建工作流的2中方式。

创建Windows SharePoint Services工作流

什么是Windows SharePoint Services工作流？ 简单说，工作流包括2个部分： 一是进行用户交互的流程表单，二是定义工作流行为的逻辑。要理解如何创建Windows SharePoint Services工作流需要了解这2方面的一些知识。

因为Windows SharePoint Services和用户通过Web浏览器通讯，所以它依靠ASP.NET显示表单。这些表单被定义为 ASPX页面。一个Windows SharePoint Services的工作流可以在流程生命周期中的4个地方显示自己的表单：

n 关联：When a Windows SharePoint Services administrator associates a workflow template with a particular document library or list, he might be able to set options that will apply to every workflow instance created from this association. If a workflow author chooses to allow this, she must provide a form that lets the administrator specify this information.

n 初始化：: The initiator of a workflow might be allowed to specify options when he starts a running instance. In the approval scenario just described, for instance, the options included specifying the list of workflow participants and defining how long each one had to complete his or her task. If a workflow allows this, its author must provide a form to allow the initiator to set these options, as shown in step 3 of the previous diagram.

n 完成任务：Task Completion: The running workflow instance must display a form to the participants in the workflow to let them complete their task. Shown in step <metricconverter productid="6 in" w:st="on">6 in</metricconverter> the previous diagram, this form is what allowed the approvers in the earlier scenario to make comments on the document and indicate their approval or rejection.

n 修改任务：Modification: Although it wasn’t shown in the scenario above, the creator of a workflow can allow it to be modified while it’s running. For example, a workflow might allow adding new participants after it’s begun executing or extending the due date for completing tasks. If this option is used, the workflow must display a form at this point to let a participant specify what changes should be made.

Workflows built solely on Windows SharePoint Services define their forms as ASPX pages, while those using Office SharePoint Server can also use forms created with InfoPath, as described later. In either case, a workflow’s logic is always defined as a group of activities, just as with any WF-based workflow. To specify the logic and forms for a workflow, Microsoft provides two different tools, each targeting a different audience. Software developers can use WF Workflow Designer hosted in Visual Studio 2005. Information workers, a less technical group, can use Office SharePoint Designer to create workflows without writing code. The next two sections examine how Windows SharePoint Services workflows can be created using each of these tools.

使用Visual Studio 2005 和WF Workflow Designer创建工作流

In many ways, a workflow is like a flowchart. Given this, it makes sense to provide a graphical tool that lets developers specify a workflow’s actions. For WF, this tool is Workflow Designer, part of Windows Workflow Foundation Extensions for Visual Studio 2005. Developers can use WF Workflow Designer to define graphically a workflow’s activities and the order in which those activities should be executed. The screen below shows a simple example of how this looks.

The activities available for use appear in the Toolbox on the left side of the screen. A developer can drag these activities onto the design surface to define the steps in a workflow. The properties of each activity can then be set in the Properties window that appears in the lower right corner.

WF’s Base Activity Library provides a group of fundamental activities, as described earlier. Windows SharePoint Services also provides a set of activities designed expressly for creating Windows SharePoint Services workflows. Among the most important of these are the following:

n OnWorkflowActivated: provides a standard starting point for a Windows SharePoint Services workflow. Among other things, this activity can accept information supplied by a Windows SharePoint Services administrator via the Association form when the workflow is associated with a document library or list. It can also accept information supplied via the Initiation form when the workflow is started. Every Windows SharePoint Services workflow must begin with this activity.

n CreateTask: creates a task assigned to a particular user in a task list. For example, the approval workflow in the scenario described earlier used this activity to add a task to the task list used by each of the participants. This activity also has a SendEmailNotification property that, when set to true, automatically sends an email message to the person for whom this task was created.

n OnTaskChanged: accepts information from the Task Completion form. The approval workflow in the earlier scenario used this activity to accept the input of each participant when the document was approved.

n CompleteTask: marks a task as completed.

n DeleteTask: removes a task from a task list.

n OnWorkflowModified: accepts information from the Modification form, which can then be used to change how this instance of the workflow behaves. If the workflow’s creator chooses not to include any instances of this activity in the workflow, that workflow cannot be modified while it’s running.

n SendEmail: sends email to a specified person or group of people.

n LogToHistoryList: writes information about the workflow’s execution to a history list. The information in this list is used to let users see where a workflow is in its execution, look at the workflow’s history after it’s completed, and more. To allow this kind of monitoring, the workflow’s author must write information to a History list at appropriate points in the workflow’s execution. Because it provides its own mechanism for tracking workflows, Windows SharePoint Services doesn’t support WF’s standard tracking service.

A typical pattern for a simple Windows SharePoint Services workflow begins with an OnWorkflowActivated activity, then uses a CreateTask activity to assign a task to a participant in the workflow. The BAL’s standard While activity might then be used to wait until the user completes the task. To learn when this has happened (perhaps the user makes multiple changes to the task, then checks a box on the Task Completion form when she’s done), an OnTaskChanged activity executes within the While, extracting whatever information the user has entered on that form. When the user has completed the task, a CompleteTask activity might execute, followed by a DeleteTask. The workflow can then go on to the next participant, using CreateTask to assign a task to him, and so on. And of course, other things can occur, such as sending email, logging information to the history list, or even including the BAL’s Code activity, which allows running arbitrary code.

All of the activities provided by Windows SharePoint Services are concerned with letting workflows operate within the Windows SharePoint Services environment. The business logic a workflow implements is entirely up to the creator of that workflow. In fact, a developer authoring a Windows SharePoint Services workflow is free to create and use her own custom activities—she’s not required to use only those provided by Windows SharePoint Services and WF.

As described earlier, Windows Workflow Foundation supports both sequential and state machine workflows. A Windows SharePoint Services workflow created with the WF Workflow Designer can also use either option. To allow this, Windows SharePoint Services adds two project types to Visual Studio 2005, one for each of these workflow styles.

Whatever style is chosen, the developer must define more than just the workflow’s logic; he must also specify the ASPX forms it should use. To do this, the developer relies on a file named workflow.xml. This file provides a template that the developer fills in to specify what form, if any, should be displayed at each of the four points at which a Windows SharePoint Services workflow is allowed to do this.

A developer must do some work to pass information between a Windows SharePoint Services workflow and the ASPX forms it uses. Windows SharePoint Services provides a namespace, Microsoft.Windows.SharePoint.Workflow, that exposes an object model for developers. Using the types in this namespace, the creator of a Windows SharePoint Services workflow can pass information from an ASPX form to the workflow and vice-versa.

Once a Windows SharePoint Services workflow and its forms have been created, the developer must package them into what Windows SharePoint Services version 3 refers to as a feature. A Windows SharePoint Services administrator must then install this feature, which includes installing the workflow’s assemblies to the target system’s global assembly cache. The new workflow will now be visible to the administrator as a workflow template that can be associated with a document library or list.

For a software developer, creating a Windows SharePoint Services workflow using Visual Studio and the WF Workflow Designer isn’t especially hard. The developer needs to understand the specifics of working in this environment, but much of what he’s doing will be familiar. Yet software developers aren’t the only people who’d like to author Windows SharePoint Services workflows. As described next, people who aren’t professional developers can also create workflows using Office SharePoint Designer.

使用Office SharePoint Designer 2007创建工作流

Office SharePoint Designer <metricconverter productid="2007, a" w:st="on">2007, a</metricconverter> separately licensed component of the 2007 Office system, allows information workers and others to add application logic (implemented as a workflow) to Windows SharePoint Services sites. This is certainly a useful goal, but Office SharePoint Designer also addresses another important problem. If a developer creates a Windows SharePoint Services workflow using Visual Studio, that workflow must be installed on a Windows SharePoint Services server like any other application. Yet many Windows SharePoint Services administrators won’t allow arbitrary code to be deployed on their servers, believing that the risk of destabilizing the system is too great. Being able to create straightforward business logic tied to documents and list items is very useful, however, and it’s something that many Windows SharePoint Services users need. Along with allowing less technical people to create workflows, Office SharePoint Designer also addresses this problem by providing a safer way to define and deploy business logic on Windows SharePoint Services servers.

The workflow scenarios that Office SharePoint Designer is intended to address are different in some ways from those addressed by Visual Studio and WF Workflow Designer. While it’s certainly possible to create complex applications, the intent of Office SharePoint Designer is to let users add business logic to Windows SharePoint Services sites. For example, suppose that a site contains a list that allows its users to submit change requests. Office SharePoint Designer could be used to create a workflow that automatically informs the submitter when her change request is accepted or rejected. Similarly, a custom workflow might inform a particular group of users whenever a new document is added to a particular document library. Performing this kind of custom notification isn’t complicated—creating the workflows is easy—but it’s challenging with earlier versions of Windows SharePoint Services because of administrators’ reluctance to install user-written code.

There’s an obvious question here: why should logic created with Office SharePoint Designer be treated any differently? What makes Windows SharePoint Services administrators willing to allow workflows built with this tool to be deployed on the systems for which they’re responsible? The answer is that workflows built with Office SharePoint Designer can only use activities from an administrator-controlled list. While a site’s administrator can choose to include custom activities created by a developer on this list, he’s not required to. By defining exactly what workflows are allowed to do, a Windows SharePoint Services administrator can have more confidence that deploying logic created using Office SharePoint Designer won’t destabilize his system.

Both because it’s intended for information workers rather than developers and because it emphasizes simpler scenarios, Office SharePoint Designer uses a different model for creating workflows than the Visual Studio-hosted WF Workflow Designer. Instead of a graphical approach, Office SharePoint Designer uses a rule-based approach. It’s somewhat similar to the Rules Wizard in Outlook, a tool that’s familiar to many people. The screen below illustrates how a user of Office SharePoint Designer defines a step in a workflow.

Each step can have a condition and an action. The condition determines whether this step’s action should be executed, as in the If statements shown above. The choices for actions include things such as assigning a To-do item to a workflow participant, sending email, and many more. Each of these actions is actually carried out by some Windows SharePoint Services activity, and the activities used here are the same as with Visual Studio and WF Workflow Designer. For example, the Send an Email option shown above corresponds to the SendEmail activity, while Assign a To-do Item corresponds to a slightly specialized version of the CreateTask activity. The list of actions can also include any other activities allowed by the Windows SharePoint Services administrator for this site, including custom activities created by developers.

Even though its user interface looks quite different from the graphical approach used with Visual Studio and WF Workflow Designer, Office SharePoint Designer creates a standard WF workflow. What’s actually produced is a sequential workflow with conditions expressed using the WF rules engine. Workflows created with this tool do have some limitations, however. For example, they can’t be modified while they’re running, unlike those built using Visual Studio and WF Workflow Designer, and only sequential workflows can be created—state machines aren’t supported. Also, workflows built with this tool must be authored against a specific document library or list when they’re designed. Creating a general workflow template that can later be associated with any library or list or with a content type isn’t possible. While this does place limits on how a workflow can be used, it also makes deploying the workflow much simpler. In fact, when a user finishes authoring a workflow with Office SharePoint Designer, the tool automatically deploys the workflow to the target site. This is significantly less complicated than the multi-step deployment process required for workflows created using Visual Studio and WF Workflow Designer.

Workflows created using Office SharePoint Designer can also display customized forms. Rather than require workflow authors to create ASPX pages directly, however, the tool instead generates those pages. The author specifies details about how the generated pages should look, such as what fields they should contain, and Office SharePoint Designer takes care of the rest. Of the four points in a Windows SharePoint Services workflow’s lifecycle where forms can be used, however, only two are used with workflows created using Office SharePoint Designer: Initiation and Task Completion. Because every workflow created with this tool must be associated with a particular document library or list, there’s no need for an association step and hence no Association form. And since these workflows can’t be modified while they’re running, there’s no need for a Modification form.

Office SharePoint Designer can be used for things other than creating Windows SharePoint Services workflows. The tool can be used to create a Windows SharePoint Services site, for example, or to customize the look and feel of a site’s pages by editing the site’s master page. It can also be used to connect to external data, something that relies on the data binding support in ASP.NET. For information workers who need to create logic that executes on a Windows SharePoint Services site, however, the most important aspect of Office SharePoint Designer is surely its support for authoring workflows.

Windows SharePoint Services provides a great deal of functionality for creating document-oriented workflows. Yet ultimately, it’s a platform for development and execution. On its own, it provides no workflow functionality that’s directly usable by end users. If what’s required is out-of-the-box workflow applications—and it often will be—Windows SharePoint Services isn’t enough. Workflows created using just Windows SharePoint Services also have other restrictions, such as the inability to interact with participants via Office client applications. As described next, Office SharePoint Server offers a way to overcome all of these limitations.

工作流和Office SharePoint Server 2007

The 2007 Office system includes new versions of the Office desktop applications, including Word, Excel, Outlook, and PowerPoint. It also includes a separately licensed suite of servers that address various areas. The member of this suite that’s most relevant to workflow is Office SharePoint Server 2007.

Office SharePoint Server supersedes earlier Microsoft products, including SharePoint Portal Server and Content Management Server, to provide a range of enterprise content management functions. These include several useful additions to the workflow capabilities built into Windows SharePoint Services. As in Windows SharePoint Services, all of these rely on Windows Workflow Foundation.

合并Windows Workflow Foundation, Windows SharePoint Services以及Office SharePoint Server

The workflow-related additions that Office SharePoint Server provides to Windows SharePoint Services can be grouped into three areas: support for Office 2007 clients, the ability for workflows to use forms created with InfoPath, and pre-defined workflows. This section looks at each of these three areas.

Workflows created using Windows SharePoint Services alone must use ASPX forms. Accordingly, the only way for people to interact with these workflows is via a Web browser. Yet the Office desktop applications are widely used, and many Windows SharePoint Services workflows will reference documents created with these applications. Why not allow users to interact with these workflows directly from Word, Excel, Outlook, and other Office applications?

Office SharePoint Server provides this ability. Rather than relying on a browser to communicate with users, a Windows SharePoint Services workflow running with Office SharePoint Server installed can display its forms directly in Office 2007 applications. For many workflows, this will allow a more natural interaction with users. A Windows SharePoint Services task list, for example, can be synchronized with the task list maintained by Outlook 2007, giving the user a single To Do list. Tasks can also be represented in Word 2007 documents, Outlook 2007 emails, and other ways, letting users input information to a running workflow directly from Office applications.

Displaying forms directly in Office applications requires some way to define those forms. The ASPX pages used by standard Windows SharePoint Services workflows will no longer suffice. To address this, Office SharePoint Server allows workflow authors to define forms using InfoPath 2007. For most people, these forms are easier to create than ASPX pages, and they can also provide capabilities such as built-in validation. It’s important to note, however, that the InfoPath-based forms used with a workflow, referred to in this paper as InfoPath workflow forms, provide only a subset of the capabilities offered by standard InfoPath forms. Much of the InfoPath object model isn’t available, for instance, as the focus is entirely on creating and using forms as part of workflows.

Letting workflow authors interact directly with Office applications through InfoPath workflow forms is certainly useful. Yet so far, everything described in this paper targets developers—there’s nothing that’s immediately usable by information workers. Office SharePoint Server changes this by including a group of pre-defined workflows. All of these workflows are meant to be used directly by information workers, and all can be customized to meet various requirements. The pre-defined workflows that Office SharePoint Server provides include the following:

n Approval: routes a document for approval. The workflow initiator specifies a list of approvers, each of whom can approve or reject the document, reassign the approval task, or request changes to the document. The example workflow scenario described earlier for Windows SharePoint Services was actually this pre-defined Approval workflow. (It’s worth noting that while the earlier scenario illustrated only aspects of Windows SharePoint Services, executing this pre-defined Approval workflow actually requires Office SharePoint Server. A developer could create a workflow that behaved exactly like the earlier scenario using only Windows SharePoint Services, however.)

n Collect Feedback: routes a document for review, much like the Approval workflow. Participants can provide feedback, which is compiled and sent to the document owner when the workflow has completed. Unlike Approval, which by default assigns tasks to participants sequentially, this pre-defined workflow defaults to parallel task assignment, allowing feedback to be returned in any order.

n Collect Signatures: routes an Office document for required signatures. This workflow can be started only from within an Office client.

n Disposition Approval: helps manage document retention by allowing participants to decide whether to retain or delete expired documents.

n Translation Management Workflow: helps manage the process of document translation. This workflow can be used to assign specific translation tasks to the participating translators, then track the progress of those tasks. It can also assign new translation tasks when a source document changes.

n Group Approval: implements a group-oriented approval process. This workflow is available only in East Asian versions of Office SharePoint Server.

All of these pre-defined workflows use InfoPath workflow forms, and so all allow access directly from Office 2007 applications.

Office SharePoint Server also provides other workflow-related services, including the ability to create reports on workflow history directly in Excel and support for bulk task completion, allowing a user to approve many outstanding tasks at once. The product provides a range of other functions as well, such as enhanced search, the ability to load, calculate, and render Excel spreadsheets on the server, and more. This large set of functionality is provided in two versions: a base edition and an enterprise edition. The product’s base edition includes the pre-defined workflows just described, but it doesn’t provide support for InfoPath workflow forms—users must interact with these workflows via a Web browser. The enterprise edition supports all of the capabilities described in this section, including using InfoPath workflow forms.

Office SharePoint Server工作流：示例

和前面一样，了解工作流在Office SharePoint Server 环境下是如何工作的最好方式是看看示例。本节将使用和Windows SharePoint Services 节中相同的工作流，即前面提及的Office SharePoint Server提供的预定义的Approval 工作流。在Windows SharePoint Services示例中，工作流与用户通过显示在Web浏览器中的ASPX表单进行交互，虽然这个例子也使用Office SharePoint Server，但所有的交互都将在显示在Office 2007应用中的InfoPath工作流表单进行。

再一次，先是安装工作流，然后是关联工作流到文档库、列表或者内容类型，忽略细节。最有趣的事情开始于流程发起者发起一个流程实例。如下图所示，发起操作可以直接从Word 2007文档中进行。如果用户安装了Office SharePoint Server，当点击Microsoft Office 按钮时就会看到Start Workflow选项。

选择该选项后将会弹出 Start New Workflow 屏幕，如下图：

和前面的示例一样，所有本文档已经关联的工作流都会显示出来。我们点击名称为Approval的工作流的Start 链接就可以发起这个流程。我们将看到如下的一个窗体（事实上，这是一个InfoPath窗体）。如前面的示例，这个预定义好的工作流允许发起者选择审批者，定义每个审批者的最长审批时间，等等。窗体下部的区域可以进行这些设定。

作为审批者的每个人员都将按照他们在名单中的顺序收到邮件通知。我们假定审批者适用Outlook 2007，那么邮件将如下所示：

审批者 可以通过点击邮件体中的文档名称链接检查文档。点击邮件顶部的Edit this task… 按钮(此处以红色框标注)可以看到下面的表单：

这是工作流的任务完成表单。该表单的内容与前面的Windows SharePoint Services示例中的一样。但是，这次这个表单定义为InfoPath工作流表单，并直接显示在Outlook 2007。象前面一样，审批者添加备注，然后同意或者否决该文档。

这个工作流的运作与Windows SharePoint S