SharePoint ワークフロー開発のベスト プラクティス
Visual Studio を使用して SharePoint でワークフローを作成する開発者に対して、ベスト プラクティスのコレクションを提供します。
注意
SharePoint 2010 ワークフローは、2020 年 8 月 1 日以降、新しいテナント用に廃止され、2020 年 11 月 1 日に既存のテナントから削除されました。 SharePoint 2010 ワークフローを使用している場合は、Power Automate またはその他のサポートされているソリューションに移行することをお勧めします。 詳細については、「SharePoint 2010 ワークフローの廃止」を参照してください。
SharePoint 用にエラーのないワークフローを開発するには、一般的なガイドラインか、「ベスト プラクティス」に従うことをお勧めします。このことは、ワークフローの開発に SharePoint Designer 2013 または Visual Studio 2012 のどちらを使用しても該当します。
統合されたワークフローを含む SharePoint アドイン (親 Web のリストと関連付けられる) は、アプリのパッケージにある workflowmanifest.xml ファイルで次のタグを true に変更することで、通常のワークフローと区別されます。
<SPIntegratedWorkflow xmlns="http://schemas.microsoft.com/sharepoint/2014/app/integratedworkflow">
<IntegratedApp>true</IntegratedApp>
</SPIntegratedWorkflow>
[ 履歴リストに記録する] アクション (または、Visual Studio を使用している場合は LogToHistoryListActivity クラス) により、ワークフローのライフサイクルの指定のポイントでワークフローが実行した内容に関する情報を記録できます。 つまり、これは使用できる最も重要なトラブルシューティング ツールの 1 つです。 重要なポイントで提供する情報が詳細であればあるほど、予期しないイベントをより簡単にトラブルシューティングすることができます。
詳細については、以下を参照してください。
Log to History List アクションを使用して履歴リストに文字列および変数を書き込めば、SharePoint デザイナーを使用して作成されたワークフローのデバッグが簡単になります。
詳細については、以下を参照してください。
ワークフローのデバッグを支援するには、各重要な作業単位に従う前に意味のある情報をキャプチャすることが重要です。この情報はトレース ログにコミットする必要があります。 詳細については、次のトピックを参照してください。
ワークフローで変数を使用する前に、存在する変数が Null でないことを確認します。 さらに、変数に期待値が含まれ、データ型が正しいことを確認します。 詳細については、「 変数と引数」を参照してください。
ワークフロー テキスト フィールドでの文字列の最大許容長は 255 文字です。 テキスト フィールドを、これを超える文字列長に設定しても、テキスト フィールドのコンテンツは切り捨てられて 255 文字になります。
ワークフローで偽装ステップを使用する場合、ニュートラル アカウント (すなわち、特定のユーザーに関連付けられていないアカウント) を使用してワークフローを作成します。 これにより、作成者のアカウントが何らかの理由で廃止になってもワークフローが壊れるのを防ぐことができます。
詳細については、「 SharePoint ワークフロー プラットフォームを使用して昇格されたアクセス許可を持つワークフローを作成する」を参照してください。
特定のフィールドが存在するリストに依存する、再利用可能なワークフローを作成する場合は、(1) ワークフローを、特定のフィールドを持つコンテンツ タイプに限定することも、(2) フィールドを関連付け列とすることもできます。 コンテンツ タイプは変化し、ワークフローが壊れる原因となる可能性があるので、オプション (2) をお勧めします。
可能な限り、ワークフロー ロジックをいくつかの小さなワークフローに分割するよりも、単一のワークフローでビジネス プロセスのモデル化を行うことをお勧めします。
可能な限り、複数の Approval アクションを作成するのでなく、 Approval アクション内の Stages 機能を使用するほうが効果的です。