Azure Logic Apps のワークフローに対する受信 HTTP 呼び出しを受け取り、応答する

[アーティクル]
01/10/2024

適用対象: Azure Logic Apps (従量課金プラン + Standard)

この攻略ガイドでは、組み込みの Request トリガーを使用して他のサービスから受信 HTTPS 要求 (または呼び出し) を受信して操作できるロジックアプリワークフローを作成する方法について説明します。ワークフローがこのトリガーを使用すると、組込みの Response アクションを使用して HTTPS 要求に応答できるようになります。

Note

Response アクションが機能するのは、Request トリガーを使用するときのみです。

たとえば、この一覧では Request トリガーと Response アクションを使用するとワークフローで実行できるいくつかのタスクについて説明しています。

オンプレミスデータベース内のデータに対する HTTPS 要求を受信して応答する。
別のロジックアプリワークフローから送信された HTTPS 要求を受信して応答します。
外部 Webhook イベントが発生したときにワークフローの実行をトリガーする。

代わりに送信要求を送信してワークフローを実行するには、HTTP 組み込みトリガーまたは HTTP 組み込みアクションを使用します。

前提条件

Azure アカウントとサブスクリプション。サブスクリプションがない場合は、無料の Azure アカウントにサインアップできます。
受信 HTTPS 要求を受信するロジックアプリワークフロー。 Request トリガーでワークフローを開始するには、空のワークフローから開始する必要があります。 Response アクションを使用するには、ワークフローが Request トリガーで開始されている必要があります。

HTTP 要求を送信してソリューションをテストできる次のようなツールをインストールまたは使用します。
注意事項

資格情報、シークレット、アクセストークン、API キーなどの機密データがあるシナリオでは、必要なセキュリティ機能でデータを保護したうえで、ツールは必ずオフラインまたはローカルで動作し、データをクラウドに同期せず、オンラインアカウントにサインインする必要がないものを使用してください。このようにすることで、機密データを一般に公開するリスクを軽減できます。

Request トリガーの追加

この Request トリガーは、HTTPS 経由の受信要求のみを処理する、手動で呼び出し可能なエンドポイントを作成します。呼び出し元がこのエンドポイントに要求を送信すると、Request トリガーが起動され、ワークフローが実行されます。このトリガーを呼び出す方法の詳細については、Azure Logic Apps での HTTPS エンドポイントを使用したワークフローの呼び出し、トリガー、または入れ子に関するページを確認してください。

従量課金プラン
Standard

Azure portal で、従量課金ロジックアプリと空のワークフローをデザイナーで開きます。
デザイナーで、こちらの一般的な手順に従って、「When a HTTP request is received」という名前の組み込み要求トリガーを見つけて追加します。

トリガー情報ボックスが表示されたら、次の情報を必要に応じて入力します。

プロパティ名	JSON プロパティ名	必須	説明
HTTP POST の URL	{なし}	はい	ワークフローを保存した後に生成され、ワークフローをトリガーする要求の送信に使用されるエンドポイント URL。
要求本文の JSON スキーマ	`schema`	いいえ	受信要求本文内のプロパティと値を記述する JSON スキーマ。デザイナーでは、このスキーマを使用して、要求内のプロパティ用のトークンが生成されます。このようにして、ワークフローは、Request トリガーからの出力を解析し、使用し、ワークフローに渡すことができます。 JSON スキーマがない場合は、[サンプルのペイロードを使用してスキーマを生成する] の機能を使用して、サンプルペイロードからスキーマを生成することができます。

次の例は、サンプル JSON スキーマを示しています。

従量課金プランのワークフローと Request トリガーを JSON スキーマの例で示したスクリーンショット。

次の例は、完全なサンプル JSON スキーマを示しています。

{
   "type": "object",
   "properties": {
      "account": {
         "type": "object",
         "properties": {
            "name": {
               "type": "string"
            },
            "ID": {
               "type": "string"
            },
            "address": {
               "type": "object",
               "properties": {
                  "number": {
                     "type": "string"
                  },
                  "street": {
                     "type": "string"
                  },
                  "city": {
                     "type": "string"
                  },
                  "state": {
                     "type": "string"
                  },
                  "country": {
                     "type": "string"
                  },
                  "postalCode": {
                     "type": "string"
                  }
               }
            }
         }
      }
   }
}

JSON スキーマを入力すると、デザイナーにリマインダーが表示され、ご自分の要求に Content-Type ヘッダーを含め、そのヘッダー値を application/json に設定するように促されます。詳細については、コンテンツタイプの処理に関するページを参照してください。

従量課金プランのワークフロー、Request トリガー、および

次の例は、Content-Type ヘッダーが JSON 形式でどのように表示されるかを示したものです。

{
   "Content-Type": "application/json"
}

予期されるペイロード (データ) に基づく JSON スキーマを生成するには、JSONSchema.net などのツールを使用するか、または次の手順を行います。

[要求] トリガーで、 [サンプルのペイロードを使用してスキーマを生成する] を選択します。

サンプルペイロードを入力して、[完了] を選択します。

従量課金プランのワークフロー、Request トリガー、およびスキーマを生成するためのサンプルペイロードが入力されたスクリーンショット。

次の例は、サンプルペイロードを示しています。

{
   "account": {
      "name": "Contoso",
      "ID": "12345",
      "address": {
         "number": "1234",
         "street": "Anywhere Street",
         "city": "AnyTown",
         "state": "AnyState",
         "country": "USA",
         "postalCode": "11111"
      }
   }
}

指定したスキーマに一致する要求本文が受信呼び出しに含まれることを確認するには、次の手順に従います。
1. スキーマで記述されているのとまったく同じフィールドを受信メッセージに強制するには、スキーマに required プロパティを追加し、必須フィールドを指定します。 addtionalProperties プロパティを追加し、値を false に設定します。
  
  たとえば、次のスキーマでは、受信メッセージには msg フィールドが必要で、他のフィールドは必要ないことが指定されています。
```
{
   "properties": {
     "msg": {
        "type": "string"
     }
   },
   "type": "object",
   "required": ["msg"],
   "additionalProperties": false
}
```
2. Request トリガーのタイトルバーにある省略記号 (...) ボタンを選択します。
3. トリガーの設定で [スキーマの検証] をオンにし、[完了] を選択します。
  
  受信呼び出しの要求本文がスキーマと一致しない場合、トリガーからは HTTP 400 Bad Request エラーが返されます。

トリガーに他のプロパティやパラメーターを追加するには、[新しいパラメーターの追加] リストを開き、追加するパラメーターを選択します。

プロパティ名	JSON プロパティ名	必須	説明
方法	`method`	いいえ	ロジックアプリを呼び出すために受信要求で使用する必要があるメソッド
相対パス	`relativePath`	いいえ	ロジックアプリのエンドポイント URL で受け入れ可能なパラメーターの相対パス

以下の例では、[メソッド] プロパティを追加します。

従量課金プランのワークフロー、Request トリガー、および

[メソッド] プロパティがトリガー内に表示されるので、一覧からメソッドを選択できます。

従量課金プランのワークフロー、Request トリガー、および

準備が整ったら、ワークフローを保存します。デザイナーツールバーで、保存を選択します。

この手順により、ワークフローをトリガーする要求を送信するために使用する URL が生成されます。
生成された URL をコピーするには、URL の横にあるコピーアイコンを選択します。

Note

Request トリガーを呼び出すとき、ハッシュまたはシャープ記号 (#) を URI に含める場合は、エンコードされたバージョン %25%23 を代わりに使用します。

Azure portal で、Standard ロジックアプリリソースと空のワークフローをデザイナーで開きます。
デザイナーで、こちらの一般的な手順に従って、「When a HTTP request is received」という名前の組み込み要求トリガーを見つけて追加します。

トリガー情報ボックスが表示されたら、次の情報を必要に応じて入力します。

プロパティ名	JSON プロパティ名	必須	説明
HTTP POST の URL	{なし}	はい	ワークフローを保存した後に生成され、ワークフローをトリガーする要求の送信に使用されるエンドポイント URL。
要求本文の JSON スキーマ	`schema`	いいえ	受信要求本文内のプロパティと値を記述する JSON スキーマ。デザイナーでは、このスキーマを使用して、要求内のプロパティ用のトークンが生成されます。このようにして、ワークフローは、Request トリガーからの出力を解析し、使用し、ワークフローに渡すことができます。 JSON スキーマがない場合は、[サンプルのペイロードを使用してスキーマを生成する] の機能を使用して、サンプルペイロードからスキーマを生成することができます。

次の例は、サンプル JSON スキーマを示しています。

Standard ワークフローと Request トリガーを JSON スキーマの例で示したスクリーンショット。

次の例は、完全なサンプル JSON スキーマを示しています。

{
   "type": "object",
   "properties": {
      "account": {
         "type": "object",
         "properties": {
            "name": {
               "type": "string"
            },
            "ID": {
               "type": "string"
            },
            "address": {
               "type": "object",
               "properties": {
                  "number": {
                     "type": "string"
                  },
                  "street": {
                     "type": "string"
                  },
                  "city": {
                     "type": "string"
                  },
                  "state": {
                     "type": "string"
                  },
                  "country": {
                     "type": "string"
                  },
                  "postalCode": {
                     "type": "string"
                  }
               }
            }
         }
      }
   }
}

Standard ワークフロー、Request トリガー、および

次の例は、Content-Type ヘッダーが JSON 形式でどのように表示されるかを示したものです。

{
   "Content-Type": "application/json"
}

予期されるペイロード (データ) に基づく JSON スキーマを生成するには、JSONSchema.net などのツールを使用するか、または次の手順を行います。

[要求] トリガーで、 [サンプルのペイロードを使用してスキーマを生成する] を選択します。

サンプルペイロードを入力して、[完了] を選択します。

Standard ワークフロー、Request トリガー、および [サンプルのペイロードを使用してスキーマを生成する] が選択されたスクリーンショット。

次の例は、サンプルペイロードを示しています。

{
   "account": {
      "name": "Contoso",
      "ID": "12345",
      "address": {
         "number": "1234",
         "street": "Anywhere Street",
         "city": "AnyTown",
         "state": "AnyState",
         "country": "USA",
         "postalCode": "11111"
      }
   }
}

指定したスキーマに一致する要求本文が受信呼び出しに含まれることを確認するには、次の手順に従います。
1. スキーマで記述されているのとまったく同じフィールドを受信メッセージに強制するには、スキーマに required プロパティを追加し、必須フィールドを指定します。 addtionalProperties プロパティを追加し、値を false に設定します。
  
  たとえば、次のスキーマでは、受信メッセージには msg フィールドが必要で、他のフィールドは必要ないことが指定されています。
```
{
   "properties": {
     "msg": {
        "type": "string"
     }
   },
   "type": "object",
   "required": ["msg"],
   "additionalProperties": false
}
```
2. デザイナーで、Request トリガーを選択します。情報ペインが開いたら、[設定] タブを選択します。
3. [Data Handling] を展開して、[スキーマの検証] を [オン] に設定します。
  
  受信呼び出しの要求本文がスキーマと一致しない場合、トリガーからは HTTP 400 Bad Request エラーが返されます。

トリガーに他のプロパティやパラメーターを追加するには、[パラメーター] タブを開き、[新しいパラメーターの追加] リストを開き、追加するパラメーターを選択します。

プロパティ名	JSON プロパティ名	必須	説明
方法	`method`	いいえ	ロジックアプリを呼び出すために受信要求で使用する必要があるメソッド
相対パス	`relativePath`	いいえ	ロジックアプリのエンドポイント URL で受け入れ可能なパラメーターの相対パス

以下の例では、[メソッド] プロパティを追加します。

Standard ワークフロー、Request トリガー、および

[メソッド] プロパティがトリガー内に表示されるので、一覧からメソッドを選択できます。

Standard ワークフロー、Request トリガー、および

準備が整ったら、ワークフローを保存します。デザイナーツールバーで、保存を選択します。

この手順により、ワークフローをトリガーする要求を送信するために使用する URL が生成されます。
生成された URL をコピーするには、URL の横にあるコピーアイコンを選択します。

Note

Request トリガーを呼び出すとき、ハッシュまたはシャープ記号 (#) を URI に含める場合は、エンコードされたバージョン %25%23 を代わりに使用します。

Request トリガーの URL は、ワークフローのストレージアカウントに関連付けられています。この URL は、ストレージアカウントが変更されると変わります。たとえば、Standard ロジックアプリでは、ストレージアカウントを手動で変更してワークフローを新しいストレージアカウントにコピーすると、Request トリガーの URL も変更されて新しいストレージアカウントを反映します。同じワークフローは異なる URL を持ちます。

ステートレスワークフローのスキーマの検証

ステートレスワークフローのスキーマの検証を有効にするには、ロジックアプリリソースまたはプロジェクトの host.json ファイル内に以下のホスト設定があることを確認します。

"extensions": {
   "workflow": {
      "Settings": {
         "Runtime.StatelessFlowEvaluateTriggerCondition": "true"
      }
   }
}

次に、次の手順として別のアクションを追加して、ワークフローの構築を続けましょう。たとえば、応答アクションを追加することによって、要求に応答することができます。応答アクションは、カスタマイズした応答を返す場合に使用できます。これについては、この記事の後半で説明します。

Note

ワークフローは、受信要求を限られた時間だけ開いたままにします。ワークフローに応答アクションが含まれている場合、この時間が経過する前にワークフローから呼び出し元に応答が返されないと、ワークフローから呼び出し元に 504 GATEWAY TIMEOUT 状態が返されます。ワークフローに応答アクションが含まれていない場合、ワークフローから呼び出し元に、直ちに 202 ACCEPTED 状態が返されます。

ワークフローのインバウンド呼び出しのセキュリティ、認証、暗号化に関する情報 (トランスポート層セキュリティ (TLS) (旧称 Secure Sockets Layer (SSL))、Microsoft Entra ID を使用した OAuth、Shared Access Signatures (SAS)、Azure API Management を使用したロジックアプリリソースの公開、インバウンド呼び出しを発生させる IP アドレスの制限など) については、「アクセスとデータのセキュリティ保護 - 要求ベースのトリガーへのインバウンド呼び出しのアクセス」を参照してください。

トリガー出力

次の表は、Request トリガーからの出力を一覧にまとめたものです。

JSON プロパティ名	データ型	説明
headers	オブジェクト	要求のヘッダーを記述する JSON オブジェクト
body	オブジェクト	要求の本文のコンテンツを記述する JSON オブジェクト

Response アクションを追加する

Request トリガーを使用して受信要求を受け取る場合は、Response 組み込みアクションを使うことで、応答をモデル化し、ペイロードの結果を呼び出し元に送り返すことができます (これは Request トリガーのみで機能します)。この Request トリガーと Response アクションの組み合わせによって、要求 - 応答パターンが作成されます。 Response アクションは、Foreach ループと Until ループや並列分岐の内部を除き、ワークフロー内のどこにでも追加できます。

重要

応答アクションに以下のヘッダーが含まれている場合、Azure Logic Apps は警告もエラーも表示せずに、生成された応答メッセージからこれらのヘッダーを自動的に削除します。 Azure Logic Apps によってこれらのヘッダーが追加されることはありませんが、これらのヘッダーを含む応答アクションが追加されたワークフローの保存は、サービス側で停止されません。
- Allow
- Content-Disposition、Content-Encoding、および Content-Type を除く Content-* ヘッダー (POST と PUT 操作を使用する場合。ただし GET 操作については含まれない)
- Cookie
- Expires
- Last-Modified
- Set-Cookie
- Transfer-Encoding
分岐を含む複雑なワークフローに 1 つ以上の応答アクションがある場合は、ワークフローで、少なくとも 1 つの応答アクションが実行時に処理されるようにしてください。そうしない場合、すべての Response アクションがスキップされると、ワークフローが正常に終了した場合でも、呼び出し元は 502 無効なゲートウェイ エラーを受け取ります。
Standard ロジックアプリの "ステートレス" ワークフローでは、応答アクションはワークフローの最後に表示される必要があります。アクションがそれ以外の場所に表示されていても、他のすべてのアクションの実行が完了するまでは、Azure Logic Apps はアクションを実行しません。

従量課金プラン
Standard

ワークフローデザイナーで、こちらの一般的な手順に従って、[応答] という名前の応答組み込みアクションを見つけて追加します。

わかりやすくするために、以下の例では、Request トリガーを折りたたんで表示します。

アクション情報ボックスに、応答メッセージに必要な値を追加します。

プロパティ名	JSON プロパティ名	必須	説明
状態コード	`statusCode`	はい	応答で返される状態コード
ヘッダー	`headers`	いいえ	応答に含める 1 つまたは複数のヘッダーを記述する JSON オブジェクト
本文	`body`	いいえ	応答本文

いずれかのテキストフィールドの内部を選択すると、動的コンテンツリストが自動的に開きます。次に、ワークフローの前のステップからの使用可能なあらゆる出力を表すトークンを選択できます。指定するスキーマからのプロパティも、この動的コンテンツの一覧に表示されます。これらのプロパティを選択してワークフローで使用できます。

たとえば、[ヘッダー] フィールドで、キー名として Content-Type を指定し、キー値についてはこの記事で既に説明したように application/json に設定します。 [本文] ボックスでは、動的コンテンツの一覧からトリガー本文の出力を選択できます。

Azure portal、従量課金プランのワークフロー、および応答アクションの情報を示すスクリーンショット。

ヘッダーを JSON 形式で表示するには、[Switch to text view]\(テキストビューに切り替え\) を選択します。

Azure portal、従量課金プランのワークフロー、および

応答本文用の JSON スキーマなど、アクションのプロパティをさらに追加するには、[新しいパラメーターの追加] リストから、追加するパラメーターを選択します。
完了したら、ワークフローを保存します。デザイナーのツールバーで、 [保存] を選択します。

ワークフローデザイナーで、こちらの一般的な手順に従って、[応答] という名前の応答組み込みアクションを見つけて追加します。

アクション情報ボックスに、応答メッセージに必要な値を追加します。

プロパティ名	JSON プロパティ名	必須	説明
状態コード	`statusCode`	はい	応答で返される状態コード
ヘッダー	`headers`	いいえ	応答に含める 1 つまたは複数のヘッダーを記述する JSON オブジェクト
本文	`body`	いいえ	応答本文

いずれかのテキストフィールドの内部を選択すると、動的コンテンツリストを開くオプションが表示されます (稲妻のアイコン)。次に、ワークフローの前のステップからの使用可能なあらゆる出力を表すトークンを選択できます。指定するスキーマからのプロパティも、この動的コンテンツの一覧に表示されます。これらのプロパティを選択してワークフローで使用できます。

たとえば、[ヘッダー] ボックスでは、キー名として Content-Type を入力し、キー値についてはこの記事で既に説明したように application/json に設定します。 [本文] ボックスでは、動的コンテンツの一覧からトリガー本文の出力を選択できます。

Azure portal、Standard ワークフロー、および応答アクションの情報を示すスクリーンショット。

ヘッダーを JSON 形式で表示するには、[Switch to text view]\(テキストビューに切り替え\) を選択します。

Azure portal、Standard ワークフロー、および

応答本文用の JSON スキーマなど、アクションのプロパティをさらに追加するには、[新しいパラメーターの追加] リストを開いて、追加するパラメーターを選択します。
完了したら、ワークフローを保存します。デザイナーのツールバーで、 [保存] を選択します。

ワークフローのテスト

ワークフローをトリガーするには、HTTP 要求ツールとその手順を使用して、Request トリガーに対して生成された URL (Request トリガーが想定するメソッドを含む) に HTTP 要求を送信します。

トリガーの基になる JSON 定義と、このトリガーの呼び出し方法の詳細については、このトピックス、Request タイプのトリガーに関するページ、および「Azure Logic Apps で HTTP エンドポイントを使用してワークフローを呼び出すか、トリガーするか、または入れ子にする」を参照してください。

セキュリティと認証

Request トリガー (Webhook トリガーではなく) で始まる Standard ロジックアプリワークフローでは、マネージド ID を使用して、そのトリガーによって作成されたエンドポイントに送信される受信呼び出しを認証するために、Azure Functions プロビジョニングを使用できます。このプロビジョニングは「Easy Auth」とも呼ばれます。詳細については、「Easy Auth を使用した Standard ロジックアプリでのワークフローのトリガー」を参照してください。

トランスポート層セキュリティ (TLS) (以前の Secure Sockets Layer (SSL))、Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth)、Azure API Management によるロジックアプリの公開、または受信呼び出しを発信する IP アドレスの制限などの、ロジックアプリワークフローへの受信呼び出しのセキュリティ、認可、および暗号化の詳細については、アクセスとデータのセキュリティ保護に関するページの「要求ベースのトリガーへの受信呼び出しへのアクセス」を参照してください。

次の方法で共有

Azure Logic Apps のワークフローに対する受信 HTTP 呼び出しを受け取り、応答する

前提条件

Request トリガーの追加

ステートレスワークフローのスキーマの検証

トリガー出力

Response アクションを追加する

ワークフローのテスト

セキュリティと認証

次のステップ

フィードバック

その他のリソース