SharePoint 工作流基础知识
提供了 SharePoint 中的工作流基础结构的高级概述，包括平台体系结构和工作流互操作性桥的视图。
注意
SharePoint 2013 工作流自 2023 年 4 月 2 日起已弃用，并且将于 2024 年 4 月 2 日起关闭新租户。 它将从现有租户中删除，并且将于 2026 年 4 月 2 日完全停用。 如果使用 SharePoint 2013 工作流，我们建议迁移到 Power Automate 或其他受支持的解决方案。 有关详细信息，请参阅 Microsoft 365 中的 SharePoint 2013 工作流停用。 自 2020 年 8 月 1 日起，SharePoint 2010 工作流已对新租户停用，并于 2020 年 11 月 1 日从现有租户中删除。 如果你使用的是 SharePoint 2010 工作流，我们建议迁移到 Power Automate 或其他支持的解决方案。 有关详细信息，请参阅 SharePoint 2010 工作流停用。
SharePoint 中的工作流概述
SharePoint 工作流由 Windows Workflow Foundation 4 提供支持，它实际上是基于早期版本重新设计的版本。 反过来，Windows Workflow Foundation (WF) 基于 Windows Communication Foundation (WCF) 提供的消息传送功能。
从概念上说，工作流模型构成了业务流程。 因此，Windows Workflow Foundation 4 工作流是工作流"活动"的结构化集合，其中每个工作流活动均表示业务流程的一个功能性组件。
SharePoint 中的工作流平台使用 Windows Workflow Foundation 4 活动模型表示基于 SharePoint 的业务流程。 此外，SharePoint 引入了一个在其中创建工作流的更高级的阶段-关卡流程模型。
记下工作流 活动 与 SharePoint操作 之间的关系很重要。 工作流活动表示其方法将推动工作流行为的基础托管对象。 另一方面，工作流操作是一些包装，可封装基础活动并在 SharePoint Designer 中的用户友好表单中呈现它们。 工作流作者与工作流操作进行交互，而工作流执行引擎将执行相应的活动。
作为活动类的实现的活动将通过使用 XAML 以声明方式实现。
使用松散耦合的 Web 服务调用工作流活动，这些服务将使用消息 API 与 SharePoint 进行通信。 这些 API 基于 Windows Communication Foundation (WCF) 提供的消息传送功能。
消息框架非常灵活且支持您需要的几乎所有消息模式。 请注意，在 SharePoint 场中，Windows Workflow Foundation 和 WCF 承载于 Workflow Manager Client 1.0 中。
Workflow Manager Client 1.0、SharePoint 和 SharePoint Designer 2013 均提供了新的基础结构的重要部分：
Workflow Manager Client 1.0 提供了工作流定义的管理。 它还承载了工作流实例的执行过程。
SharePoint 提供了针对 SharePoint 工作流的框架，该框架将为涉及 SharePoint 文档、列表、用户和任务的基于 SharePoint 的业务流程建模。 此外，将在 SharePoint 中存储和管理 SharePoint 工作流、关联、活动和其他工作流元数据。
SharePoint Designer 2013 是用于创建并发布工作流定义的主业务用户工具，与早期版本一样。 它还可用于打包带有或不带有关联的 SharePoint 组件的工作流定义。
平台体系结构
图 1 描述了 SharePoint 工作流框架的高级视图。 首先，请注意新的工作流基础结构如何将 Workflow Manager Client 1.0 作为新的工作流执行主机引入。 然而，在 SharePoint 自身承载的早期版本的工作流执行中，此情况已在 SharePoint 中发生改变。 Workflow Manager Client 1.0 位于 SharePoint 外部并使用常见协议通过 Microsoft Azure 服务总线（由 OAuth 进行协调）进行通信。 另外，SharePoint 包含您期望看到的功能：内容项、事件、应用程序等。 但请注意，还会实现 SharePoint 2010 工作流主机（即 Windows Workflow Foundation 3 引擎）以实现向后兼容。 有关此内容的详细信息，请参阅 使用 SharePoint 的工作流互操作。
图 1. 工作流基础结构的高级体系结构
Workflow Manager Client 1.0在 SharePoint 中以 Workflow Manager Client 1.0服务应用程序代理的形式表示。 此组件允许 SharePoint 与 Workflow Manager Client 1.0服务器进行通信和交互。 同使用 OAuth 提供服务器间的身份验证。
为其侦听工作流的 SharePoint 事件（如 itemCreated、 itemUpdated 等）将通过使用 Microsoft Azure 服务总线传送到 Workflow Manager Client 1.0。 对于回程，平台将使用 SharePoint 代表性状态传输 (REST) API 回调到 SharePoint。
此外，还为 SharePoint 工作流对象模型增加了功能，这些功能统称为"工作流服务管理器"，可使用该管理器管理和控制工作流及其执行。 服务管理器的交互的主区域为部署、消息传送、实例控件和（用于向后兼容）与 SharePoint 2010 工作流的互操作性。
最后，提供了一个工作流创作组件。 SharePoint Designer 现在可以创建和部署 SharePoint 2010 和 SharePoint 工作流。 Visual Studio 2008 不仅可以提供用于创建声明性工作流的设计器图面，还可以创建与 Workflow Manager Client 1.0 功能完全集成的 SharePoint 外接程序 和解决方案。
工作流订阅和关联
由于对 SharePoint 工作流所做的最明显的更改是，将工作流处理移至诸如 Microsoft Azure 这样的外部工作流主机上，这对于将 SharePoint 消息和事件连接到 Microsoft Azure 中的工作流基础结构是至关重要的。 此外，将基础结构连接到客户数据对于 Microsoft Azure 也是非常重要的。 工作流关联（基于订阅的 WF 概念构建）是支持这些要求的 SharePoint 基础结构部分。
Microsoft Azure 发布/订阅服务
您必须先查看 Microsoft Azure 发布/订阅服务（该服务有时称作"pub/sub"或简称为"PubSub"，然后才能讨论工作流关联和订阅。 PubSub 是一个异步消息框架。 消息发送者（发布者）不会直接将消息发送给消息接收者（订阅者）。 相反，发布者会将消息呈现为不知道消息订阅者的类。 随后，订阅者通过根据其已创建的订阅标识感兴趣的消息来使用已发布的消息，而不管发布者的身份如何。
通过将消息创建与消息使用分离可以实现可伸缩性和灵活性。 它支持发布者端的多播消息，以及订阅者端的混杂消息使用。
注意
PubSub 功能属于 Microsoft Azure 服务总线，为 WCF 和其他服务终结点提供连接选项。 其中包括 REST 终结点，它们位于网络地址转换 (NAT) 边界后面和/或绑定到经常变化的动态分配 IP 地址。 有关Azure 服务总线的详细信息，请参阅服务总线。
工作流关联和关联范围
工作流关联使用特定的默认值将工作流定义绑定到特定的 SharePoint 范围。 关联本身表示一组存储在 Azure 发布/订阅服务中的订阅规则，这些规则将处理传入消息以确保它们由适当的（即订阅的）工作流实例使用。
默认情况下，消息基础结构支持以下范围的工作流：
与早期版本不同，SharePoint 不支持范围限定为某个内容类型 ( SPContentType ) 的工作流。 但由于消息基础结构是可扩展的，因此，它可以支持任意范围。 作为一名开发人员，您可以将给定 WorkflowSubscription 实例的 EventSourceId 属性设置为任何 guid。 然后，可以使用该 EventSourceId 值调用 PublishEvent (Guid、String、IDictionary<String、Object>) ，这会触发指定 WorkflowSubscription 的新工作流实例。
Microsoft Azure 中的工作流服务
SharePoint 工作流的关联由其在 Microsoft Azure 中的工作流服务表示。 当一个应用程序必须获取工作流关联及其数据时，它必须先对给定范围内可用的所有工作流服务进行查询。
同样地，工作流实例会将指针返回其各自的工作流服务。 这就是确定其正确的关联的方式。
启动工作流
可以手动或自动启动工作流。
手动工作流
当 PubSub 服务接收 StartWorkflow 消息时，将手动启动工作流。 该消息包含以下说明性信息：
关联标识符（即 WorkflowSubscription 实例）。
原始项上下文的 ID。 这会在 PublishEvent 方法调用上通过 ItemId 参数和 EventSource 属性传入。
手动启动的事件类型 ( WorkflowStart)。
来自订阅或 Init 表单（如果适当）的附加工作流初始参数。 这将是 CorrelationId（对于订阅）和 WFInstanceId（对于 Init 表单）。
自动启动工作流
通过对 PubSub 服务使用 Add 消息启动自动启动工作流。 该消息包含以下说明性信息：
原始项上下文的 ID。
此事件本身是一个常规 SharePoint Add 事件。
工作流启动参数
注意
如果工作流自动对可重复事件（例如，OnItemChanged 事件）启动，那么在关联的工作流的现有运行实例完成运行前，不能启动给定关联的另一个工作流。
工作流订阅
订阅是对关联的自然补充，它允许工作流与关联进行交互。 工作流必须使用 create 方法和 delete 方法在 Azure 服务总线上创建订阅。
用于创建订阅和实例化工作流的方法的签名指定可选参数和必需参数。 由于参数列表是由工作流作者确定，因此可能会因工作流定义而异。 将订阅参数列表指定为工作流定义的元数据。 订阅参数是在订阅创建时提供。 在 XAML 中将初始化参数列表指定为工作流定义的一部分。 初始化参数是在工作流实例化时提供。
订阅绑定到特定 SharePoint 对象，可以是 SPList 实例，也可以是 SPWeb 实例。 在订阅创建时，订阅对象类型以必需参数值的形式传入。 对象类型定义了订阅范围，因此订阅只能响应已订阅对象上发生的事件。
SharePoint 工作流互操作
利用 SharePoint 工作流互操作性，可从 SharePoint 工作流（基于 Windows Workflow Foundation 4）中调用 SharePoint 2010 工作流（基于 Windows Workflow Foundation 3 构建）。 从而实现在 2013 工作流内执行 2010 工作流。
这一点非常重要，因为您可能会将您要使用的 SharePoint 2010 与 SharePoint 工作流一起重复使用。 此外，您可能希望使用 SharePoint 2010 中的活动或功能，而 SharePoint 中尚未实施这些活动或功能。
有关 SharePoint 工作流互操作的完整讨论，请参阅 使用 SharePoint 工作流互操作。