次の方法で共有


Azure Logic Appsで HTTP Webhook を使用して、サービス エンドポイント イベントに基づいてワークフローまたはアクションを実行する

適用対象: Azure Logic Apps (従量課金 + 標準)

ワークフロー トリガーまたはアクションが実行前にイベントまたはデータがターゲット サービス エンドポイントに到着するのを待機する場合は、スケジュールに従ってエンドポイントを事前に確認するのではなく、 HTTP Webhook トリガーまたはアクションを使用します。 HTTP Webhook トリガーまたはアクションは、サービス エンドポイントをサブスクライブし、実行する前に新しいイベントまたはデータを待機します。 Webhook パターンは、実行時間の長いタスクや非同期処理に使用できます。

次の一覧では、Webhook ベースのワークフローの例について説明します。

  • HTTP Webhook トリガーは、ワークフローを実行する前にAzure Event Hubsからイベントが到着するのを待機します。
  • HTTP Webhook アクションは、ワークフローの次のアクションを続行する前に、Office 365 Outlookでの承認を待機します。

このガイドでは、 ワークフロー がサービス エンドポイントで新しいイベントまたはデータを受信して応答できるように 、HTTP Webhook トリガーと HTTP Webhook アクションを設定する方法について説明します。

Webhook のしくみ

Webhook トリガーまたはアクションは、ターゲット サービス エンドポイントで新しいイベントまたはデータを ポーリング したり、事前にチェックしたりしません。 代わりに、トリガーまたはアクションは、新しいイベントまたはデータがサービス エンドポイントに到着するまで待機してから実行されます。 Webhook トリガーまたはアクションをワークフローに追加してワークフローを保存した後、または無効なロジック アプリ リソースを再び有効にした後、Webhook トリガーまたはアクションは、エンドポイントにコールバック URL を生成して登録することで、サービス エンドポイントをサブスクライブします。 トリガーまたはアクションは、サービス エンドポイントが URL を呼び出すのを待機し、トリガーまたはアクションを実行します。 要求トリガーと同様に、HTTP Webhook トリガーはすぐに起動します。

たとえば、Office 365 Outlook コネクタ アクション (Send approval email は webhook パターンに従いますが、Office 365 Outlookでのみ機能します。 必要なサービス エンドポイントで HTTP Webhook トリガーまたはアクションを使用して 、Webhook パターンを任意のサービスに拡張できます。

Webhook トリガーは、次のいずれかのアクションを手動で実行するまで、サービス エンドポイントにサブスクライブされた状態を維持します。

  • トリガーのパラメーター値を変更します。
  • トリガーを削除し、ワークフローを保存します。
  • ロジック アプリ リソースを無効にします。

Webhook アクションは、次のいずれかの条件が発生しない限り、サービス エンドポイントにサブスクライブしたままです。

  • Webhook アクションが正常に終了した。
  • 応答の待機中にワークフローの実行を取り消します。
  • ワークフローはタイムアウトになります。
  • Webhook トリガーが入力として使用する Webhook アクション パラメーター値を変更します。

詳細については、以下を参照してください:

前提条件

  • Azure アカウントとサブスクリプション。 無料のAzure アカウントを取得します。

  • デプロイされたサービス エンドポイントまたは API の URL。

    この項目は、ワークフロー内の Webhook トリガーまたはワークフロー内の webhook アクションの "サブスクライブとサブスクライブ解除" パターン サポートする必要があります。

  • HTTP Webhook トリガーまたはアクションを使用したい Standard または Consumption ロジック アプリ ワークフロー。

    • HTTP Webhook トリガーを使用するには、空のワークフローを含むロジック アプリ リソースを作成します。
    • HTTP Webhook アクションを使用するには、シナリオに最適なトリガーを使用してワークフローを開始します。 この例では、 HTTP Webhook トリガーを使用します。

HTTP Webhook トリガーの追加

この組み込みトリガーは、ターゲット サービスでサブスクライブ エンドポイントを呼び出し、そのコールバック URL をターゲット サービスに登録します。 その後、ワークフローは、ターゲット サービスがコールバック URL に HTTP POST 要求を送信するのを待ちます。 このイベントが発生すると、トリガーが起動され、要求内のすべてのデータがワークフローに渡されます。

  1. Azure ポータルで、ロジック アプリ リソースを開きます。 デザイナーで、空のワークフローを開きます。

  2. 一般的な手順に従って、HTTP Webhook という名前のトリガーをワークフローに追加します。

    次の使用例は、トリガーの名前を Run HTTP Webhook trigger わかりやすい名前に変更します。 この例では、後で HTTP Webhook アクションも追加します。 どちらの名前も一意である必要があります。

  3. HTTP Webhook トリガー パラメーターの場合は、サブスクライブ呼び出しとサブスクライブ解除呼び出しの値を指定します。

    パラメーター 必須 説明
    サブスクライブ メソッド はい ターゲット エンドポイントに登録するために使用する方法。
    購読 URI はい ターゲット エンドポイントのサブスクライブに使用する URL。
    本文をサブスクライブする いいえ サブスクライブ要求に含めるメッセージ本文。 この例には、 listCallbackUrl() 式関数 を使用してトリガーのコールバック URL を取得することで、サブスクライバー (ワークフロー) を一意に識別するコールバック URL が含まれています。
    配信停止の本文 いいえ サブスクライブ解除要求に含めるメッセージ本文。 listCallbackUrl()式関数を使用して、アクションのコールバック URL を取得できます。 ただし、トリガーには、ターゲット サービスがサブスクライバーを一意に識別するために使用できるヘッダー、 x-ms-client-tracking-idx-ms-workflow-operation-nameも自動的に含まれ、送信されます。
  4. 他のトリガー パラメーターを追加するには、[ 詳細パラメーター ] 一覧を開きます。

    たとえば、 Unsubscribe メソッドUnsubscribe URI パラメーターを使用するには、[ 詳細パラメーター ] リストから追加します。

    次の例は、サブスクライブおよびサブスクライブ解除メソッドに使用するメソッド、URI、メッセージ本文を含むトリガーを示しています。

    HTTP Webhook トリガー パラメーターを含むワークフローを示すスクリーンショット。

  5. 認証を使用する必要がある場合は、[詳細パラメーター] 一覧から [サブスクライブ認証] パラメーターと [認証のサブスクライブ解除] パラメーターを追加します。

    HTTP Webhook で使用できる認証の種類の詳細については、「送信呼び出しに認証を追加する」を参照してください。

  6. シナリオに必要なその他のアクションを追加します。

  7. 完了したら、ワークフローを保存します。 デザイナーのツール バーで、[保存] を選択します。

ワークフローを保存すると、ターゲット サービスでサブスクライブ エンドポイントが呼び出され、コールバック URL が登録されます。 ワークフローは、ターゲット サービスがコールバック URL に HTTP POST 要求を送信するのを待機します。 このイベントが発生すると、トリガーが起動し、要求内のすべてのデータがワークフローに渡されます。 この操作が正常に完了すると、トリガーはエンドポイントのサブスクライブを解除し、ワークフローは次のアクションに進みます。

HTTP Webhook アクションの追加

この組み込みアクションは、ターゲット サービスでサブスクライブ エンドポイントを呼び出し、そのコールバック URL をターゲット サービスに登録します。 その後、ワークフローは一時停止し、ターゲット サービスがコールバック URL に HTTP POST 要求を送信するまで待機します。 このイベントが発生すると、アクションは要求内のすべてのデータをワークフローに渡します。 操作が正常に完了すると、アクションはエンドポイントからサブスクライブ解除され、ワークフローは次のアクションに進みます。

  1. Azure ポータルで、ロジック アプリ リソースを開きます。 デザイナーでワークフローを開く。

  2. 一般的な手順に従って、HTTP Webhook という名前のアクションをワークフローに追加します。

    次の使用例は、アクションの名前を Run HTTP Webhook action わかりやすい名前に変更します。 ワークフローで HTTP Webhook トリガーも使用する場合は、両方の名前が一意である必要があります。

  3. HTTP Webhook アクション パラメーターの場合は、サブスクライブ呼び出しとサブスクライブ解除呼び出しに使用する値を指定します。

    パラメーター 必須 説明
    サブスクライブ メソッド はい ターゲット エンドポイントに購読するために使用するメソッド。
    購読 URI はい ターゲット エンドポイントのサブスクライブに使用する URL。
    本文をサブスクライブする いいえ サブスクライブ要求に含めるメッセージ本文。 この例には、 listCallbackUrl() 式関数 を使用してアクションのコールバック URL を取得することで、サブスクライバー (ワークフロー) を一意に識別するコールバック URL が含まれています。
    配信停止の本文 いいえ サブスクライブ解除要求に含めるメッセージ本文。 listCallbackUrl()式関数を使用して、アクションのコールバック URL を取得できます。 ただし、ターゲット サービスがサブスクライバーを一意に識別するために使用できるヘッダー、 x-ms-client-tracking-idx-ms-workflow-operation-nameもアクションに自動的に含まれ、送信されます。
  4. 他のアクション パラメーターを追加するには、[ 詳細パラメーター ] 一覧を開きます。

    たとえば、 Unsubscribe メソッドUnsubscribe URI パラメーターを使用するには、[ 詳細パラメーター ] リストから追加します。

    次の例は、サブスクライブおよびサブスクライブ解除メソッドに使用するメソッド、URI、メッセージ本文を含むアクションを示しています。

    HTTP Webhook アクション パラメーターを含む Standard ワークフローを示すスクリーンショット。

  5. 認証を使用する必要がある場合は、[詳細パラメーター] 一覧から [サブスクライブ認証] パラメーターと [認証のサブスクライブ解除] パラメーターを追加します。

    HTTP Webhook で使用できる認証の種類の詳細については、「送信呼び出しに認証を追加する」を参照してください。

  6. シナリオに必要なその他のアクションを追加します。

  7. 完了したら、ワークフローを保存します。 デザイナーのツール バーで、[保存] を選択します。

このアクションが実行されると、ワークフローはターゲット サービスでサブスクライブ エンドポイントを呼び出し、コールバック URL を登録します。 ワークフローは一時停止し、ターゲット サービスがコールバック URL に HTTP POST 要求を送信するまで待機します。 このイベントが発生すると、アクションは要求内のすべてのデータをワークフローに渡します。 操作が正常に完了すると、アクションはエンドポイントからサブスクライブ解除され、ワークフローは次のアクションに進みます。

コネクタに関するテクニカル リファレンス

HTTP Webhook トリガーとアクション パラメーターの詳細については、「HTTP Webhook パラメーター」を参照してください。 トリガーとアクションには同じパラメーターがあります。

Shared Access Signature (SAS) トークンの有効期限

HTTP Webhook トリガーまたはアクションのコールバック URL は、リスト コールバック URL - REST API メソッドによって自動的に生成されます。 既定では、コールバック URL の SAS トークンには時間ベースの有効期限はありません。 コールバック URL は、ワークフローの実行期間にわたって有効なままです。

タイムアウトの制限

次の表では、ロジック アプリのホスティング オプションに基づく HTTP Webhook アクションのタイムアウト制限について説明します。

ホスティング オプション ワークフローの種類 期間
従量課金 Stateful 最大 90 日。
Standard Stateful 最大 30 日。
Standard ステートレス 5 分
(固定制限)

HTTP Webhook アクションのコールバック URL は、次のイベントが発生すると無効になります。

  • ワークフローを取り消します。
  • ワークフローまたはロジック アプリ リソースを削除または無効にします。
  • ワークフローのアクセス キーをローテーションします。
  • ワークフローはタイムアウトになります。

その他の HTTP 制限については、Azure Logic Appsを参照してください。

タイムアウト制限の変更

Azure ポータルを使用してステートフル ワークフローの HTTP Webhook アクションのこの制限を変更するには、送信 HTTP 要求の Timeout 期間の表を参照してください。 または、アクションの JSON 定義で、 limit.timeout オブジェクトを追加し、必要な期間に値を設定します。次に例を示します。

{
   "actions": {
      "Run_HTTP_Webhook_action": {
         "type": "HttpWebhook",
         "inputs": {
            "subscribe": {
               "method": "POST",
               "uri": "https://<external-service>.com/subscribe",
               "body": {
                  "callbackUrl": "@{listCallBackUrl()}"
               }
            },
            "unsubscribe": {}
         },
         "limit": {
            "timeout": "PT1H"
         }
      }
   }
}

トリガーとアクションの出力

次の表は、 HTTP Webhook トリガーまたはアクションによって返される出力の詳細を示しています。

JSON での名前 タイプ 説明
headers JSON オブジェクト リクエストのヘッダー。
body JSON オブジェクト リクエストの本文の内容を持つオブジェクト。
status code 整数 (int) 要求の状態コード。
status code 説明
200 [OK]
202 受け入れられた
400 要求が正しくありません
401 権限がありません
403 Forbidden
404 見つかりません
500 内部サーバー エラー。 不明なエラーが発生しました。

セカンダリ アクセス キーを使用してコールバック URL を生成する

ロジック アプリ ワークフローには、プライマリとセカンダリの 2 つのアクセス キーがあります。 既定では、Azure Logic Appsは主キーを使用して HTTP webhook トリガーのコールバック URL を生成します。

代わりに、コールバック URL の生成にセカンダリ キーを使用するには、次の手順に従います。

  1. ワークフロー デザイナーを使用している場合は、コード ビューに切り替えます。

  2. HttpWebhook トリガー定義で、accessKeyType パラメーターを見つけます。

  3. パラメーター値として単語 Secondary を入力します。

  4. 変更を保存。

次の例は、 accessKeyType パラメーターを Secondary に設定した webhook トリガー定義を示しています。

{
  "type": "HttpWebhook",
  "inputs": {
    "subscribe": {
      "method": "POST",
      "uri": "<subscription-URL>",
      "body": "@listCallbackUrl()"
    },
    "accessKeyType": "Secondary"
  },
  "runAfter": {}
}