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

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

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

Note

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

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

• オンプレミス データベース内のデータに対する HTTPS 要求を受信して応答する。

• 別のロジック アプリ ワークフローから送信された HTTPS 要求を受信して応答します。

• 外部 Webhook イベントが発生したときにワークフローの実行をトリガーする。

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

前提条件

• Azure アカウントとサブスクリプション。 サブスクリプションがない場合は、無料の Azure アカウントにサインアップできます。

• 受信 HTTPS 要求を受信するロジック アプリ ワークフロー。 Request トリガーでワークフローを開始するには、空のワークフローから開始する必要があります。 応答アクションを使用するには、ワークフローが Request トリガーで開始されている必要があります。

Request トリガーの追加

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

従量課金プラン

1. Azure portal で、従量課金ロジック アプリと空のワークフローをデザイナーで開きます。

2. デザイナーで、こちらの一般的な手順に従って、「When a HTTP request is received」という名前の組み込み要求トリガーを見つけて追加します。

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

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

   次の例は、サンプル 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 に設定するように促されます。 詳細については、コンテンツ タイプの処理に関するページを参照してください。

   

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

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

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

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

      

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

      

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

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

4. 指定したスキーマに一致する要求本文が受信呼び出しに含まれることを確認するには、次の手順に従います。

   1. スキーマで記述されているのとまったく同じフィールドを受信メッセージに強制するには、スキーマに required プロパティを追加し、必須フィールドを指定します。 addtionalProperties プロパティを追加し、値を false に設定します。

      たとえば、次のスキーマでは、受信メッセージには msg フィールドが必要で、他のフィールドは必要ないことが指定されています。

      {
         "properties": {
           "msg": {
              "type": "string"
           }
         },
         "type": "object",
         "required": ["msg"],
         "additionalProperties": false
      }
      

   2. 要求トリガーのタイトル バーにある省略記号 (...) ボタンを選択します。

   3. トリガーの設定で [スキーマの検証] をオンにし、[完了] を選択します。

      受信呼び出しの要求本文がスキーマと一致しない場合、トリガーからは HTTP 400 Bad Request エラーが返されます。

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

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

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

   

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

   

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

   この手順により、ワークフローをトリガーする要求を送信するために使用する URL が生成されます。

7. 生成された URL をコピーするには、URL の横にあるコピー アイコンを選択します。

   

   Note

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

Standard

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

2. デザイナーで、こちらの一般的な手順に従って、「When a HTTP request is received」という名前の組み込み要求トリガーを見つけて追加します。

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

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

   次の例は、サンプル 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 に設定するように促されます。 詳細については、コンテンツ タイプの処理に関するページを参照してください。

   

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

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

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

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

      

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

      

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

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

4. 指定したスキーマに一致する要求本文が受信呼び出しに含まれることを確認するには、次の手順に従います。

   1. スキーマで記述されているのとまったく同じフィールドを受信メッセージに強制するには、スキーマに required プロパティを追加し、必須フィールドを指定します。 addtionalProperties プロパティを追加し、値を false に設定します。

      たとえば、次のスキーマでは、受信メッセージには msg フィールドが必要で、他のフィールドは必要ないことが指定されています。

      {
         "properties": {
           "msg": {
              "type": "string"
           }
         },
         "type": "object",
         "required": ["msg"],
         "additionalProperties": false
      }
      

   2. デザイナーで、Request トリガーを選択します。 情報ペインが開いたら、[設定] タブを選択します。

   3. [Data Handling] を展開して、[スキーマの検証] を [オン] に設定します。

      受信呼び出しの要求本文がスキーマと一致しない場合、トリガーからは HTTP 400 Bad Request エラーが返されます。

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

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

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

   

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

   

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

   この手順により、ワークフローをトリガーする要求を送信するために使用する URL が生成されます。

7. 生成された URL をコピーするには、URL の横にあるコピー アイコンを選択します。

   

   Note

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

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

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

Note

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

トランスポート層セキュリティ (TLS) (以前の Secure Sockets Layer (SSL))、Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth)、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 はアクションを実行しません。

従量課金プラン

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

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

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

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

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

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

   

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

   

3. 応答本文用の JSON スキーマなど、アクションのプロパティをさらに追加するには、[新しいパラメーターの追加] リストから、追加するパラメーターを選択します。

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

Standard

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

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

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

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

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

   

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

   

3. 応答本文用の JSON スキーマなど、アクションのプロパティをさらに追加するには、[新しいパラメーターの追加] リストを開いて、追加するパラメーターを選択します。

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

ワークフローのテスト

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

セキュリティと認証

要求トリガー (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 のマネージドまたは Azure でホストされるコネクタ