Sharepoint 和 Project 中的 SharePoint 2013 工作流限制和性能

简介

本文包含有关在 Microsoft 365 的 SharePoint 和 Project 中使用 SharePoint 2013 工作流平台类型的工作流的限制方案和限制的相关信息。

注意: SharePoint 2010 工作流自2020起已停用，自起新租户并已从年11月 1 2020 日的现有租户中删除。如果您使用的是 SharePoint 2010 工作流，我们建议迁移到 Power 自动化或其他受支持的解决方案。有关详细信息，请参阅 SharePoint 2010 工作流停用。

详细信息

若要了解有关 SharePoint 中的限制的详细信息，请转到操作方法：避免在 sharepoint 中阻止或阻止。

若要了解有关 SharePoint 工作流的电子邮件限制的详细信息，请转到sharepoint 中的 "每日电子邮件限额已超过" 和 "工作流已暂停" 错误。

SharePoint 2013 工作流活动可按两个级别的限制进行管制：

SharePoint 限制
工作流服务限制

工作流服务限制

执行限制以允许公平资源使用。它还可保护环境免受有害工作流和不遵循最佳做法的工作流的影响。工作流服务限制不受 SharePoint 控制。工作流服务和 SharePoint 是两个独立的服务，每个服务都将请求限制为对整体服务运行状况感兴趣。在工作流服务中，将在与 SharePoint 网站对齐的工作流范围级别执行限制。限制不是全局所占。相反，每个工作流后端服务单独跟踪工作流范围的使用情况。工作流范围中可能存在一个或多个工作流。工作流限制是动态的，并且将定期由工作流范围和工作流服务后端重新评估。

工作流服务还限制单个工作流实例可以生成的出站请求数。在24小时内，单个工作流实例最多可以生成5000个出站请求。在24小时内生成5000出站请求后，工作流服务将暂停工作流。

工作流的 "工作流状态" 页面将包含有关挂起的工作流的信息。在此方案中，内部状态 的信息气球将显示以下消息：

该实例已超过1.00：00：00时间段的出站 http 请求配额。<次> 时达到5000请求限制。

注意：> 占位符的 <时间表示达到工作流的5000请求限制所花的时间。

你可以通过单击工作流的 "恢复" 或使用 "SharePoint 工作流客户端对象模型" （24小时后）来恢复挂起的工作流实例。必须在终止工作流之前执行此操作。

如果工作流超过 CPU 使用率限制，则工作流的 "工作流状态" 页面将包含有关已挂起工作流的信息。在此方案中，内部状态的信息气球将显示以下消息：

工作流实例超过了00：00：01.2000000 的限制的 CPU 使用限制，因此无法卸载，因为它不是持久的。

挂起的工作流实例将在10天后终止。如果终止了工作流，则内部状态的信息气球将显示以下消息：

WorkflowTerminatedException：该实例已从 "已暂停" 状态移动到 "已终止" 状态，因为它已过期。

终止的工作流最终将被清除。清理终止的工作流后，它将显示以下消息：

很抱歉，出现了问题。
找不到该工作流。自动清理已完成实例

工作流范围

工作流范围 定义为网站集中的网站。例如，以下 URL 适用于根网站集，并且被视为工作流范围：

https://contoso.sharepoint.com/sites/rootsite

相同网站集中另一个工作流作用域的示例如下所示。但是，此工作流范围位于子网站中。

https://contoso.sharepoint.com/sites/rootsite/subsite

什么是请求？

SharePoint 2013 工作流基于 SharePoint 的外接程序模型生成，它们使用 REST Api 与 SharePoint 数据交互。若要了解详细信息，请转到了解 SharePoint 2013 REST 服务。

请求是从工作流服务到 SharePoint 或项目 REST API 终结点的网络调用。给定请求的请求类型或响应之间没有区别。操作和其撰写活动不会影响请求计数，除非该请求涉及到 SharePoint 2013 REST API。例如，"记录到历史记录 列表" 操作可能会生成五个或更多个正常操作请求。此外，可在工作流中内置重试逻辑以防出现问题。这可能会产生额外的请求。

许多操作生成请求，并且可以通过使用最佳做法来最大程度地减少请求。例如，你可以使用单个更新列表项操作，而不是在当前项目操作中使用多个设置字段来减少工作流范围发出的请求数，还可以获得相同的结果。

工作流设计建议

可通过多种方式在工作流中生成大量请求，从而导致限制。一些常规示例如下所示：

单个积极循环的工作流或多个积极循环的工作流
将内容迁移到 SharePoint 时与列表或库相关联的工作流。
以前的问题工作流版本已更正，并且继续运行具有问题配置的工作流实例，直到终止工作流。

工作流服务强制执行的工作流范围限制应允许使用典型的工作流使用案例方案。但是，随着工作流的逻辑增大更复杂，工作流可能会超过安全限制。

以下特定工作流方案也将导致限制。

方案1：循环监视更改的工作流

例如，你可以检查项目的更新，而不是等待更新项目。

方案2：使用工作流执行复杂的算法

工作流旨在管理文档驱动的人工流程，而不是调度重要的计算任务。

方案3：运行多个工作流，该工作流使用 "在列表项中等待事件" 活动

在此方案中，每个工作流将侦听目标列表中的更改。如果有多个工作流正在运行，则每个工作流都必须对引发的事件做出响应，并且可能会回调到 SharePoint 中以执行某些工作。

注意：如果对列表进行了许多更改，并且工作流配置为在创建或更改项目时启动，则也会发生这种情况。

方案1的替代方法：循环监视更改的工作流

选项1：使用 SharePoint 外接程序和外部事件接收器

应重新评估工作流设计，并使用不同的设计方法。 SharePoint 外接程序或外部事件接收器更适合此任务。

选项2：添加暂停操作

你可以通过添加延迟 (即 "暂停操作") 来改进工作流的设计。这应该会减少生成的流量。但是，它不会更改此设计的整体缺点。

选项3：使用 "在当前项目中等待域更改" 活动

最好使用默认事件接收器，而不是使用循环查找更改。工作流可在创建或更改项目时启动。执行多个工作流实例，而不是在主动循环中使用一个工作流是更好的方法。工作流中的条件可以配置为仅在需要时执行工作。

"开始选项" 对话框

在给定时间，只能运行一个工作流的一个工作流实例。

另一种方法是使用 "等待" 字段在 "当前项" 活动中更改。

工作流设计可以使用具有多个值的选项列来驱动工作流执行。仅当最终用户选择适当选项时，工作流将恢复。这可以防止启动攻击性循环和不必要的工作流实例。工作流在项目准备就绪时执行，而不是执行或启动多个实例。

你可以使用多个并行块监控多个字段中的多个值。工作流可以等待特定状态，然后继续执行给定路径，如以下示例中所示：

创建布尔类型变量。
将值设置为 "否"。
插入并行块，右键单击该块，然后单击 "高级属性"。
在下拉列表中，选择您在步骤1中创建的变量。
在具有CompletionCondition属性的插入并行块中插入两个并行块。
在您在步骤5中插入的两个平行块中的第一条，在 "当前项目" 活动中插入 "等待域更改"。更改活动，使其监视 "选项" 栏。不监视默认选择。
将用于停止其他平行块的工作流变量设置为"是"。
对其他选择栏值重复步骤1-7。
将原始工作流的其他部分移动到并行块后的某个位置。

当嵌套的并行块之一执行所有活动时，父并行块将终止其他并行块中的其他活动。这使工作流能够继续。嵌套的并行块由父并行块通过使用变量进行监视。

选项4：从 SharePoint 2013 工作流启动 SharePoint 2010 工作流

你可以使用 SharePoint 2010 工作流平台类型来执行 SharePoint 2013 工作流平台类型执行的一些工作。这可以减少请求的数量。

具体地说，SharePoint 2010 工作流可通过使用 "在当前项目中等待域更改" 活动或执行许多其他基本操作开始监控域更改。

方案2的替代方法：使用工作流执行复杂的算法

如果你的解决方案需要重要的计算任务，你应考虑开发 SharePoint 外接程序。有关详细信息，请转到 SharePoint 外接程序。

仍需要帮助？请转至 Microsoft 社区。