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

[アーティクル]
04/13/2024

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

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

Note

代わりに、受信 HTTPS 呼び出しを受信して応答するワークフローを作成するには、「Azure Logic Apps で HTTPS エンドポイントを使用して呼び出したり、トリガーしたり、入れ子にしたりできるワークフローを作成する」と、組み込みの要求トリガーと応答アクションに関する記事を参照してください。

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

定期的なスケジュールでエンドポイントを調べる、つまり "ポーリング" するには、ワークフローの最初のステップとして HTTP トリガーを追加します。トリガーによるエンドポイントの調査ごとに、トリガーからそのエンドポイントに対して、呼び出しまたは要求の送信が行われます。エンドポイントの応答によって、ワークフローが実行されるかどうかが決定します。エンドポイントの応答からの任意のコンテンツが、トリガーによってワークフローのアクションに渡されます。
ワークフロー内のどこか他の場所からエンドポイントを呼び出すには、HTTP アクションを追加します。エンドポイントの応答によって、ワークフローの以降のアクションの実行方法が決まります。

前提条件

Azure アカウントとサブスクリプション。 Azure サブスクリプションがない場合は、無料の Azure アカウントにサインアップしてください。
呼び出す宛先エンドポイントの URL
宛先エンドポイントの呼び出し元となるロジックアプリワークフロー。 HTTP トリガーから開始するには、空のワークフローが必要です。 HTTP アクションを使うには、任意のトリガーを使って対象のワークフローを起動します。この例では、最初のステップとして HTTP トリガーを使用します。

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

トリガーとアクションのパラメーターに関する技術的な情報については、以下のセクションを参照してください。

HTTP トリガーの追加

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

Standard
従量課金プラン

Azure portal で、Standard ロジックアプリリソースと空のワークフローをデザイナーで開きます。
HTTP という名前の組み込みトリガーをワークフローに追加するには、次の一般的な手順に従います。

この例では、トリガー名を HTTP trigger - Call endpoint URL に変更します。これにより、トリガーの名前がわかりやすいものになります。また、この例では後で HTTP アクションを追加します。ワークフロー内の操作名は一意である必要があります。
宛先エンドポイントへの呼び出しに含める HTTP トリガーパラメーターの値を指定します。トリガーで宛先エンドポイントを確認する頻度を設定します。

[なし] 以外の認証の種類を選択した場合、認証設定は、選択に基づいて変化します。 HTTP に使用できる認証の種類の詳細については、以下のトピックを参照してください。
- 送信呼び出しに認証を追加する
- マネージド ID を利用してリソースへのアクセスを認証する
その他の使用可能なパラメーターを追加するには、[高度なパラメーター] リストを開き、必要なパラメーターを選択します。
トリガーの起動時に実行するその他のすべてのアクションを追加します。
完了したら、ワークフローを保存します。デザイナーのツールバーで、 [保存] を選択します。

HTTP アクションの追加

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

Standard
従量課金プラン

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

この例では、前のセクションで追加した HTTP トリガーを最初の手順として使用します。
HTTP という名前の組み込みアクションをワークフローに追加するには、次の一般的な手順に従います。

この例では、アクション名を HTTP action - Call endpoint URL に変更します。これにより、このステップの名前がわかりやすいものになります。また、ワークフロー内の操作名は一意である必要があります。
宛先エンドポイントへの呼び出しに含める HTTP アクションパラメーターの値を指定します。

[なし] 以外の認証の種類を選択した場合、認証設定は、選択に基づいて変化します。 HTTP に使用できる認証の種類の詳細については、以下のトピックを参照してください。
- 送信呼び出しに認証を追加する
- マネージド ID を利用してリソースへのアクセスを認証する
その他の使用可能なパラメーターを追加するには、[高度なパラメーター] リストを開き、必要なパラメーターを選択します。
完了したら、ワークフローを保存します。デザイナーのツールバーで、 [保存] を選択します。

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

ここでは、以下の情報を返す HTTP トリガーまたはアクションからの出力の詳細情報を示します。

プロパティ	タイプ	説明
`headers`	JSON オブジェクト	要求のヘッダー
`body`	JSON オブジェクト	要求の本文の内容を含むオブジェクト
`status code`	Integer	要求の状態コード

状態コード	説明
200	OK
202	Accepted
400	Bad request
401	権限がありません
403	許可されていません
404	Not Found
500	内部サーバーエラー。不明なエラーが発生しました。

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

トランスポート層セキュリティ (TLS) (以前の Secure Sockets Layer (SSL))、自己署名証明書、Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) などの、ワークフローからの送信呼び出しの暗号化、セキュリティ、認可については、アクセスとデータのセキュリティ保護 - 他のサービスやシステムへの送信呼び出しへのアクセスに関する記事を参照してください。

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

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

TLS/SSL 証明書: アプリ設定を追加し、WEBSITE_LOAD_ROOT_CERTIFICATES、その値をTLS/SSL 証明書の拇印に指定します。
クライアントの証明書、または「Certificate」資格情報の種類を使用した Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth): アプリの設定である WEBSITE_LOAD_USER_PROFILE を追加し、値を 1 に設定します。

TLS/SSL 証明書認証

ロジックアプリリソースのアプリ設定で、アプリ設定の追加または更新、WEBSITE_LOAD_ROOT_CERTIFICATES を行います。
設定値には、信頼できるルート証明書として TLS/SSL 証明書の拇印を指定します。

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

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

ロジックアプリプロジェクトの local.settings.json ファイルを開きます。
Values JSON オブジェクトで、WEBSITE_LOAD_ROOT_CERTIFICATES 設定を追加または更新します。
```
{
   "IsEncrypted": false,
   "Values": {
      <...>
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS/SSL-certificate>",
      <...>
   }
}
```
Note

拇印を見つけるには、次の手順に従います。
1. ロジックアプリのリソースメニューで、[設定] の下で [TLS/SSL の設定]>[秘密キー証明書 (.pfx)] か [公開キー証明書 (.cer)] を選びます。
2. 使用する証明書を見つけ、拇印をコピーします。
詳細については、「拇印の検索 - Azure App Service」を確認してください。

詳細については、次のドキュメントを確認してください。

クライアント証明書、または「Certificate」資格情報の種類の認証を使用した Microsoft Entra ID OAuth

ロジックアプリリソースのアプリ設定で、アプリ設定の追加または更新、WEBSITE_LOAD_USER_PROFILE を行います。
設定値として 1 と入力します。

"WEBSITE_LOAD_USER_PROFILE": "1"

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

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

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

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

詳細については、次のドキュメントを確認してください。

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

HTTP 要求に multipart/form-data 型を含むコンテンツを処理する目的で、このフォーマットを使用することで、$content-type 属性と $multipart 属性を含む JSON オブジェクトを HTTP 要求の本文に追加できます。

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

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

Standard ワークフロー

従量課金ワークフロー

基礎的なワークフロー定義で 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"
}

Content with application/x-www-form-urlencoded type

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

たとえば、HTTP POST 要求を Web サイトに送信するロジックアプリがあり、application/x-www-form-urlencoded 型をサポートするとします。このアクションは次のようになります。

Standard ワークフロー

従量課金ワークフロー

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

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

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

HTTP アクションの基になる JavaScript Object Notation (JSON) 定義では、暗黙的に非同期操作パターンに従います。
HTTP アクション (トリガーではありません) に [非同期パターン] 設定があります。これは既定で有効になっています。この設定では、呼び出し元は処理が終了するのを待たずに次のアクションに進むことができますが、処理が停止するまで状態のチェックは継続されます。無効にした場合、この設定は次のアクションに進む前に、呼び出し元が処理の終了を待機することを指定します。

[非同期パターン] 設定を見つけるには、Standard ワークフローと従量課金ワークフローのどちらを使用しているかに基づいて、次の手順に従います。

Standard ワークフロー*
1. ワークフローデザイナーで、HTTP アクションを選択します。情報ペインが開いたら、[設定] を選択します。
2. [ネットワーク] で [非同期パターン] 設定を探します。
従量課金ワークフロー
1. ワークフローデザイナーの HTTP アクションのタイトルバーで、省略記号 (...) ボタンを選択します。これにより、アクションの設定が開きます。
2. [非同期パターン] 設定を探します。

非同期操作の無効化

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

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

ワークフローデザイナーで HTTP アクションを選択し、開いた情報ウィンドウで [設定] 選択します。
[ネットワーク] で [非同期パターン] 設定を探します。この設定を [オフ] にします (有効になっている場合)。

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

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

長時間実行されるタスクで HTTP タイムアウトを回避

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

アクションが継続的にポーリングしたり、要求の状態を確認したりしないように、HTTP アクションの非同期操作パターンを無効にします。アクションは代わりに、要求が処理を終了した後、受信側が状態と結果を応答するまで待機します。
HTTP アクションを 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 ヘッダー

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

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

Azure Logic Apps では、これらのヘッダーが含まれる HTTP トリガーまたはアクションを使用するロジックアプリの保存は妨げられませんが、これらのヘッダーは無視されます。

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

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