Sharepoint および Project での SharePoint 2013 ワークフローの調整とパフォーマンス

概要

この記事では、Microsoft 365 の SharePoint および Project で SharePoint 2013 ワークフロープラットフォームタイプを使用するワークフローの調整シナリオと制限について説明します。

注: SharePoint 2010 ワークフローは、2020年8月1日以降、新しいテナントで廃止され、2020年11月1日に既存のテナントから削除されています。 SharePoint 2010 ワークフローを使用している場合は、Power Automate またはその他のサポートされているソリューションに移行することをお勧めします。詳しくは、「 SharePoint 2010 ワークフローの廃止」をご覧ください。

詳細情報

SharePoint での調整について詳しくは、「操作方法: sharepoint での調整またはブロックを回避する方法」をご覧ください。

SharePoint ワークフローのメールメッセージの制限の詳細については、「SharePoint のメールメッセージの上限を超えていて、ワークフローが中断されました」というエラーを参照してください。

SharePoint 2013 ワークフローアクティビティは、次の2つの調整レベルで規制できます。

SharePoint の調整
ワークフローサービスの調整

ワークフローサービスの調整

公平なリソース使用を可能にするために調整が行われます。また、ベストプラクティスに従わない有害なワークフローやワークフローから環境を保護します。ワークフローサービスの調整は SharePoint によって制御されません。ワークフローサービスと SharePoint は2つの独立したサービスであり、各サービスは、サービスの正常性に関する要求を処理します。ワークフローサービスでは、SharePoint サイトと連携するワークフローのスコープレベルで調整が行われます。調整はグローバルには計上されません。代わりに、各ワークフローバックエンドサービスはワークフロースコープの使用状況を個別に追跡します。ワークフローのスコープには、1つ以上のワークフローが存在する場合があります。ワークフローの調整は動的であり、ワークフローのスコープおよびワークフローサービスのバックエンドによって定期的に再評価されます。

ワークフローサービスでは、1つのワークフローインスタンスで生成できる送信要求の数も制限されます。 24時間以内に、1つのワークフローインスタンスで最大5000の送信要求を生成できます。 5000送信要求が24時間以内に生成されると、ワークフローはワークフローサービスによって中断されます。

ワークフローの [ワークフローの状態] ページには、中断されたワークフローに関する情報が含まれています。このシナリオでは、内部状態 の情報バルーンに次のメッセージが表示されます。

インスタンスが 1.00:00:00 の送信 http 要求のクォータを超えています。5000要求の制限に達しました <>。

注:<time> プレースホルダーは、ワークフローの5000要求の制限に達するまでにかかった時間を表します。

中断されたワークフローインスタンスを再開するには、ワークフローの [再開] をクリックするか、24時間経過した後に SharePoint ワークフロークライアントオブジェクトモデルを使用します。これは、ワークフローが終了する前に行う必要があります。

ワークフローの CPU 使用量の上限を超えている場合、ワークフローの [ワークフローの状態] ページには、中断されたワークフローに関する情報が含まれます。このシナリオでは、内部状態の情報バルーンに次のメッセージが表示されます。

ワークフローインスタンスの CPU 使用量の制限である 00:00: 01.2000000 を超えていないため、アンロードされませんでした。

中断されたワークフローインスタンスは、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 が含まれていない限り、アクションとその作成アクティビティは要求カウントには影響しません。たとえば、"履歴リストに記録する " アクションを実行すると、正常に動作するために5つ以上の要求が生成されることがあります。また、問題が発生した場合のために、再試行ロジックはワークフローに組み込まれています。これにより、追加の要求が発生する可能性があります。

多くのアクションは要求を生成し、要求はベストプラクティスを使用して最小化できます。たとえば、[現在のアイテム] アクションの複数のSet フィールドではなく、1つの更新リストアイテムのアクションを使用して、ワークフローのスコープによって行われる要求の数を減らし、同じ結果を得ることができます。

ワークフローの設計に関する推奨事項

調整が必要な多数の要求をワークフローで生成するには、さまざまな方法があります。いくつかの一般的な例を次に示します。

1つの積極的なループワークフローまたは複数の積極的ループワークフロー
コンテンツが SharePoint に移行されているときに、リストまたはライブラリに関連付けられているワークフロー。
以前に修正され、ワークフローが終了するまで、問題のある構成を持つワークフローインスタンスの実行を継続する、問題のあるワークフローバージョン。

ワークフローサービスによって適用されるワークフローのスコープの調整により、一般的なワークフローユースケースシナリオを許可する必要があります。ただし、ワークフローのロジックがより洗練されているため、ワークフローは安全な制限を超える可能性があります。

次の特定のワークフローシナリオでも、調整が行われます。

シナリオ 1: 変更を監視するためにループするワークフロー

たとえば、項目が更新されるのを待たずに、更新プログラムの項目をチェックすることができます。

シナリオ 2: ワークフローを使って複雑なアルゴリズムを実行する

ワークフローは、ドキュメント駆動型の人的処理を管理することを目的としており、重要な計算タスクをディスパッチしないようにします。

シナリオ 3: "リストアイテムのイベントを待つ" アクティビティを実行している複数のワークフローを実行する

このシナリオでは、各ワークフローがターゲットリストの変更をリッスンします。実行されているワークフローが多い場合は、各ワークフローが発生したイベントに反応する必要があります。また、いくつかの作業を実行するために SharePoint にコールバックする必要があります。

注:この問題は、項目が作成または変更されたときにワークフローが開始されるように構成されているリストに、多くの変更がある場合にも発生することがあります。

シナリオ1の代替手段: 変更を監視するためにループするワークフロー

オプション 1: SharePoint アドインと外部イベントレシーバーを使用する

ワークフローの設計を再評価して、別の設計方法を使用する必要があります。 SharePoint アドインまたは外部イベントレシーバーは、このタスクに適しています。

オプション 2: 一時停止アクションを追加する

遅延 (一時停止アクション) を追加することで、ワークフローの設計を多少向上させることができます。これにより、生成されるトラフィックが少なくなります。ただし、この設計の全体的な欠点は変わりません。

オプション 3: [現在のアイテムでのフィールドの変更を待つ] アクティビティを使用する

ループを使って変更を検索する代わりに、既定のイベントレシーバーを使うことをお勧めします。ワークフローは、アイテムが作成または変更されたときに開始できます。積極的なループで1つのワークフローを使うのではなく、複数のワークフローインスタンスを実行することをお勧めします。ワークフローの条件は、必要なときにのみ作業を実行するように構成できます。

[スタートオプション] ダイアログボックス

ワークフローの1つのワークフローインスタンスのみが、指定した時間に実行できます。

もう1つの方法は、[現在のアイテムのアクティビティ] で [待機時間] フィールドを変更することです。

ワークフローの設計では、複数の値を持つ choice 列を使用して、ワークフローの実行を実行できます。適切なオプションがエンドユーザーによって選択された場合にのみ、ワークフローは再開されます。これにより、積極的なループと不要なワークフローインスタンスが開始されるのを防ぐことができます。ワークフローは、複数インスタンスの実行または開始の代わりに、アイテムの準備ができたときに実行されます。

複数の並列ブロックを使用すると、複数のフィールドから複数の値を監視できます。ワークフローは、次の例のように、特定の状態を待ち、指定したパスの実行を続けることができます。

ブール型の変数を作成します。
値を [いいえ」に設定します。
並列ブロックを挿入するには、ブロックを右クリックし、[詳細プロパティ] をクリックします。
ドロップダウンで、手順1で作成した変数を選択します。
"補完条件" プロパティが設定されている、挿入された並列ブロックに2つの並列ブロックを挿入します。
手順5で挿入した2つの並列ブロックの最初に、[現在のアイテムのアクティビティ] で [フィールドの変更を待つ]を挿入します。アクティビティを変更して、選択肢列を監視するようにします。既定の選択を監視しないでください。
他の並列ブロックを停止するために使用されるワークフロー変数を[はい]に設定します。
他の選択肢列の値について、手順1-7 を繰り返します。
元のワークフローの他の部分を並列ブロックの後の位置に移動します。

入れ子になった並列ブロックのいずれかのアクティビティが実行されると、親並列ブロックは他の並列ブロック内の他のアクティビティを終了します。これにより、ワークフローを続行することができます。入れ子になった並列ブロックは、変数を使って親並列ブロックによって監視されます。

オプション 4: SharePoint 2013 ワークフローから SharePoint 2010 ワークフローを開始する

SharePoint 2010 ワークフロープラットフォームタイプを使用して、SharePoint 2013 ワークフロープラットフォームタイプで実行されている作業の一部を実行できます。これにより、要求の数を減らすことができます。

具体的には、SharePoint 2010 ワークフローを開始して、[現在のアイテムのアクティビティでのフィールドの変更を待つ] または他の基本的な操作を実行することで、フィールドの変更を監視することができます。

シナリオ2に代わる方法: ワークフローを使用して複雑なアルゴリズムを実行する

ソリューションで重要な計算作業が必要な場合は、SharePoint 用のアドインを開発することを検討してください。詳細については、「 SharePoint アドイン」を参照してください。

さらにヘルプが必要な場合 Microsoft コミュニティに移動します。