Azure Logic Apps のワークフローから外部 HTTP または HTTPS エンドポイントを呼び出す

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

一部のシナリオでは、HTTP または HTTPS 経由で他のサービスまたはシステム上のエンドポイントに送信要求を送信するロジック アプリ ワークフローを作成することが必要になる場合があります。 たとえば、特定のスケジュールでエンドポイントを確認して、Web サイトのサービス エンドポイントを監視するとします。 Web サイトがダウンするなど、そのエンドポイントで特定のイベントが発生すると、そのイベントによってワークフローがトリガーされ、そのワークフローでアクションが実行されます。

このガイドでは、HTTP トリガーと HTTP アクションを使用して、ワークフローが他のサービスやシステムに送信呼び出しを送信できるようにする方法を示します。次に例を示します。

• 定期的なスケジュールでエンドポイントを確認またはポーリングするには、ワークフローの最初のステップとして HTTP という名前の組み込みトリガーを追加します。 トリガーがエンドポイントを確認するたびに、トリガーはエンドポイントを呼び出すか、 エンドポイントに要求 を送信します。 エンドポイントの応答によって、ワークフローが実行されるかどうかが決まります。 トリガーは、エンドポイントの応答からワークフロー内のアクションにコンテンツを渡します。

• ワークフロー内の他の場所からエンドポイントを呼び出すには、HTTP という名前の組み込みアクションを追加します。 エンドポイントの応答によって、ワークフローの残りのアクションの実行方法が決まります。

[前提条件]

• Azure アカウントとサブスクリプション。 Azure サブスクリプションがない場合は、無料の Azure アカウントにサインアップしてください。

• 呼び出す宛先エンドポイントの URL。

• 外部エンドポイントを呼び出すワークフローを含むロジック アプリ リソース。

  HTTP トリガーを使用してワークフローを開始するには、空のワークフローが必要です。 HTTP アクションを使用するために、ワークフローはシナリオに最も適したトリガーから開始できます。 この記事のワークフロー例では 、HTTP トリガーを使用します。

  ロジック アプリのリソースとワークフローがない場合は、必要なロジック アプリの手順に従って、今すぐ作成します。

  • 従量課金ロジック アプリ ワークフローを作成する
  • 標準ロジック アプリ ワークフローの例を作成する

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

トリガーとアクションのパラメーターに関する技術情報については、スキーマ リファレンス ガイドの次のセクションを参照してください。

• HTTP トリガー パラメーター
• HTTP アクション パラメーター

HTTP トリガーを追加する

この組み込みトリガーは、エンドポイントの指定された URL に対して HTTP 呼び出しを行い、応答を返します。

HTTP アクションを追加する

この組み込みアクションは、エンドポイントの指定された URL に HTTPS または HTTP 呼び出しを送信し、応答で返します。

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

HTTP トリガーまたはアクションは、次の情報を出力します。

送信呼び出しの URL セキュリティ

トランスポート層セキュリティ (TLS)、自己署名証明書、Microsoft Entra ID オープン認証など、ワークフローからの送信呼び出しの暗号化、セキュリティ、承認については、他のサービスやシステムへの発信呼び出しのアクセスを参照してください。

シングルテナント環境の認証

シングルテナントの Azure Logic Apps に Standard ロジック アプリ リソースがあり、次のいずれかの認証の種類で HTTP 操作を使用する場合は、対応する認証の種類に対する追加のセットアップ手順を必ず完了してください。 そうでない場合、呼び出しは失敗します。

• TLS 証明書: アプリ設定 WEBSITE_LOAD_ROOT_CERTIFICATES追加し、TLS 証明書の拇印に値を設定します。

• クライアント証明書または Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) と 証明書 資格情報の種類: アプリ設定を WEBSITE_LOAD_USER_PROFILE追加し、値を 1 に設定します。

TLS 証明書認証

1. ロジック アプリ リソースのアプリ設定で、 WEBSITE_LOAD_ROOT_CERTIFICATESというアプリ設定を追加または更新します。 具体的な手順については、「 アプリ設定の管理 - local.settings.json」を参照してください。

2. 設定値には、信頼するルート証明書として TLS 証明書の拇印を指定します。

   "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS-certificate>"

たとえば、Visual Studio Code で作業している場合は、次の手順に従います。

1. ロジック アプリ プロジェクトの local.settings.jsonファイルを 開きます。

2. Values JSON オブジェクトで、WEBSITE_LOAD_ROOT_CERTIFICATES設定を追加または更新します。

   {
      "IsEncrypted": false,
      "Values": {
         <...>
         "AzureWebJobsStorage": "UseDevelopmentStorage=true",
         "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS-certificate>",
         <...>
      }
   }
   

詳細については、「 アプリ設定の管理 - local.settings.json」を参照してください。

クライアント証明書、または Microsoft Entra ID OAuth による証明書資格情報認証

1. ロジック アプリ リソースのアプリ設定で、 WEBSITE_LOAD_USER_PROFILEというアプリ設定を追加または更新します。 具体的な手順については、「アプリ設定の管理 - local.settings.json」を参照してください。

2. 設定値には、 1を指定します。

   "WEBSITE_LOAD_USER_PROFILE": "1"

たとえば、Visual Studio Code で作業している場合は、次の手順に従います。

1. ロジック アプリ プロジェクトの local.settings.jsonファイルを 開きます。

2. Values JSON オブジェクトで、WEBSITE_LOAD_USER_PROFILE設定を追加または更新します。

   {
      "IsEncrypted": false,
      "Values": {
         <...>
         "AzureWebJobsStorage": "UseDevelopmentStorage=true",
         "WEBSITE_LOAD_USER_PROFILE": "1",
         <...>
      }
   }
   

Azure portal で作業している場合は、ロジック アプリを開きます。 サイドバー メニューの [設定] で、[ 環境変数] を選択します。 [ アプリの設定] で、設定を追加または編集します。

マルチパート/フォームデータタイプのコンテンツ

HTTP 要求で multipart/form-data の種類を持つコンテンツを処理するには、この形式を使用して、HTTP 要求の本文に $content-type 属性と $multipart 属性を含む JSON オブジェクトを追加します。

"body": {
   "$content-type": "multipart/form-data",
   "$multipart": [
      {
         "body": "<output-from-trigger-or-previous-action>",
         "headers": {
            "Content-Disposition": "form-data; name=file; filename=<file-name>"
         }
      }
   ]
}

たとえば、そのサイトの API を使用して Excel ファイルの HTTP POST 要求を Web サイトに送信するワークフローがあり、 multipart/form-data の種類をサポートしているとします。 次の例は、このアクションがどのように表示されるかを示しています。

基になるワークフロー定義の HTTP アクションの JSON 定義を示すのと同じ例を次に示します。

"HTTP_action": {
   "inputs": {
      "body": {
         "$content-type": "multipart/form-data",
         "$multipart": [
            {
               "body": "@trigger()",
               "headers": {
                  "Content-Disposition": "form-data; name=file; filename=myExcelFile.xlsx"
               }
            }
         ]
      },
      "method": "POST",
      "uri": "https://finance.contoso.com"
   },
   "runAfter": {},
   "type": "Http"
}

application/x-www-form-urlencoded 型のコンテンツ

HTTP要求の本文にフォームURLエンコードされたデータを提供するには、データにapplication/x-www-form-urlencodedコンテンツタイプがあることを指定する必要がある。 HTTP トリガーまたはアクションで、 content-type ヘッダーを追加します。 ヘッダー値を application/x-www-form-urlencoded に設定します。

たとえば、web サイトに HTTP POST 要求を送信するロジック アプリがあり、 application/x-www-form-urlencoded の種類をサポートしているとします。 このアクションの外観を次に示します。

HTTP リクエストと content-type ヘッダーが application/x-www-form-urlencoded に設定されたワークフローを示すスクリーンショット。

非同期の要求/応答の動作

マルチテナントとシングルテナントの両方の Azure Logic Apps の ステートフル ワークフローの場合、すべての HTTP ベースのアクションは、既定の動作として標準 の非同期操作パターン に従います。 このパターンは、HTTP アクションがエンドポイント、サービス、システム、または API に要求を呼び出すか送信した後、受信側がすぐに 202 ACCEPTED 応答を返すように指定します。 このコードは、受信側が要求を受け入れたが、処理が完了していないことを確認します。 応答には、URI と更新 ID を指定する ___location ヘッダーを含めることができます。このヘッダーは、受信者が処理を停止し、 200 OK 成功応答またはその他の 202 以外の応答を返すまで、呼び出し元が非同期要求の状態をポーリングまたはチェックするために使用できます。 ただし、呼び出し元は要求の処理が完了するまで待機する必要はなく、次のアクションの実行を継続できます。 詳細については、「 同期メッセージングと非同期メッセージング」を参照してください。

シングルテナント Azure Logic Apps の ステートレス ワークフローの場合、HTTP ベースのアクションでは非同期操作パターンは使用されません。 代わりに、同期的にのみ実行され、 202 ACCEPTED 応答 as-is返され、ワークフロー実行の次の手順に進みます。 応答に ___location ヘッダーが含まれている場合、ステートレス ワークフローは、指定された URI をポーリングして状態を確認しません。 標準の 非同期操作パターンに従うには、代わりにステートフル ワークフローを使用します。

• HTTP アクションの基になる JSON 定義は、非同期操作パターンに暗黙的に従います。

• HTTP アクションはトリガーではなく、 非同期パターン 設定を持ち、既定で有効になっています。 この設定は、呼び出し元が処理の完了を待機せず、次のアクションに進むことができるが、処理が停止するまで状態のチェックを続行することを指定します。 無効にした場合、この設定は次のアクションに進む前に、呼び出し元が処理の終了を待機することを指定します。

  非同期パターン設定を見つけるには:

  1. ワークフロー デザイナーで、 HTTP アクションを選択します。
  2. 情報ペインが開いたら、[設定] を選択します。
  3. [ ネットワーク] で、[ 非同期パターン ] 設定を見つけます。

非同期操作を無効にする

場合によっては、特定のシナリオで HTTP アクションの非同期動作を無効にしたい場合があります。たとえば、次のような場合です。

• 長時間実行されるタスクで HTTP タイムアウトを回避
• 場所ヘッダーの確認の無効化

非同期パターン設定をオフにする

1. ワークフロー デザイナーで HTTP アクションを選択し、開いた情報ウィンドウで [設定] を選択します。

2. [ ネットワーク] で、[ 非同期パターン ] 設定を見つけます。 有効になっている場合は、この設定を [オフ] に設定します。

アクションの JSON 定義で非同期パターンを無効にする

HTTP アクションの基になる JSON 定義で、 アクションの定義に DisableAsyncPattern 操作オプションを追加 して、代わりにアクションが同期操作パターンに従います。 詳細については、「 同期操作パターンでアクションを実行する」も参照してください。

実行時間の長いタスクの HTTP タイムアウトを回避する

HTTP 要求には タイムアウト制限があります。 この制限によりタイムアウトする実行時間の長い HTTP アクションがある場合は、次のオプションがあります。

• アクションが要求の状態を継続的にポーリングまたはチェックしないように、HTTP アクションの非同期操作パターンを無効にします。 代わりに、アクションは、要求の処理が完了した後、受信者が状態と結果で応答するのを待機します。

• HTTP アクションを HTTP Webhook アクションに置き換えます。HTTP Webhook アクションは、要求の処理が完了した後、受信側が状態と結果で応答するのを待機します。

Retry-After ヘッダーを使用して再試行間隔を設定する

再試行間隔の秒数を指定するには、http アクション応答に Retry-After ヘッダーを追加します。 たとえば、宛先エンドポイントが 429 - Too many requests 状態コードを返す場合は、再試行間隔を長く指定できます。 Retry-After ヘッダーは、202 - Accepted状態コードでも機能します。

Retry-Afterを含む HTTP アクション応答を示す同じ例を次に示します。

{
    "statusCode": 429,
    "headers": {
        "Retry-After": "300"
    }
}

ページネーションサポート

場合によっては、変換先サービスは一度に 1 ページずつ結果を返すことで応答します。 応答で nextLink プロパティまたは @odata.nextLink プロパティを持つ次のページが指定されている場合は、HTTP アクションで改ページ設定を有効にすることができます。 この設定により、 HTTP アクションはこれらのリンクに自動的に従い、次のページを取得します。 ただし、応答で他のタグを含む次のページが指定されている場合は、ワークフローにループを追加する必要があります。 このループをそのタグに従わせ、タグが null になるまで各ページを手動で取得します。

場所ヘッダーのチェックを無効にする

エンドポイント、サービス、システム、または API によっては、___location ヘッダーのない202 ACCEPTED応答が返される場合があります。 ___location ヘッダーが存在しないときに HTTP アクションが要求の状態を継続的にチェックしないようにするには、次のオプションを使用できます。

• アクションが要求の状態を継続的にポーリングまたはチェックしないように、HTTP アクションの非同期操作パターンを無効にします。 代わりに、アクションは、要求の処理が完了した後、受信者が状態と結果で応答するのを待機します。

• HTTP アクションを HTTP Webhook アクションに置き換えます。HTTP Webhook アクションは、要求の処理が完了した後、受信側が状態と結果で応答するのを待機します。

既知の問題

省略された HTTP ヘッダー

HTTP トリガーまたはアクションにこれらのヘッダーが含まれている場合、Azure Logic Apps は、警告やエラーを表示せずに、生成された要求メッセージからこれらのヘッダーを削除します。

• Accept-* ヘッダーのうち、Accept-version を除く
• Allow
• Content-* ヘッダー (Content-Disposition、Content-Encoding、および Content-Type を除く)。これらは、POST 操作と PUT 操作を使用するときには受け入れられます。 ただし、 GET 操作を使用すると、Azure Logic Apps によってこれらのヘッダーが削除されます。
• Cookie ヘッダーですが、Azure Logic Apps では、 Cookie プロパティを使用して指定した値が優先されます。
• Expires
• Host
• Last-Modified
• Origin
• Set-Cookie
• Transfer-Encoding

Azure Logic Apps では、これらのヘッダーで HTTP トリガーまたはアクションを使用するロジック アプリを保存できなくなりますが、Azure Logic Apps はこれらのヘッダーを無視します。

応答コンテンツが想定されるコンテンツ タイプと一致しない

HTTP アクションは、http アクションが Content-Type ヘッダーを application/json に設定してバックエンド API を呼び出す場合に BadRequest エラーをスローしますが、バックエンドからの応答には実際には JSON 形式のコンテンツが含まれず、内部 JSON 形式の検証は失敗します。

関連コンテンツ

• Azure Logic Apps コネクタのマネージド コネクタ
• Azure Logic Apps の組み込みコネクタ