针对开发人员的 Windows SharePoint Services V3 和 SharePoint Server 2007 工作流简介
Andrew May
Microsoft Corporation
适用于:
• | Microsoft Windows SharePoint Services(版本 3) |
• | Microsoft Office SharePoint Server 2007 |
摘要:关于 Microsoft Windows SharePoint Services(版本 3)如何实现 Windows Workflow Foundation 的工作流功能及 Microsoft Office SharePoint Server 2007 如何利用对称的 Microsoft Office InfoPath 2007 窗体来扩展这些功能的高级概述。
![*](http://img.microsoft.com/library/gallery/templates/MNP2.Common/images/3squares.gif)
本页内容
工作流简介
Microsoft Windows SharePoint Services 为用户提供稳健和可自定义的工作环境,以创建、协作和存储重要的业务信息。如今,利用 Microsoft Windows SharePoint Services(版本 3)和 Microsoft Office SharePoint Server 2007,可将自定义的业务进程附加于文档或列表项目。
可以使用工作流来展现这些自定义业务流程。工作流是组织并运行一组工作单元或活动的自然方式,用来构成工作流程的可执行表示。该流程几乎可以控制 Windows SharePoint Services 中项目的任何方面,包括项目的生命周期。工作流的灵活性极佳,可以模仿完成工作流所必需的系统功能和人员操作。
可以根据业务流程所需创建简单或复杂的工作流。可以创建用户启动的工作流,也可以创建 Windows SharePoint Services 根据某些事件(如创建或更改项目时)而自动启动的工作流。
假定您需要创建一个简单的工作流,将文档发布给一系列用户进行批准或备注。该工作流将包含系统需要执行的操作并为用户提供与工作流按指定方式进行交互的界面。例如,在准备检查文档时 Windows SharePoint Services 将发送一封电子邮件消息给所选的用户。这些用户在完成检查之后必须可以通知 Windows SharePoint Services,或者输入一些备注。使用包含在 Windows SharePoint Services V3 中并在 SharePoint Server 2007 中得到扩展的工作流框架,您可以模仿如此复杂的工作流进程并将其以一种简单易懂且便于接受的方式呈现给终端用户,指导他们完成每一步流程。
本文提供了工作流的高级概述,这些工作流在 Windows SharePoint Services 中得以实现并在 SharePoint Server 中得到扩展。本文讨论了开发人员在两种环境中创建工作流时可以使用的工具,以及这些工具各自的功能和优势所在。
工作流体系结构
在 Windows SharePoint Services V3 中的工作流功能构建于 Windows Workflow Foundation (WF) 之上,它是一种 Microsoft Windows 平台组件,为开发和执行基于工作流的应用程序提供编程基础结构和工具。WF 简化了异步编程的进程,以创建有状态、长时间运行及持久的工作流应用程序。WF 运行时引擎会管理工作流的执行,使工作流长时间保持活动状态,甚至在重新启动计算机时也不会受到影响。运行时服务提供了事务和持久性等功能,以适时而正确地管理错误。
WF 运行时引擎提供每一工作流应用程序所需的服务,例如排序、状态管理、跟踪功能及事务支持等。WF 运行时引擎可用作状态机,负责加载和卸载工作流以及管理所运行的任何工作流的当前状态。WF 允许任何应用程序进程或服务容器通过托管 WF(即,在其进程内部加载 WF)来运行工作流。
Windows SharePoint Services 托管 WF 运行时引擎。使用 WF 代替所包含的可插拔服务,Windows SharePoint Services 为引擎提供了以下服务的自定义实现:事务、持久性、通知、角色、跟踪和消息传送。然后,开发人员即可创建在 Windows SharePoint Services 内部运行的工作流解决方案。
图 1 显示了 Windows SharePoint Services 中的工作流体系结构。Windows SharePoint Services 在其进程内部托管 WF 运行时引擎,并提供必要服务的自定义实现。WF 运行时引擎的功能以及 Windows SharePoint Services 提供的托管功能,通过 Windows SharePoint Services 对象模型得以实现。
![.](https://i-blog.csdnimg.cn/blog_migrate/b017ab90b571767639ac56af15b9352b.png)
图 1. Windows SharePoint Services V3 中的工作流体系结构
Windows Workflow Foundation 还提供了 Visual Studio 2005 Designer for Windows Workflow Foundation,它是一种在 Microsoft Visual Studio 2005 开发系统内部托管的加载项,开发人员可用其创建自己的自定义工作流和工作流活动。有关详细信息,请参阅在 Visual Studio 2005 中编写 SharePoint 工作流。
SharePoint Server 借用了 Windows SharePoint Services(版本 3)中的工作流功能,并通过与 InfoPath 窗体和其他工作流活动相集成而扩展了该功能。在 SharePoint Designer 2007 中编写 SharePoint 工作流对此做了更为详细的论述。
Windows Workflow Foundation 运行时引擎作为 Microsoft Windows Workflow Foundation Runtime Components Beta 2.2 and Visual Studio 2005 Extensions for Windows Workflow Foundation Beta 2.2(英文)的一部分,可从 Microsoft 下载中心获得。此下载还包含 Visual Studio 2005 Designer for Windows Workflow Foundation 以及 Windows Workflow Foundation Software Development Kit (SDK)。
既然已经对 Windows SharePoint Services 中所提供的工作流基础结构做了简短描述,接下来让我们开始研究 WF 工作流自身的内部组成和结构。之后,我们将要看看 Microsoft 为开发人员创建 Windows SharePoint Services 和 SharePoint Server 2007 的工作流解决方案所提供的各种工具。
工作流持久性
Windows SharePoint Services 向 WF 工作流引擎所提供的一个最重要服务是持久性。包含人员交互的工作流必须可以长时间运行;即使在理想的环境下,与计算机相比人们也需要相对较长的时间才能完成工作。在许多 Microsoft Office 方案中,如果不是很长工作流,一般需要几天的时间。以发布供批准的文档的工作流为例。批准人可能需要几天的时间来检查文档。
很明显,在其执行的整个持续时间内将每一个运行中的工作流均保留在内存中是不切实际的;不断累积的长时间运行工作流所需的资源很快就会使系统停止。
因此,在工作流实例到达等待用户输入的时候,Windows SharePoint Services 会从内存中卸载该工作流实例而保留其数据。然后,在某一合适的事件(如用户输入数据)需要工作流实例再次启动时,Windows SharePoint Services 会使用所保留的数据重新创建工作流实例,因此工作流实例可根据需要接收和处理事件。
尽管在某任意时刻可能有大量工作流实例在运行,但其中只有一小部分可能存在于内存中并使用系统资源。
工作流类型
Windows Workflow Foundation 支持两种基本的工作流类型:
• | 顺序工作流 将工作流显示为一系列按顺序执行的步骤,直到最后一个活动完成。不过,顺序工作流不会完全遵照它们的执行顺序。因为它们可以接收外部事件且包含并行逻辑流,因此活动执行的准确顺序可能会有所变化。 |
• | 状态机工作流 显示一组状态、转换和操作。将某状态表示为开始状态,然后根据某一事件进行某种转换,使其成为另一种状态。状态机可具有确定工作流结束的最终状态。 |
可以为 Windows SharePoint Services 和 SharePoint Server 创建任一类型的工作流。
顺序工作流
顺序工作流可以用图形的方式很好地表示为操作流程图:有开始、结束和从开始至结束的顺序流方向。顺序工作流可以合并诸如重复、循环和并行分支这样的流结构,但最终还是按照从开始操作至结束操作来前进的。
例如,假定您要制定一张简单的工作流图表,该工作流在 Windows SharePoint Services 中分布供批准的文档。在工作流开始时,系统会通过电子邮件消息通知特定的检查人员有一个文档要进行检查。检查人员会检查该文档并通知系统任务已完成,无论该人员批准还是拒绝文档。根据检查人员的响应,工作流会执行两个并行分支中的一个。如果检查人员批准文档,则系统会将批准文档移动至一特定的 SharePoint 文档库,然后发送一条电子邮件消息给整个团队,通知他们此批准文档。如果检查人员拒绝此文档,则系统会通知文档作者。无论哪种情况,工作流都会到达其结尾并停止。图 2 显示了此工作流。
![.](https://i-blog.csdnimg.cn/blog_migrate/118a3d1e80ccd586833e11c3bb726fca.png)
图 2. 顺序工作流的概念图表
状态机工作流
与顺序工作流不同,状态机工作流没有预定的执行流,也不需要结束。相反,状态机工作流可定义项目可能具有的任意数量状态,还可定义将项目从一种状态转换至另一种状态的任意数量事件。
图 3 显示了一个简单的文档发布进程,采用状态机工作流建模。创建文档时工作流启动,文档状态设置为完成时结束。不过,在这期间,文档不会按预定的路径进行,而是根据事件的发生在各状态间进行转换。
状态机工作流由状态活动构成。每个状态活动表示一种项目的状态。每个状态活动均可包含可选的状态初始化、状态定案和一个或多个事件处理程序。每个事件处理程序活动可处理一个事件。在响应所处理的事件时,某进程处理可能完成,因此可转换到另一状态。
![.](https://i-blog.csdnimg.cn/blog_migrate/70cc4742a04fe11612155fc4f2bd0989.png)
图 3. 状态机工作流的概念图表
顺序工作流和状态机工作流的一个共同特点是每种类型的工作流均可以打断为离散操作(即,一部分操作由系统执行,一部分操作由用户执行)的集合。可以认为这些操作是工作流的构建块。在 WF 工作流中,这些操作称为活动。。
工作流组成
早期定义的工作流作为组织并运行一组工作单元或活动的方式用来构成工作流程的可执行表示。因此,每个 WF 工作流由一组相关活动构成。在 Windows Workflow Foundation 中,活动是建模、编程、重用和执行的基本单元。活动可由系统或用户来执行。例如,系统可以向某人发送电子邮件消息作为警告;或某人可以批准文档的分发。
从概念上说,我们连续的工作流示例包括 5 个活动:
• | 发送电子邮件消息来通知批准人 |
• | 批准或拒绝文档 |
• | 将文档移动到“经批准的”文档库 |
• | 发送电子邮件消息来通知团队 |
• | 发送电子邮件消息来通知文档作者 |
活动还可表示定义工作流范围并控制工作流的执行流的逻辑控制结构,与代码逻辑控制(如,If Then 和 Do While 循环)十分类似,能够控制代码中的程序流。
活动可以具有属性、方法和事件。简单活动执行工作的单一单元,如“延时 1 天”或“调用 Web 服务”。复合活动包含其他活动;例如,带有两个分支的条件。还可以向活动附加处理程序,如,错误或补偿处理程序。特别建议将其用于复合活动。
实际上,工作流本身就是一个复合活动,其包含了工作流中的所有其他活动。
因此,可将工作流视为作为描述实际过程的模型存储的一组活动。工作从开始到结束遍历该模型,活动可由人或系统功能执行。工作流提供了一种方式来描述执行顺序以及多个短时运行工作或长时运行工作之间的依赖关系。
Windows Workflow Foundation 包括若干预定义的活动,可用于您的工作流,您也可以创建自己的自定义活动。Windows SharePoint Services 工作流项目模板包包含了大量的活动,明确设计用于 Windows SharePoint Services 环境。此模板包还包含针对 Windows SharePoint Services 对象模型进行编程所必须的参考。类似地,对 SharePoint Server 项目模板包进行自定义,以用于 SharePoint Server 环境。有关详细信息,请参阅在 Visual Studio 2005 中编写 SharePoint 工作流。
工作流标记
每个 WF 工作流可由以下文件的组合来表示:
• | 包括工作流的声明性元数据的 XML 文件或标记文件 |
• | 与包含表示工作流属性和行为的自定义代码的 code-behind 文件结合使用的标记文件 |
• | 包括工作流的声明性逻辑和行为的代码文件 |
标记文件以可扩展应用程序标记语言 (XAML) 编写而成,该语言具有文件必须遵守的已发布架构,且考虑到了 .xoml 文件扩展。
因为 XAML 具有已发布的架构,所以可以选择使用任何文本编辑器或 XML 编辑器创建 XAML 文件。不过,本文章中所讨论的两个工作流编写工具 Visual Studio 2005 Designer for Windows Workflow Foundation 和 Microsoft Office SharePoint Designer 2007 为开发人员提供了图形界面,可在其中创建工作流并自动生成合适的标记文件。
开发人员可以从工作流中包括的业务逻辑中选择集成或分离其声明性元数据。从概念上说,WF 工作流使用的“代码分离”模式与 Microsoft ASP.NET 中所使用的类似:声明性元数据与封装业务逻辑的文件分离。所以,尽管标记文件包含用于工作流中所包括的活动的元数据,这些活动的属性和行为仍在分离的文件中详细列出。
对于使用代码分离编写的工作流,信息如之前所述仍保存在标记文件中,且以如下两种文件类型之一保存:
• | 包含封装业务逻辑的代码的 code-beside 文件。该文件可以 Microsoft Visual C# 或 Microsoft Visual Basic .NET 进行编写。 |
• | 以声明性规则而非代码封装业务逻辑的工作流规则文件。 |
以此方式创建的每个工作流实际是一个唯一的 Microsoft .NET 类型,构造于两个局部类,这两个类以 XOML 和 code-behind 或规则文件进行表示。对工作流项目进行编译后,这两个局部类被结合到 .NET 程序集中。以上即为通过使用 Visual Studio 2005 Designer for Windows Workflow Foundation 为 Windows SharePoint Services 或 SharePoint Server 编写工作流时所采用的方法。
仅由代码文件组成的工作流遵守相同的常规编译过程,即,代码文件被编译到 .NET 类型中。
此外,还可编译仅由标记文件组成的工作流。但这不是必要的;WF 运行时引擎可加载并运行未编译的标记工作流。以上即为通过使用 SharePoint Designer 2007 为 Windows SharePoint Services 或 SharePoint Server 编写工作流时所采用的方法。
Windows SharePoint Services 和 SharePoint Server 2007 中的工作流
迄今为止,我们已讨论了实现 Windows Workflow Foundation 的任何应用程序的工作流属性。现在,让我们深入研究专门在 Windows SharePoint Services 中实现的工作流并讨论该实现的某些重要方面。
工作流模板和实例
在 Windows SharePoint Services 中,站点或列表上提供的工作流称为工作流模板;实际运行于特定 SharePoint 项目上的工作流称为工作流实例。所以,在给定的列表上,同一工作流模板的多个实例可以同时运行,每个实例运行在不同的 SharePoint 项目上。每次,可以有多个工作流运行在给定的 SharePoint 项目上。
可以在文档或列表项上运行工作流。可以通过称为“关联”的过程使工作流模板在站点上可用,本文章稍后将进行讨论。
使用窗体来启用用户与 Windows SharePoint Services 的交互
尽管可以使用 Windows SharePoint Services 工作流建模任意数量的唯一业务流程,但仍提供了多个公共阶段,其中用户可以与工作流模板或实例交互。
为了使用户向工作流传递信息,开发人员必须通过使用窗体为此交互提供一个接口。向工作流添加窗体将使得工作流更加动态、灵活。窗体使您能够在工作流生命周期的预定义时间从用户收集信息,并使用户能够与针对该工作流的任务交互。
从技术上说,可以将任何窗体技术用于 WF 工作流,只要窗体能够执行以下操作:
• | 调用 Windows SharePoint Services 对象模型 |
• | 生成发送到 Windows SharePoint Services 对象模型所需的数据 |
• | 接收并分析来自 Windows SharePoint Services 对象模型的所需数据 |
任何在加载中传递给窗体的信息均转换为字符串,因为用户提交窗体时,窗体必须将该数据传递回 Windows SharePoint Services V3 对象模型。尽管该字符串通常为 XML,但仍可以使用任何可转换为字符串的数据格式,只要窗体能够生成该格式的字符串并分析其收到的字符串。
Windows SharePoint Services 支持使用 ASP.NET 2.0 窗体。如何实现这些窗体将取决于开发人员所使用的工作流编写工具,即 Visual Studio 2005 Designer for Windows Workflow Foundation 或 SharePoint Designer 2007。此外,SharePoint Server 2007 使得开发人员能够将 Microsoft Office InfoPath 窗体与其工作流进行集成。这些 InfoPath 窗体可以在 Microsoft Office 客户端应用程序(例如 Microsoft Office Word、Microsoft Office PowerPoint、Microsoft Office Excel 和 InfoPath)以及客户端浏览器内进行托管,并提供了更丰富的客户端体验。有关每个工作流编写工具如何实现工作流窗体的详细信息,请参阅 Windows SharePoint Services 工作流中的 ASP.NET 窗体、SharePoint Server 工作流中的 InfoPath 窗体和 SharePoint Designer 工作流中的 ASP.NET 窗体。
无论使用何种窗体技术,每个窗体的概念操作均相同。Windows SharePoint Services 在工作流的合适结合点向用户显示窗体。用户输入信息并提交窗体。
作为工作流开发人员,您有责任对用户提交窗体后将发生的情况进行编程处理。多数情况下,窗体会调用 Windows SharePoint Services 对象模型并调用合适的方法来向正确的工作流实例传递窗体信息。
如果对窗体和工作流活动进行编程以分析该字符串,信息字符串可以是任何格式。多数情况下,开发人员可能会选择使用 XML。
Windows SharePoint Services 将字符串信息传递给 WF 运行时引擎、工作流实例,最终传递给工作流实例内的正确活动。活动接收到信息后会按编程预定的方式响应。图 4 显示了窗体集成工作流的方式。
![.](https://i-blog.csdnimg.cn/blog_migrate/93d5a279ca70693c2819b5c00da4e8c3.png)
图 4. 窗体集成工作流
Windows SharePoint Services 工作流中使用了如下三种类型的窗体:
• | 关联和初始化窗体 关联和初始化窗体为用户在任何工作流实际启动之前进行填充而显示。通过这些窗体用户可以在工作流启动前设置工作流的参数和其他信息。 |
• | 修改窗体 修改窗体为提供给用户的可选项,以在工作流运行在某项目上时对其进行更改。随后可以创建修改窗体使用户能够指定修改的参数。 |
• | 任务窗体 基于工作流任务类型,还可以在您的工作流中为任务指定自定义窗体。Windows SharePoint Services 中的每个工作流任务类型均分配了一个内容类型;内容类型定义确定了是否为给定的工作流任务类型指定自定义窗体。 |
上述三种类型的窗体表示预定义阶段,其中用户可以与工作流进行交互。接下来我们将讨论这些阶段。
用户与工作流交互的要点
让我们深入研究一下各个阶段,其中用户可以与 Windows SharePoint Services 和 SharePoint Server 中的工作流进行交互。
关联
站点管理员在特定文档库、列表或内容类型上提供了工作流模板时将发生关联。在此阶段,站点管理员为特定文档库、列表或内容类型自定义工作流,方法为指定以下参数信息:
• | 工作流的唯一名称 |
• | 工作流应用于给定项目的方式:创建或更改项目时为自动,或为手动;可启动工作流的角色,如管理员或参与者 |
• | 工作流在其中创建任务的任务列表 |
• | 工作流在其中存储由工作流定义的历史事件的历史列表 |
此外,工作流开发人员使得网站管理员能够通过设置针对特定工作流的参数信息来进一步自定义工作流。该管理员可能需要为工作流指定参数、默认值及其他信息,以便工作流适用于管理员将其关联的列表、库或内容类型上的项目。
关联工作流实际发生在工作流自身的外部;关联期间实际上没有启动任何工作流实例。而是,Windows SharePoint Services 将关联信息存储在专门的内部工作流关联表格中。然后,在工作流实例实际启动时,Windows SharePoint Services 使用关联数据(以及初始化数据,如果有)来设置新工作流实例的参数。
初始化
关联处理适用于特定列表、库或内容类型的工作流,而初始化处理适用于特定 SharePoint 项目的工作流。
用户在特定项目上实际启动工作流实例后,发生初始化。必要时,用户提供该项目上的特定工作流的自定义信息,然后启动工作流。
工作流开发人员可使用初始化使得用户可以覆盖或附加管理员设置的关联参数,或指定其他有关适用于给定的 SharePoint 项目的工作流的参数或信息。并非所有工作流均需要初始化。实际上,设置为自动启动的工作流不能包含初始化参数。
用于 Visual Studio 2005 Designer for Windows Workflow Foundation 的 Windows SharePoint Services 工作流项目包括一个活动,该活动作为初始化工作流时的事件处理程序。该活动是任何 Windows SharePoint Services 工作流中的首个活动。
修改
修改使得用户可以改变正在运行的工作流实例的参数或流程。作为开发人员,您可以在工作流中设置多个点,通过它们使得用户可以在工作流运行在项目上时,对其进行修改。例如,您可能希望使得用户可以为其他人分配任务,或者甚至可以向工作流添加特定任务。为用户提供的以在工作流运行在某项目上时对其进行更改的选项称为修改。
用于 Visual Studio 2005 Designer for Windows Workflow Foundation 的 Windows SharePoint Services 工作流项目包括一个启用工作流修改的活动,以及一个启用工作流修改时作为事件处理程序的活动。
任务
由用户所执行的工作流活动表示为 Windows SharePoint Services 工作流中的任务。
作为工作流作者,您可以指定任务架构。例如,任务列表可包括以下各项:
• | 任务标题 |
• | 任务分配到的用户的名称 |
• | 任务状态 |
• | 任务优先级 |
• | 任务截止日期 |
• | 到引用项目的链接 |
随后用户可以根据需要编辑任务。工作流实例会收到工作流任务更改的通知并可以按工作流中指定的方式选择对其进行响应。
用于 Visual Studio 2005 Designer for Windows Workflow Foundation 的 Windows SharePoint Services 工作流项目包括创建、删除及更新任务的活动,以及创建、更新或删除任务时作为事件处理程序的活动。
编写 SharePoint 工作流
Microsoft 为 Windows SharePoint Services 提供了两种用于编写工作流的开发工具:Visual Studio 2005 Designer for Windows Workflow Foundation 和 Office SharePoint Designer 2007。由于每种编写工具所生成的工作流分别具有不同的属性和功能,因此需要仔细检查每种工具。
图 5 显示了使用每种编写工具创建、部署、关联和运行工作流时需要执行的不同步骤。通常,这两种工具之间的最大差别在于:
• | Visual Studio 2005 Designer for Windows Workflow Foundation 中的工作流编写由专业开发人员执行,由其创建可跨多个站点部署并含有自定义代码和活动的工作流模板。开发人员然后将该工作流模板传给服务器管理员进行实际部署和关联。 |
• | SharePoint Designer 中的工作流编写适于某些非专业的开发人员来完成,如,想要为特定列表或文档库创建工作流的 Web 设计者或知识工作者。此时,设计者将局限于安全控件列表上的工作流活动,同时该工作流不能包括自定义代码。在工作流编写过程中,工作流编写者会将工作流模板直接部署到列表或文档库中。 |
有关这两个工具功能的详细比较,请参阅比较 Visual Studio 2005 Designer for Windows Workflow Foundation 和 SharePoint Designer 2007。
![.](https://i-blog.csdnimg.cn/blog_migrate/195f3189112e0e601a50fa7c4e39b791.png)
图 5. 工作流编写、部署和初始化进程
在 Visual Studio 2005 中编写 SharePoint 工作流
Visual Studio 2005 Designer for Windows Workflow Foundation 是 Visual Studio 2005 的一个加载项,它提供了通过使用图形界面来快速开发工作流的方法,其中利用了开发人员关于 Visual Studio 开发环境的知识。
Visual Studio 2005 Designer for Windows Workflow Foundation 是一个可供您按照与用于封装业务流程的代码开发相集成的方式来快速创建工作流的工具。为此,Visual Studio 2005 Designer for Windows Workflow Foundation 提供了一个包含直观控件的图形界面,该界面托管于常用的 Visual Studio 开发环境中。其功能包括:
• | 一个拖放式画面,允许通过您从“Toolbox”(工具箱)中拖出的预定义工作流活动集合自定义工作流 |
• | 允许您使用直观图形工具来处理工作流标记的界面 |
• | 与“Properties”(属性)窗口集成,因此开发人员可通过图形界面或直接在 code-beside 文件中配置工作流活动的属性,并使得这两者始终保持同步 |
• | 通过附加到 Windows SharePoint Services 进程调试您的工作流,包括在工作流中设置断点 |
• | 能够为活动附加错误、补偿和事件处理程序,并能够以图形方式“注释掉”活动 |
Microsoft 下载中心的 Microsoft Windows Workflow Foundation Runtime Components Beta 2.2 and Visual Studio 2005 Extensions for Windows Workflow Foundation Beta 2.2(英文)中提供了 Visual Studio 2005 Designer for Windows Workflow Foundation。此下载中还包含 Windows Workflow Foundation 运行时引擎以及 Windows Workflow Foundation SDK。
为进一步协助您的工作流开发,Microsoft 还提供了两个 Visual Studio 项目模板包,以与 Visual Studio 2005 Designer for Windows Workflow Foundation 一同使用:一个是针对 Windows SharePoint Services 工作流而定制,另一个是针对为 SharePoint Server 创建工作流而定制。
Windows SharePoint Services 工作流项目模板含有对 Windows SharePoint 命名空间的引用,并包括专门针对 Windows SharePoint Services 环境而设计的自定义工作流活动。通过这些自定义活动,您能够执行 Windows SharePoint Services 环境的一些常用功能,如创建、更新、完成和删除 SharePoint 任务以及发送电子邮件和启用工作流修改。
SharePoint Server 工作流项目含有 Windows SharePoint Services 工作流项目模板中的一切内容,以及对 SharePoint Server 命名空间的引用和其他用于在 SharePoint Server 工作环境中管理工作流任务的功能。
Visual Studio 中的工作流开发过程
通常,在使用 Visual Studio 2005 Designer for Windows Workflow Foundation 为 Windows SharePoint Services 或 Office SharePoint Server 开发工作流时,需执行以下基本步骤:
1. | 在 Visual Studio 2005 Designer for Windows Workflow Foundation 中编写工作流,包括 code-beside 文件(如果需要)。 |
2. | 设计并发布要与工作流一同使用的任何窗体。 |
3. | 编写功能定义和工作流模板定义文件,其中包含工作流程序集的相关信息,并将窗体绑定到工作流程序集。 |
4. | 将工作流文件编译为 .NET 程序集。 |
5. | 将工作流程序集和工作流定义打包在一起,并使用 Windows SharePoint Services 中的功能对其进行部署。 |
6. | 使用 Visual Studio 2005 Designer for Windows Workflow Foundation 调试活动的工作流程序集。 |
7. | 根据需要重新编译和部署工作流程序集以修复发现的所有错误。 |
以下部分概述了其中的每一个开发步骤。
使用 Visual Studio 2005 Designer for Windows Workflow Foundation 创建工作流
选择新的 Windows SharePoint Services 或 Office SharePoint Server 工作流项目时,Visual Studio 将显示 Visual Studio 2005 Designer for Windows Workflow Foundation 设计画面(图 6)。此设计画面提供了一个图形界面,在其中可通过从“Toolbox”(工具箱)中拖放各种活动来集合工作流。
![.](https://i-blog.csdnimg.cn/blog_migrate/0bf7a5bb2d9d3990b92f254476ceadc7.png)
图 6. Visual Studio 2005 Designer for Windows Workflow Foundation 界面
在将某个特定活动拖到工作流上时,Visual Studio 2005 Designer for Windows Workflow Foundation 将向您显示该活动在此工作流中的有效位置。您不能将活动放置在对于它无效的位置中。例如,不能将 Send 活动作为 Listen 活动分支中的第一个活动来放置。如图 7 中所示,Visual Studio 2005 Designer for Windows Workflow Foundation 通过显示绿色的加号图标来指示特定活动的有效位置。
![.](https://i-blog.csdnimg.cn/blog_migrate/12c90e185e0ad73de78d865647e10954.png)
图 7. 工作流活动的有效位置
在以图形方式设计工作流时,Visual Studio 2005 Designer for Windows Workflow Foundation 实际上会生成对应的标记。
此外,如果要使用代码分离,工作流项目中会包含一个 code-behind 文件,可在其中编写工作流的业务逻辑。需要时,可在工作流设计画面和 code-beside 文件之间进行操作切换。
设置工作流属性
向工作流添加活动后,只有为该活动设置属性,其才会在工作流中有效。可使用标准的 Visual Studio“Properties”(属性)窗口来设置这些属性。可指定的数据类型取决于属性自身所接受的数据类型:文字值、变量或方法名。
如果要为属性指定变量,可使用两种方法:一种是在“Properties”(属性)窗口中输入变量名,此种情况下,Visual Studio 2005 Designer for Windows Workflow Foundation 会在 code-behind 文件中自动声明该变量;另外一种是在 code-behind 文件中声明变量,然后在“Properties”(属性)窗口中将其选中。
有些活动属性实质上是对符合特定签名的 code-beside 文件中方法的引用。与变量名一样,您可在“Properties”(属性)窗口中输入方法名,然后让 Visual Studio 2005 Designer for Windows Workflow Foundation 将方法签名添加到 code-behind 文件中,或者,可在 code-behind 文件中创建方法,然后在“Properties”(属性)窗口中将其选中。
还可将某个属性绑定到其他活动的属性。
处理程序活动
工作流可能具有多个潜在的故障点。跟踪工作流的状态并在发生错误时进行报告是很重要的,这样便能够准确地解决问题,且花费的代价最少。就工作流而言,保持一组密切相关的操作的完整性同等重要,这样,在某个操作的一部分发生而另一部分却没有时,可将整个操作回滚。可使用 FaultHandlerActivity、TransactionScopeActivity、CompensationHandlerActivity 和 CancellationHandlersActivity 活动处理错误以维护工作流的状态,并在问题发生时加以修复。
您可将 FaultHandlersActivity 活动视为 C 语言的 try 块,并可向其附加相当于异常处理程序的 FaultHandlerActivity 活动的有序集合。可将这些异常处理程序视为 C 语言的 catch 块。如果在执行复合活动期间引发异常,则 WF 运行时引擎会将此异常与 FaultHandlerActivity 活动所处理的异常类型进行匹配。如果运行时引擎未发现匹配的异常处理程序,则将此异常传递到下一更高级别的复合活动,在其中重复此过程,以此类推,直至找到相应的处理程序。
您也可拥有用于响应事件的 EventHandlersActivity 活动,方法是向 EventHandlerScopeActivity 活动添加事件处理程序。从概念上讲,这些事件处理程序与 C 或 Visual Basic .NET 语言中的处理程序非常相似。要创建事件处理程序,必须使用 EventDrivenActivity 活动。
CompensationHandlerActivity 活动含有用于补偿或回滚复合活动的操作的代码(如果该活动未成功执行)。
Windows SharePoint Services 工作流中的 ASP.NET 窗体
如前文所述,您可以使用 ASP.NET 来创建要与 Windows SharePoint Services 工作流一起使用的窗体。随后,在工作流的适当阶段,这些窗体会显示在 Windows SharePoint Services 用户界面中。
通过您在工作流模板定义 XML 文件中所提供的信息,工作流窗体会被后期绑定到工作流程序集中。工作流模板定义架构包含一些元素,它们用于指示可与 Windows SharePoint Services 工作流一起使用的各种窗体的 URL。因此,可为用于任何自定义工作流修改的窗体以及用于工作流中所使用的各种 SharePoint 任务的窗体创建元素。
多数情况下,工作流程序集自身不包含任何与工作流窗体本身相关的信息。开发人员只需编辑工作流定义 XML(而不必一定重新编译工作流程序集本身)便可更改要使用的工作流窗体。工作流修改是一个例外;实现工作流修改的每个活动必须包含用于该工作流修改的窗体的 GUID。
SharePoint Server 工作流中的 InfoPath 窗体
尽管也可以在 SharePoint Server 工作流中使用 ASP.NET 工作流窗体,但 SharePoint Server 能够让您扩展工作流窗体并在 Microsoft Office 客户端应用程序中显示这些窗体。
可将 InfoPath 窗体与工作流一起使用。可通过 InfoPath 创建对称窗体,即,无论这些窗体是显示在 SharePoint Server Web 界面中还是显示在 Microsoft Office 客户端应用程序(如 Word、Excel 或 PowerPoint)中,它们的外观和操作均完全相同。这就提供了更加丰富的交互体验,用户可直接在客户端应用程序中与工作流交互,而不必离开客户端并切换到 SharePoint Server Web 界面。而且作为开发人员,您不必创建两个独立的窗体(一个用在服务器上,另一个用在客户端中)来为用户提供客户端应用程序集成。
有关创建常见对称窗体的详细信息,请参阅 Microsoft Office InfoPath 2007 客户帮助或 Office Online。
Office Forms Services 是适用于 InfoPath 窗体的基于服务器的运行时环境,SharePoint Server 使用它来托管工作流窗体。Office Forms Services 使用您在 InfoPath 客户端应用程序中所创建的窗体,并将这些窗体显示在 ASP.NET 框架中,ASP.NET 框架相当于窗体的运行时环境。此环境提供与 InfoPath 客户端应用程序相匹配的窗体编辑体验。
有关 Office Forms Services 的详细信息,请参阅 Microsoft Office SharePoint Server 2007 SDK。
注意 由于 Office 2007 客户端应用程序(如 Word、PowerPoint 和 Excel)具有托管 InfoPath 窗体的功能,因此用户不必安装 InfoPath 客户端应用程序来利用其丰富的集成。
显示 InfoPath 工作流窗体
SharePoint Server 使用相同的基本技术来显示所有自定义 InfoPath 工作流窗体,包括关联、初始化、修改或编辑任务窗体。
当用户在 SharePoint Server 界面中单击链接来显示某个工作流窗体时,SharePoint Server 会加载一个 ASPX 页面,其中包含 Office Forms Services Web 部件。此 Web 部件随后会将相应的 InfoPath 窗体转换成 ASP.NET 并将其加载。当用户提交该窗体时,Web 部件会收到窗体中的数据并相应地对其进行处理。
SharePoint Server 中包括其中包含 Office Forms Services Web 部件的 ASPX 页面。
指定 InfoPath 工作流窗体
此外,在工作流模板定义(而非工作流自身)中指定您要使用的自定义窗体。多数情况下,这涉及到设置两个元素。首先,将该工作流进程(关联、初始化、修改等)的窗体 URL 设置为 SharePoint Server 中包含的适当的 ASPX 托管页面。接下来,添加一个元素,用来为该类型工作流进程指定自定义 InfoPath 窗体的 URN。
通过使用 InfoPath 工作流窗体提交信息
为了使托管 ASPX 页面接收到被托管窗体中的数据,开发人员在 InfoPath 窗体中添加了一个“Submit”(提交)按钮。通过借助到托管环境的数据连接,此按钮使用某个规则来提交数据。当用户单击“Submit”(提交)按钮时,此连接会自动将数据传递回托管 ASPX 页面中。随后,托管 ASPX 页面会对数据分析进行处理,并根据需要将其传递回工作流或文档库。
部署工作流
完成对工作流的指定后,您可以选择将工作流作为工作流或是作为活动来进行编译。
完成对工作流的编译后,您可使用 SharePoint Features 功能来打包和部署工作流程序集以及任何必需的支持文件。
功能打包是一种为了便于部署而封装 Windows SharePoint Services 解决方案和功能的方式。开发人员可根据它所提供的机制来打包解决方案(如工作流、Web 部件、列表和站点定义)所需的文件,以便于分布和部署。开发人员将所需文件打包为 .wsp 文件,该文件实质上是一个 .cab 文件,其中包含列有所含内容的清单。有关 SharePoint Features 的详细信息,请参阅 Windows SharePoint Services V3 SDK。
您部署的每个工作流模板必须包含一个工作流模板定义文件。工作流模板定义是一个 XML 文件,它包含 Windows SharePoint Services 实例化和运行工作流时所需的信息,诸如以下内容:
• | 工作流模板的名称、GUID 及描述 |
• | 程序集 |
• | 与此工作流模板一起使用的任何自定义窗体的 URL(或 IP 窗体的 URN) |
• | 工作流名称、工作流引擎名称以及运行工作流时要使用的托管服务程序集的名称(可选) |
• | 这些程序集中要调用的正确的类(可选) |
必须将工作流程序集本身部署到全局程序集缓存中。
在将其部署到站点后,该工作流即可作为工作流模板使用,SharePoint 管理员可将其与该站点上的文档库和列表相关联。
调试工作流
部署工作流程序集后,可通过打开工作流项目并附加到 Windows SharePoint Service w3wp 进程来调试工作流。
由于 Visual Studio 2005 Designer for Windows Workflow Foundation 是在 Visual Studio 中进行托管的,因此可充分利用 Visual Studio 的调试功能。对于 code-beside 文件中所编写的代码以及设计画面中的工作流活动,均可设置断点。
注意 为方便调试,强烈建议您在计划部署工作流模板的服务器上开发这些工作流模板。
Visual Studio 2005 Designer for Windows Workflow Foundation 不仅支持标准的 Visual Studio 调试功能(如“Breakpoints”(断点)和“Call Stack”(调用堆栈)窗口),它还包含一系列可视指示器,用于在调试过程中提供信息。在调试程序集的同时,还可向工作流活动添加断点。
可执行“步入”、“步出”和“单步跳过”操作来运行整个工作流代码。
Visual Studio 2005 Designer for Windows Workflow Foundation 不支持下列调试类型:
• | 托管进程中运行时异常的实时调试 |
• | 通过在“Task Manager”(任务管理器)中选择进程进行实时调试 |
有关使用 Visual Studio 2005 Designer for Windows Workflow Foundation 进行调试的详细信息,请参阅 Windows Workflow Foundation SDK。
注意 在 Microsoft 下载中心的 Microsoft Windows Workflow Foundation Runtime Components Beta 2.2 and Visual Studio 2005 Extensions for Windows Workflow Foundation Beta 2.2(英文)下载中提供了 Windows Workflow Foundation SDK。此下载中还包含 Visual Studio 2005 Designer for Windows Workflow Foundation 以及 Windows Workflow Foundation 运行时引擎。
在 SharePoint Designer 2007 中编写 SharePoint 工作流
在 Office SharePoint Designer 2007 中编写工作流时,您是直接针对 Windows SharePoint Services 中的特定列表或文档库来编写该工作流和进行数据绑定。您使用的是预定义的工作流活动列表,并不使用任何代码。您设计的工作流将不作为程序集进行编译,而是作为源文件进行存储,直到在它首次运行时,Windows SharePoint Services 才会对它进行编译。
该方法具有以下优点:
• | 可快速开发和测试工作流。 |
• | 由于工作流特定于给定列表,因此部署过程相对简单一些。 |
• | 因为同样的原因,安全问题也简单了许多。 |
• | 由于并未将工作流编译为程序集,因此,可将 SharePoint Designer 中所创建的工作流部署到服务器上(其中,管理策略禁止自定义代码程序集)。 注意 SharePoint Designer 中所编写的工作流收集自预定义活动的“安全列表”,管理员可能已批准这些活动在服务器上运行。 |
• | 工作流可由具有较少开发人员经验的用户创建,如 Web 设计者或知识工作者。 |
这种方法还表明,SharePoint Designer 中编写的工作流与使用 Visual Studio 2005 Designer for Windows Workflow Foundation 创建的工作流在一些重要的方面存在着差异:
• | 在 SharePoint Designer 中编写的工作流不能被部署到多个列表中。工作流仅对专门为之创建该工作流的列表有效。 |
• | 由于直接对列表编写工作流,所以该工作流在设计时与该列表相关联。因此,在 SharePoint Designer 中编写的工作流不包含关联阶段。 |
• | 对于在 SharePoint Designer 中编写的工作流,不能执行工作流修改。 |
• | 不能对 SharePoint Designer 中的内容类型进行编写。 |
有关详细的比较信息,请参阅比较 Visual Studio 2005 Designer for Windows Workflow Foundation 和 SharePoint Designer 2007。
运行 SharePoint Designer 2007 中所编写的工作流
由于在 Office SharePoint Designer 中编写的工作流不包含自定义代码,因此它们不作为程序集进行编译和部署。而是作为各自的源文件存储在 Windows SharePoint Services 内部,并仅当需要时才被编译到内存中。
对于每个站点,这种类型的工作流均存储在单独的文档库中。对于在 SharePoint Designer 中编写的每个工作流,此文档库均包含一个文件夹。此文件夹包含该工作流所需的所有源文件,其中包括:
• | 工作流标记文件 |
• | 工作流规则文件 |
• | 任何自定义工作流窗体所需的 ASPX 窗体 |
Windows SharePoint Services 包括一个实时编译器,用来在工作流首次在某个项目上启动时将源文件编译成工作流。Windows SharePoint Services 将已编译的工作流保留在内存中,直到它再次被调用,这类似于服务器将已编译的 .aspx 页面保留在内存中,以便在下次调用页面时提高执行性能。
每当某个工作流在项目上启动时,Windows SharePoint Services 会判断该工作流是已被部署为程序集还是源文件。如果存在工作流程序集,则 Windows SharePoint Services 会调用该程序集来创建工作流实例。如果已将工作流部署为源文件,则 Windows SharePoint Services 会判断是否已根据内存中的这些源文件编译了一个工作流。如果是这样,则 Windows SharePoint Services 会调用内存中已编译的工作流来创建工作流实例。如果不是这样,Windows SharePoint Services 会使用其实时编译器来将源文件编译为内存中的工作流,随后再调用该工作流来创建工作流实例。
SharePoint Designer 2007 中的工作流开发过程
为实现工作流的快速设计和部署,SharePoint Designer 中的开发过程将比 Visual Studio 中的开发过程简单得多。
通常,在使用 Visual Studio 2005 Designer for Windows Workflow Foundation 为 Windows SharePoint Services 或 SharePoint Server 开发工作流时,需执行以下基本步骤:
• | 通过收集和配置 SharePoint Designer 中提供的预定义活动和条件来编写工作流。 |
• | 如有必要,让 SharePoint Designer 自动生成用于工作流初始化和任何自定义 SharePoint 任务的 ASP.NET 窗体。 |
• | 如有必要,自定义工作流窗体。 |
SharePoint Designer 会自动生成工作流定义模板并处理工作流到指定列表的部署。
以下部分概述了其中的每一个开发步骤。
使用 SharePoint Designer 2007 创建工作流
SharePoint Designer 使用的是向导驱动界面,用户可通过该界面从预定义活动中收集顺序工作流。用户从预定义列表中选择活动,然后使用 SharePoint Designer 界面对它们进行配置。这些活动可与 Visual Studio 2005 Designer for Windows Workflow Foundation 中所提供的活动相同;这两个工具所提供的活动之间不存在任何区别。
但在 SharePoint Designer 中,每个活动都作为一个操作出现,这些操作通过包含变量的句子来表示,用户可使用下拉菜单和查找对话框来配置这些变量。用户还可以选择条件,它们是可配置条件子句,用来指示工作流的流程。
当用户在工作流界面中选择和配置条件及操作时,SharePoint Designer 会生成两个文件,它们实际上代表工作流类:
• | 工作流标记文件,它包含用于描述工作流中所含活动的标记 |
• | 工作流规则文件,它包含以声明性规则窗体而非代码封装的工作流的业务逻辑 |
添加自定义活动和条件
如前所述,使用 SharePoint Designer 的工作流设计者无法创建可用于自身工作流中的自定义活动。而是只能使用显示在 SharePoint Designer 中的安全控件列表(可能已经过服务器管理员的批准)中已经提供的活动和条件。
条件只是一个包含静态方法的自定义程序集,该静态方法会在调用时判断某个条件并返回布尔值。
开发人员可创建自定义活动和条件,并使得它们在安全列表中可用。为此,开发人员必须:
1. | 创建活动或条件,将其作为强命名程序集进行编译,并将其部署到全局程序集缓存。 |
2. | 将活动或条件添加到 web.config 文件的操作安全列表中。 |
3. | 在工作流文件夹的 WSS.Actions 文件中,为用于表示 SharePoint Designer 用户界面中的活动或条件的句子添加规则和参数。这是用于指定界面中活动或条件出现及执行的方式的标记,因为此信息不会出现在活动或条件程序集中。 |
有关部署自定义活动和条件的详细信息,请参阅 SharePoint Designer 帮助。
SharePoint Designer 工作流中的 ASP.NET 窗体
在 SharePoint Designer 中可创建工作流的初始化阶段。如果您要这样做,SharePoint Designer 会根据您的初始化规范,使用 ASP.NET 自动生成初始化窗体。
同样,您可以为工作流创建自定义 SharePoint 任务。SharePoint Designer 会再次根据您的规范,自动生成此任务的 ASP.NET 窗体。
这些 aspx 窗体与工作流源文件一起存储在 SharePoint 站点上。如同任何其他 aspx 窗体一样,您可以打开并对其自定义。
注意 SharePoint Designer 2007 不提供与 InfoPath 窗体的集成。
使用 SharePoint Designer 2007 部署工作流
由于您是针对特定列表进行编写,因此,与在 Visual Studio 2005 Designer for Windows Workflow Foundation 中所创建的工作流相比,在 Office SharePoint Designer 中所创建的工作流的部署过程要简单得多。SharePoint Designer 用于处理工作流到指定列表的部署。
SharePoint Designer 不提供任何自定义调试功能。
从列表中删除在 SharePoint Designer 中编写的工作流并不会删除用于在内存中编译该工作流的实际源文件。而是此工作流不再与列表相关联,但源文件仍存储在站点的工作流文档库中。
在 Windows SharePoint Services 对象模型中,不能将在 SharePoint Designer 中编写的工作流与在 Visual Studio 2005 Designer for Windows Workflow Foundation 中编写的工作流区分开来。
比较 Visual Studio 2005 Designer for Windows Workflow Foundation 和 SharePoint Designer 2007
下表提供 Visual Studio 2005 Designer for Windows Workflow Foundation 和 Office SharePoint Designer 2007 所提供的功能之间,以及使用这两者可创建的工作流之间的详细比较。
表 1. 功能的详细比较 | |
Visual Studio 2005 Designer for Windows Workflow Foundation | SharePoint Designer 2007 |
可为 Windows SharePoint Services 或 SharePoint Server 编写工作流 | 可为 Windows SharePoint Services 或 SharePoint Server 编写工作流 |
开发人员可通过 code-behind 文件来编写自定义 Visual C# 或 Visual Basic .NET 代码,以表示业务逻辑 | 无 code-behind 文件;工作流规则文件采用声明方式来封装业务逻辑 |
生成工作流标记文件 | 生成工作流标记文件 |
将工作流编写为可与多个站点和列表关联的模板 | 设计时针对特定列表来编写工作流和进行数据绑定 |
工作流标记文件或者标记和 code-behind 文件被编译到工作流程序集中 | 工作流标记、工作流规则和支持文件存储在站点上的特定文档库中,但未进行编译 |
工作流模板必须与该工作流模板在其上可用的每个列表相关联 | 关联在针对特定列表编写工作流时发生;不需要或不能进行后期关联 |
可以使用任何窗体技术。例如,Windows SharePoint Services 工作流的 ASP 窗体,或者 SharePoint Server 工作流的 InfoPath 窗体 | 自动生成 ASP.NET 窗体,可在随后进行自定义 |
可包括工作流修改 | 工作流修改不可用 |
可以使用自定义对称 InfoPath 窗体,该窗体可实现自定义工作流窗体的 Office 客户端集成 | InfoPath 窗体集成不可用 |
可编写自定义活动以包含在工作流中 | 必须使用所提供的活动 |
将工作流程序集和工作流定义打包为 SharePoint 功能,然后部署到站点 | 自动处理到特定列表的部署 |
启动工作流时可以使用初始化窗体收集用户信息 | 启动工作流时可以使用初始化窗体收集用户信息 |
用户与 SharePoint 任务进行交互时可以使用自定义窗体 | 用户与 SharePoint 任务进行交互时可以使用自定义窗体 |
可以进行 Visual Studio 调试 | 不能进行逐步调试 |
可以编写顺序工作流和状态工作流 | 只能编写顺序工作流 |
Windows SharePoint Services 中的工作流结构
图 8 显示在工作流模板创建、部署并与特定内容类型、列表或文档库建立关联后,如何加入 Windows SharePoint Services 工作流结构的各个元素。
在将工作流模板与给定内容类型、列表或文档库关联时,Windows SharePoint Services 会将管理员设置的关联参数信息写入场级别工作流关联表中。此关联表中的条目会将特定内容类型、列表或文档库链接到相关联工作流的工作流模板定义。而工作流模板定义中的信息又包括对工作流程序集本身的引用,以及工作流使用的任何自定义工作流窗体。
对于在 SharePoint Designer 2007 中编写的工作流,设计器会自动将关联参数信息写入工作流关联表,并生成和安装工作流模板定义。另外,工作流会作为标记和工作流规则源文件(而非编译后的程序集)存储在站点级工作流文档库中。
![.](https://i-blog.csdnimg.cn/blog_migrate/8287bf85534ac5aa304738215ef94849.png)
图 8. Windows SharePoint Services 中的工作流组件结构
使用工作流命名空间
在完成工作流解决方案的部署后,可使用 Windows SharePoint Services 对象模型来查询工作流进程以及以编程方式执行工作流操作,如,将工作流添加到列表或为某个项目启动工作流。
主要 Microsoft.Windows.SharePoint.Workflow 对象
Microsoft.Windows.SharePoint.Workflow 命名空间表示包含在 Windows SharePoint Services 中的工作流功能。
SPWorkflowTemplateCollection 对象表示当前在站点上部署的工作流模板。每个 SPWorkflowTemplate 对象都表示一个工作流模板,其中包含可用来获得或设置模板相关信息(如,模板的实例化数据以及历史和任务列表)的属性。
要将工作流与列表或文档库关联,请使用 SPList.AddWorkflowAssociation 方法。此重载方法使用四个参数:
• | 工作流模板名称或 ID |
• | 要为工作流指定的名称 |
• | 要与此工作流一起使用的任务列表的名称或 ID |
• | 工作流的历史列表 |
与通过用户界面添加工作流相同,此方法将在列表中添加工作流的状态列。使用 SPList.RemoveWorkflowAssociation 方法从列表中删除工作流模板。
SPWorkflowAssociationCollection 对象表示站点的内部工作流关联表;即,它表示站点集合中列表当前关联的工作流,以及每个工作流的关联信息。每个 SPWorkflowAssociation 对象都表示一个已与特定列表相关联的工作流模板,并且包含用于返回关联的相关自定义信息(如工作流是否已启用、工作流是否已修改、工作流所关联的列表以及对用作此 SPWorkflowAssociation 对象基础的 SPWorkflowTemplate 对象的引用)的属性。
对于存储为未编译文件的工作流(如在 SharePoint Designer 中编写的那些工作流),SPWorkflowAssociation.IsDeclarative 属性会返回 True。
SPWorkflowCollection 表示给定列表项上已经运行或当前正在运行的工作流实例。每个 SPWorkflow 对象都包含用于返回工作流实例相关信息(如,工作流是否已完成、其内部状态以及它所基于的工作流模板)的属性。此外,每个工作流还包含该工作流的任务集合 SPWorkflowTaskCollection。
使用 SPListItem.Workflows 属性返回 SPWorkflowCollection 对象,它表示该列表项当前正在运行的工作流。
以编程方式管理运行中的工作流实例
用户通过 Windows SharePoint Services 用户界面,与在项目上运行的工作流分别进行交互。但 Windows SharePoint Services 为您提供了通过对象模型,集中控制整个服务器场中正在运行的工作流实例的功能。使用 SPWorkflowManager 对象管理整个场中正在运行的工作流实例。在用户界面中,SPWorkflowManager 对象没有等效对象。虽然要通过 SPSite 对象访问此对象,但您可使用它来管理整个场中运行的工作流实例。使用 SPWorkflowManager 对象可执行以下操作:
• | 启动、运行或取消工作流。 |
• | 返回特定项目上当前正在运行的所有工作流。 |
• | 取消列表中基于特定工作流模板的所有工作流实例。 |
• | 执行其他工作流管理操作。 |
要手动启动某项目的特定工作流(即,未配置为自动启动的工作流),请使用 SPSite.WorkflowManager.StartWorkflow 方法。此方法使用三个参数:列表项的名称、工作流模板的名称以及启动事件。
图 9 显示了 SPWorkflowManager 对象及其包含的对象的分层视图。
![.](https://i-blog.csdnimg.cn/blog_migrate/83d09efe40459f43d21ef0afe48125df.png)
图 9. SPWorkflowManager 对象分层结构
结论
Windows SharePoint Services V3 可托管 Windows Workflow Foundation,通过 Windows Workflow Foundation,您可将自定义业务流程(实现为顺序工作流或状态机工作流)附加到 SharePoint 项目。此实现包括创建自定义工作流功能以及用于实现用户交互的窗体集成功能。通过提供与那些可在 Office 客户端应用程序(如 Word、PowerPoint、Excel 和 InfoPath)中托管的对称 InfoPath 窗体的集成,SharePoint Server 2007 扩展了这些工作流功能。
Microsoft 为 Windows SharePoint Services 提供了两种用于编写工作流的强大工具。Visual Studio 2005 Designer for Windows Workflow Foundation 是 Visual Studio 2005 的一个加载项,使您能够开发可部署到多个站点和列表的工作流模板和自定义代码。也可根据工作流活动的预定义列表,使用 SharePoint Designer 快速开发和部署列表特定的工作流。
无论哪种情况,在完成工作流解决方案的部署后,您都可以使用 Windows SharePoint Services 对象模型来查询工作流进程以及以编程方式执行工作流操作。
其他资源
• | |
• |