Sharepoint 與 Project 中的 SharePoint 2013 工作流程節流和效能

簡介

本文包含在 Microsoft 365 的 SharePoint 和 Project 中使用 SharePoint 2013 工作流程平臺類型之工作流程的限制案例與限制的相關資訊。

附註: SharePoint 2010 工作流程已于新租使用者的2020年8月1日終止，且已從2020年11月1日的現有租使用者中移除。如果您使用的是 SharePoint 2010 工作流程，我們建議您遷移至 [電源自動化] 或其他支援的解決方案。如需詳細資訊，請參閱 SharePoint 2010 工作流程停用。

其他資訊

若要深入瞭解 SharePoint 中的節流，請移至如何：避免在 sharepoint 中受到封鎖或封鎖。

若要深入瞭解 SharePoint 工作流程的電子郵件訊息限制，請移至 SharePoint 中的「已超過每日電子郵件限制，以及您的工作流程已暫停」錯誤。

SharePoint 2013 工作流程活動可以依兩個等級限制來管制：

SharePoint 節流
工作流程服務節流

工作流程服務節流

執行節流以允許公平資源使用量。它也能保護環境免受不遵循最佳做法之有害工作流程和工作流程的影響。工作流程服務節流不受 SharePoint 控制。工作流程服務和 SharePoint 是兩個獨立的服務，而且每個服務都要限制整個服務健康情況的相關要求。在工作流程服務中，會在與 SharePoint 網站對齊的工作流程範圍層級執行限制。不會對限制進行全域控制。相反地，每個工作流程後端服務會獨立追蹤工作流程範圍的使用方式。工作流程範圍中可能有一個或多個工作流程。工作流程節流是動態的，且會依工作流程範圍及工作流程服務後端定期重新評估。

工作流程服務也會限制單一工作流程實例可產生的輸出要求數目。在24小時內，單一工作流程實例最多可產生5000個輸出要求。在24小時內產生5000輸出要求之後，工作流程會由工作流程服務暫停。

工作流程的 [工作流程狀態] 頁面將會包含暫停工作流程的相關資訊。在這種情況下，內部狀態 的資訊氣球會顯示下列訊息：

此實例已超過1.00：00：00時間期間的輸出 HTTP 要求配額。在 <時間> 中達到5000要求限制。

注意：<時間> 預留位置代表達到工作流程的5000要求限制所需的時間。

您可以按一下工作流程的 [繼續]，或在24小時後使用 [SharePoint 工作流程用戶端物件模型] 來繼續暫停的工作流程實例。這必須在工作流程終止之前發生。

如果工作流程超過 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，否則動作和其組成的活動不會對要求計數造成影響。例如，[記錄到歷程記錄 清單] 動作可能會產生五個或更多個正常運作的要求。此外，您也可以在工作流程中內置重試邏輯，以防發生問題。這可能會產生額外的要求。

許多動作會產生要求，而要求可以使用最佳做法來最小化。例如，您可以使用單一的 [更新清單專案] 動作，而不是 [目前專案] 動作中的多個Set 欄位，以減少工作流程範圍所產生的要求數，並同時達到相同的結果。

工作流程設計建議

有許多方法可以在工作流程中產生大量要求，這可能會導致節流。以下是一些一般範例：

單一積極迴圈的工作流程或多個積極迴圈的工作流程
在內容被遷移至 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的替代方案2：使用工作流程執行複雜的演算法

如果您的方案需要大量的計算工作，您應該考慮開發適用于 SharePoint 的增益集。如需詳細資訊，請移至 SharePoint 增益集。

仍需要協助嗎？移至 Microsoft Community。