SharePoint ワークフローをデバッグする

  • [アーティクル]

SharePoint が、すべてのワークフローの処理と管理をワークフロー マネージャー 1.0 に依存するようになったことについて説明します。また、デバッグ オプションについても説明します。

提供:Andrew Connell、 Voitanos

注:

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

ワークフロー チームは Azure チームと協力して、ワークフロー マネージャーという製品を作成しました。 ワークフロー マネージャーは、最新バージョンの Windows Workflow Foundation ランタイムと必要なすべてのサービスを使用できる状態でスケーラブルな方法でホストします。 Microsoft Azure Service Bus を活用することでパフォーマンスとスケーラビリティに対応し、展開時には Office 365 と同様にオンプレミス展開でクラウドとまったく同じように動作します。 その後、SharePoint はワークフロー マネージャー ファームに接続され、このファームにすべてのワークフローの実行と関連タスクを渡すように構成されます。

このアーキテクチャの変更により、お客様がカスタム ワークフローの作成に使用していた 2 つの主要なワークフロー作成ツール (SharePoint Designer 2013 と Visual Studio 2012) にいくつかの変更が必要になりました。 ただし、SharePoint 2007 および SharePoint 2010 で開発者が採用していたデバッグの手法は引き続き適用できます。 新しいアーキテクチャでは、SharePoint Designer 2013 または Visual Studio 2012 のどちらかを使用して作成したワークフローの場合に、Fiddler を使用して SharePoint とワークフロー マネージャーの間のトラフィックを監視する新しいオプションが使用できます。

SharePoint ワークフロー デバッグの概要

SharePoint 用に作成されたカスタム ワークフローのデバッグは、SharePoint 2010 や SharePoint 2007 などの以前のバージョンのものと似ています。 使用できる一部のデバッグ オプションは、ワークフローの作成に使用するツール (SharePoint Designer 2013 または Visual Studio 2012) と、SharePoint の展開の種類 (オンプレミスまたは Office 365 (ホスト型)) によって異なります。 ワークフロー作成者が利用できるワークフローのデバッグ方法は次の 4 つです。

  • ワークフローの履歴リストにログを記録する
  • ブレークポイントを設定する
  • デバッグ メッセージをコンソールに送信する
  • Fiddler を使用して SharePoint とワークフロー マネージャー間のトラフィックを監視する

それぞれのオプションには長所と短所があります。 2 つのワークフロー作成ツール (SharePoint Designer 2013 または Visual Studio 2012) を使用した場合にできることとワークフローの展開の種類 (社内または Office 365) を理解しておくと役に立ちます。 次の表は、作成ツールおよび展開先と、各シナリオで利用できるオプションを示しています。

製品 SharePoint オンプレミス Office 365 SharePoint Online
SharePoint Designer 2013, SharePoint Online Fiddler の履歴リストに記録する 履歴リストに記録する
Visual Studio 2012 Fiddler のブレークポイント コンソール デバッグ メッセージ 履歴リストに記録する ブレークポイントの履歴リストに記録する

ワークフローの履歴リストを使用したデバッグ

あらゆる種類の SharePoint 展開で利用できる唯一のデバッグ オプションは、ワークフローの履歴リストにログ メッセージを書き込む方法です。 この方法を用いて SharePoint Designer 2013 の [ 履歴リストに記録する] アクションまたは Visual Studio 2012 の WriteToHistory アクティビティのいずれかを使用すると、ワークフローの関連付けで指定された、すべての履歴ログ メッセージのコンテナーとなるリストに文字列メッセージを新しいアイテムとして書き込むことができます。 これらは単純な文字列にすることも、ワークフロー内の変数の内容を連結して作成することもできます。

履歴リストをデバッグ ツールとして使用する方法は、ユーザーがメッセージを見ることができるため理想的ではありません。 したがって、デバッグ セッションが完了してワークフローが運用に使用されたら、ワークフロー開発者はデバッグと展開の間に追加ステップを作成し、これらのメッセージを削除します。 それでも、この方法はワークフローの作成に使用するツールや SharePoint 展開の種類に関係なく、あらゆるシナリオで利用できる唯一のオプションとなります。

Visual Studio 2012 のブレークポイントを使用したデバッグ

もう 1 つのデバッグ オプションは、ブレークポイントを利用することです。 ブレークポイントは、Visual Studio 2012 を使用して作成されたワークフローでのみ使用できます。SharePoint Designer 2013 にはブレークポイントを設定したり、実行中のプロセスにデバッガーをアタッチしたりする機能がないためです。 これらは、オンプレミスの SharePoint と、Office 365などのホストされた展開の両方で使用できます。 このシナリオでは、ワークフロー内のアクティビティにブレークポイントを設定し、デバッグ モードでワークフローを開始します。

図 1. ワークフローの開始

図 1. ワークフローの開始

Visual Studio はターゲットの SharePoint 環境にワークフローを展開し、デバッガーをアタッチします。 ブレークポイントが設定されているアクティビティにワークフロー プロセスが到達すると、Visual Studio がフォーカスを取り戻し、ユーザーはワークフローの変数の値を調べ、次の図に示すように Visual Studio 2012 から各アクティビティを順に実行できるようになります。

図 2. ワークフローのブレークポイント

図 2. ワークフローのブレークポイント

デバッグ メッセージとテスト サービス ホストを使用したワークフローのデバッグ

ワークフロー マネージャーを SharePoint ワークフローのストーリーに導入すると、Visual Studio 2012 を使用してカスタム ワークフローを作成しているときと、それらを社内展開でテストしているときに利用できる 2 つの新しいデバッグ機会が取り入れられます。 Visual Studio 2012 には、単一の文字列ベースのメッセージを入力として受け付ける WriteLine アクティビティが含まれます。

図 3. WriteLine アクティビティ

図 3. WriteLine アクティビティ

このアクティビティは、標準の .NET Windows コンソール アプリケーションの System.Diagnostics.Debug.WriteLine() メソッドに似たメッセージを書き込みます。 ワークフロー マネージャー 1.0 の開発ツールには Test Service Host という名前のコンソール ユーティリティが含まれ、新しいデバッグ セッションの開始時と社内 SharePoint 展開でのテスト時に Visual Studio 2012 によって開かれます。 次 Microsoft.Workflow.TestServiceHost.exeの図に示すように、C:\Program Files (x86)\ワークフロー マネージャー Tools\1.0 にあるこのコンソール ユーティリティは、登録済みのワークフロー マネージャー インスタンスにアタッチされ、WriteLine アクティビティを使用して書き込まれたメッセージをリッスンします。

図 4. WriteLine アクティビティのメッセージ

図 4. WriteLine アクティビティのメッセージ

これらのメッセージは、コンソール アプリケーションのコード コメントやデバッグ メッセージに似ています。 ワークフローの履歴リストへの書き込みと異なり、これらのメッセージはワークフローを運用に展開する前に削除する必要がありません。 Test Service Host ユーティリティがワークフロー マネージャーに接続されない限り、メッセージは無害です。

このデバッグ オプションは、SharePoint Designer 2013 を使用して作成されたワークフローでは使用できません。 これは、WriteLine アクティビティにマップされるアクションがないためです。 残念ながら、このデバッグ オプションは、テスト サービス ホスト ユーティリティで使用されるポートは通常、オンプレミス ネットワークの外部でパブリックにアクセスできないので、SharePoint オンプレミスのインストールでのみ使用できます。 これは、Office 365にも当てはまります。 SharePoint がワークフロー マネージャーに接続するために使用するポートは、テスト サービス ホストで使用されるものと同じポートであり、信頼されたネットワーク内でのみアクセスできます。 ただし、これは、デプロイ前に WriteLine アクティビティを削除するためにワークフローを変更する必要があることを意味Office 365。 これらのアクティビティは、テスト サービス ホストがワークフロー マネージャーに接続されていない限り表示されないため、ワークフローに残すことができます。

Fiddler を使用して HTTP トラフィックを監視するデバッグ

SharePoint ワークフローの最後のデバッグ オプションは、現行プラットフォームのワークフローの処理方法が変更されたために、ワークフロー開発者のために新しく追加されたものです。 前述したように、SharePoint ではすべてのワークフロー処理が外部製品であるワークフロー マネージャー 1.0 に渡されます。 ワークフローは、ワークフローの現在の状態の更新時、SharePoint サイトのアイテムまたはユーザーからのデータの収集時、タスクの操作時などに SharePoint と通信する必要があります。こうした操作を実行するために、ワークフロー マネージャーのアクティビティは SharePoint REST API を利用します。 SharePoint は、ワークフロー マネージャーが公開する REST サービスへのプロキシとして機能するクライアント ライブラリを使用してワークフロー マネージャーと通信します。 SharePoint とワークフロー マネージャーはどちらも、標準の HTTP プロトコルおよび HTTPS プロトコルを使用してお互いに通信します。

このアーキテクチャは、ワークフローの作成者に新しいデバッグ オプションをもたらします。 HTTP デバッグ プロキシ ツールの Fiddler を使用すると、2 製品間のすべての要求と対応する応答を監視できます。 また、Visual Studio 2012 の HttpSend アクティビティまたは SharePoint Designer 2013 の対応する Call HTTP Web Service アクションを使用してカスタム ワークフローによって呼び出される任意のカスタム サービスも Fiddler で監視および調査することができます。 このデバッグ モデルも、カスタム ワークフローの作成に使用するツール (SharePoint Designer 2013 または Visual Studio 2012) に関係なく利用できます。

このオプションは、SharePoint の Office 365 展開を使用してワークフローをテストしているときにのみ選択できなくなります。 SharePoint とワークフロー マネージャーの間のトラフィックはすべてサーバー側で発生するため、Office 365 のサーバーの 1 つに接続してコンソールから Fiddler を起動することは不可能です。

この新しいオプションにより、SharePoint 以前のバージョンの SharePoint でワークフローを開発するときには不可能だったワークフロー エンジンに対する透過性と洞察が得られます。

たとえば、Web サービスの呼び出しではワークフロー マネージャーまたは SharePoint から戻される生の応答を確認できます。 場合によっては、ワークフロー マネージャーが具体的なエラー メッセージで応答することもあります。 SharePoint には、わかりやすいエラー メッセージが含まれますが、このようなメッセージには具体性が不足しているもあります。 Fiddler を使用すると、問題のトラブルシューティングに役立つ正確なエラー メッセージを確認できます。

もう 1 つの使用例は、成功した Web サービスの呼び出しからの応答を調べることです。 ワークフローで Web サービスを操作するときは、作成ツールに関係なく、応答に含まれる値の正確なプロパティ名 (および複雑な応答の場合はパス) を知る必要があります。 Fiddler を使用すると、完全な応答データを確認することができます。

Fiddler を使用したデバッグのために SharePoint とワークフロー マネージャーについて理解する

Fiddler を使用して SharePoint とワークフロー マネージャー 1.0 でデバッグするには、デバッグの前に開発者の環境で構成と設定の手順をいくつか実行する必要があります。 手順を完了する前に、Fiddler の仕組みと SharePoint におけるワークフローの仕組みを理解しておくと役立ちます。

Fiddler はローカル サーバーからのトラフィックのみを調査できる

Fiddler で取得と調査が可能なトラフィックは、Fiddler が起動されたローカル サーバーからの要求のみです。 これは、SharePoint ワークフローのデバッグ ツールとして Fiddler を使用するときに問題になります。

SharePoint とワークフロー マネージャー 1.0 が、それぞれ別のサーバーにインストールされているときに、Fiddler が SharePoint Server から起動されたとすると、Fiddler に表示されるトラフィックは、SharePoint から要求が発生したトラフィックのみになります。 ワークフロー マネージャー 1.0 から発生するトラフィックは、SharePoint Server がターゲットだとしても取得されません。

そのため、ワークフローを開発するときに、SharePoint とワークフロー マネージャー 1.0 がどちらも同じサーバーにインストールされているとデバッグが簡単になります。 これは必要条件ではな点に注意してください。Fiddler は SharePoint Server とワークフロー マネージャー サーバーの両方で起動できます。ただし、同じワークフロー プロセスについて 2 台のサーバー上の 2 つのインスタンスを監視すること面倒な作業になります。

Fiddler は現在ログオンしているユーザーからのトラフィックのみを調査できる

Fiddler は現在ログオンしているユーザーからのトラフィックのみを取得して調査できます。 SharePoint から発生したトラフィックを表示するには、ワークフローを開始する SharePoint サイトの Web アプリケーションをホストするアプリケーション プールの ID として構成されている Windows アカウントを使用して SharePoint Server にログオンする必要があります。

同じことがワークフロー マネージャーにも当てはまります。 ワークフロー マネージャーから発生するトラフィックを取得して調査するには、ワークフロー マネージャーのサービス アカウントとしてワークフロー マネージャー ファームのプロビジョニング時に構成された Windows ID を使用してサーバーにログオンする必要があります。

Fiddler を使用してワークフローをデバッグするときに、ワークフロー マネージャーと SharePoint の両方が同じサーバーにインストールされていて構成されているだけでなく、サービス アカウントと同じ Windows ID を使用していると、さらにデバッグが簡単になります。 このようにすると、ワークフロー マネージャーと SharePoint の両方からのトラフィックを Fiddler ですべて取得して調査できます。

SharePoint は Fiddler の証明書を信頼する必要がある

SharePoint ワークフローのデバッグに Fiddler を使用する前に、暗号化されたトラフィックの処理方法について理解しておく必要があります。 HTTPS として知られている HTTP 経由の暗号化されたトラフィックは、データを暗号化してから別の受信者に送信するために証明書の秘密キーを使用して実装されます。 受信者は、秘密キーと対になっている証明書の公開キーを持っています。 受信者は要求を受信したときに、暗号化されたコンテンツの署名が公開キーと一致する (証明書の秘密キーで暗号化された場合にのみ当てはまる) ことから、要求が送信者から送られたことを検証できます。

Fiddler は HTTPS トラフィックを取得して、そのトラフィックを復号化するように構成できます。これにより、トラフィックはツールで検査する際に人間が判読できる形式になります。 要求を表示した後で、Fiddler は独自の証明書を使用してトラフィックを再び暗号化し、目的の受信者に送信します。 ただし、これが問題になることがあります。受信者は元の応答を受信しますが、この応答は元の送信者の証明書を使用してセキュリティ保護されていないためです。 これは、SharePoint ワークフローをデバッグするときに、Fiddler の証明書が SharePoint によって信頼されていないために問題になることがあります。 そのため、Fiddler を使用して SharePoint とワークフロー マネージャーの間の HTTPS トラフィックを取得して調査するには、Fiddler の証明書が SharePoint によって信頼される必要があります。

Fiddler を使用したワークフローのデバッグのために SharePoint とワークフロー マネージャー 1.0 を構成する

次のセクションでは、ワークフローのデバッグのために Fiddler と SharePoint を構成する方法について説明します。

.NET Framework の既定のプロキシ構成を設定する

最初の手順では、.NET Framework の既定のプロキシ構成を定義します。 ここに示す変更によって、Fiddler は SharePoint とワークフロー マネージャーの両方からのトラフィックを取得できるようになります。 次の両方の場所にある machine.config ファイルを開きます。

  • %systemdrive%\\Windows\\Microsoft.NET\\Framework\\v4.0.30319\\Config\\machine.config
  • %systemdrive%\\Windows\\Microsoft.NET\\Framework64\\v4.0.30319\\Config\\machine.config

次に、閉じる <構成要素> の直前にある各ファイルの下部に次のマークアップを追加します。

<system.net>
  <defaultProxy enabled="true">
    <proxy bypassonlocal="false" usesystemdefault="true" />
  </defaultProxy>
</system.net>

変更内容を保存し、ファイルを閉じます。

HTTPS トラフィックを取得して調査するように Fiddler を構成する

次の手順は、暗号化されたトラフィックを取得して構成のために復号化するように Fiddler を構成することです。

  1. Fiddler を起動します。
  2. ローカル HOSTS ファイルを使用している場合は、[ ツール ] -> [HOSTS ] メニュー オプションを選択して、エントリが Fiddler に含まれていることを確認します。
  3. [ Enable remapping of requests for one host to a different host or IP, overriding DNS] チェック ボックスをオンにします。
  4. [ Import Windows Hosts File] をクリックし、[ Save] ボタンをクリックします。
図 5. ホスト再マッピング

図 5. ローカル hosts ファイルを利用するための UI

次に、Fiddler の接続オプションを構成します。

  1. [ ツール ] -> [Fiddler オプション] メニュー オプションを選択します。

  2. [ Connections] タブをクリックします。

  3. [ Chain to upstream gateway proxy] チェック ボックスをオフにします。

  4. 次の図のように、[ Act as system proxy on startup] および [ Monitor all connections] のチェック ボックスをオンにします。

    図 6. Fiddler 接続オプション

  5. [ Fiddler Options] ダイアログで [ HTTPS] タブをクリックします。

  6. [ Capture HTTPS CONNECTs] チェック ボックスをオンにします。

  7. [Decrypt HTTPS Traffic] チェックボックスをオンにします。

  8. [… from all processes] を選択します。

  9. [Ignore server certificate errors] チェックボックスをオンにします。

  10. [ Export Root Certificate to Desktop] ボタンをクリックします。

  11. 警告のプロンプトが表示されたら、[ Yes] をクリックして Fiddler ルート証明書を信頼します ([ Trust the Fiddler Root certificate])。

このプロセスでは、SharePoint でまだ信頼されていない証明書を Windows が信頼するように構成します。

図 7. HTTPS タブ

図 7. HTTPS タブ

注:

Fiddler 証明書を信頼しないように指示するメッセージのあるセキュリティ警告が表示された場合は、[Yes] をクリックして証明書のインストールを続行します。

証明書を信頼するように SharePoint を構成する

最後の手順は、前の手順でエクスポートされた Fiddler 証明書を信頼するように SharePoint を構成することです。

  1. SharePoint ファーム管理者としてログオンします。

  2. SharePoint 管理シェルを起動します。

  3. SharePoint スナップインを読み込みます。

    Add-PSSnapIn Microsoft.SharePoint.PowerShell

  4. 証明書ユーティリティを使用して Fiddler 証明書をインストールします。

    $fidderCertificatePath = [full path to exported FiddlerRoot.cer certificate file]
certutil.exe -addstore -enterprise -f -v root $fidderCertificatePath
$fiddlerCertificate = Get-PfxCertificate -FilePath $fidderCertificatePath
New-SPTrustedRootAuthority -Name "Fiddler" -Certificate $fiddlerCertificate

  5. IISRESET を実行し、SharePoint が証明書の信頼の変更に対応するようにします。

チュートリアル: Fiddler を使用した SharePoint ワークフローのデバッグ

このシンプルなチュートリアルでは、Visual Studio 2012 を使用して作成した SharePoint ワークフローを Fiddler でデバッグする例を示します。 ワークフローが開始されると、カスタム リストのフィールドから顧客 ID が取得されます。 この顧客 ID は、公的にアクセス可能なサービスを照会し、客に関する追加の詳細情報を取得するために使用されます。 その後で、ワークフローはこれらの値を使用して元のリスト アイテムを更新します。 ワークフローについては、次の MSDN コード サンプル: SharePoint ワークフロー: 外部 Web サービスを呼び出す を参照してください。

このチュートリアルの前提条件は以下の通りです。

  • SharePoint とワークフロー マネージャー 1.0 が同じサーバーにインストールされている。

  • Windows ID CONTOSO\SP_Content は、ワークフローを開始する SharePoint サイトにサービスを提供する Web アプリケーションをホストするアプリケーション プール ID 用に構成されています。

  • ワークフローの開始に使用する SharePoint サイトが http://intranet.contoso.com である。

  • ワークフロー マネージャー 1.0 ファームのエンドポイントが w15sp.contoso.com である。

  • SharePoint とワークフロー マネージャー 1.0 が HTTP 経由の OAuth を許可するように構成されている。

    注意

    これはテストおよびデバッグ目的でのみ実行し、運用サーバーでは実行しないでください。

  1. ワークフロー マネージャー 1.0 ファーム アカウントおよび SharePoint アプリケーション プール ID として構成されている Windows ID を使用して、ワークフロー マネージャーと SharePoint がインストールされているサーバーにログオンします。

  2. Fiddler を起動します。 Fiddler が現在のユーザーからのトラフィックを取得する間に既存の接続または実行中のプロセスがあった場合、接続が最初に確立されたときに Fiddler が実行されていなかったためにこれらを見逃すことがあります。 ワークフロー マネージャーと SharePoint Server がリサイクルされ、お互いのトラフィックが Fiddler で取得されるようにするには、IISRESET を実行して SharePoint をリサイクルし、Windows サービス Workflow Manager Backend を停止してから起動してワークフロー マネージャをリサイクルします。 これは、管理コマンド プロンプトで次の 2 つのコマンドを使用して実行できます。

    IISRESET
net stop WorkflowServiceBackend
net start WorkflowServiceBackend

  3. ワークフローを開始します。

以下の図で、SharePoint から発生したセッション #18 ～ 36 と、ワークフロー マネージャーから発生した #37 ～ 43 に注目してください。

図 8. ワークフローの開始

図 8. ワークフローの開始

セッション #36 の場合、SharePoint はワークフロー マネージャーがワークフローを開始し (図の [A])、ワークフロー マネージャーが "Success" メッセージで応答すること (図の [B]) を要求しています。

図 9. "Success" メッセージ応答

図 10. 成功メッセージ

セッション #40 は、ワークフロー マネージャーが SharePoint からリスト アイテム ID と GUID を取得しているところです。

図 10. アイテム ID と GUID の取得

図 10. 取得リスト アイテムの ID と GUID

セッション #43 は、ワークフロー マネージャーが、JavaScript Object Notation (JSON) オブジェクト (図の [A]) をペイロードと共に渡すことにより、SharePoint のリスト アイテムをお知らせアイテムの [ Body] フィールドの新しい値に更新しているところです。 SharePoint は HTTP ステータス 204 で応答し、要求を正常に処理したが応答にメッセージがないことを示します。

図 11. リスト アイテムの更新

図 11. SharePoint でリスト アイテムの更新

まとめ

SharePoint リリースのワークフロー ストーリーには、新しい抽象層のワークフロー マネージャー 1.0 が導入されました。 この新しいアーキテクチャにより、ワークフローの処理方法が変更されています。 SharePoint では、すべてのワークフロー処理と管理をワークフロー マネージャー 1.0 に依存するようになりました。

ワークフローでカスタム アプリケーションとビジネス プロセスを作成するときには、タスクの 1 つとして作業のデバッグを実行する必要があります。 SharePoint の新しいワークフロー アーキテクチャでは、以前の SharePoint と同じデバッグ オプションが提供されています。 ただし、新しいアーキテクチャでは、新しいアーキテクチャを使用してカスタム ワークフローを作成するときに 2 つの新しいオプションも選択できます。 この記事では、以前のデバッグ オプションに加えて、新しいデバッグ オプション (WriteLine アクティビティを使用するオプションと、Fiddler を使用して SharePoint とワークフロー マネージャー 1.0 の間のトラフィックを取得して調査するオプション) について説明しました。

関連項目