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

[アーティクル]
11/08/2023

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

このハウツーガイドでは、HTTP または HTTPS 経由で他のサービスやシステム上のエンドポイントに送信要求を送信できるロジックアプリワークフローを作成する方法を示します。代わりに受信 HTTPS 呼び出しを受信してそれに応答するには、組み込みの Request トリガーと Response アクションを使用します。

たとえば、Web サイトのサービスエンドポイントは、そのエンドポイントを特定のスケジュールで確認することによって監視できます。 Web サイトの停止など、そのエンドポイントで指定されたイベントが発生すると、そのイベントによってロジックアプリのワークフローがトリガーされ、そのワークフロー内のアクションが実行されます。

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

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

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

前提条件

Azure アカウントとサブスクリプション。 Azure サブスクリプションがない場合は、無料の Azure アカウントにサインアップしてください。
呼び出すターゲットエンドポイントの URL
ロジックアプリワークフローの作成方法に関する基礎知識。ロジックアプリを初めて使用する場合は、「Azure Logic Apps とは」を参照してください。
ターゲットエンドポイントの呼び出し元となるロジックアプリワークフロー。 HTTP トリガーから開始するには、空のワークフローから開始する必要があります。 HTTP アクションを使うには、任意のトリガーを使って対象のワークフローを起動します。この例では、最初のステップとして HTTP トリガーを使用します。

HTTP トリガーの追加

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

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

この例では、トリガー名を HTTP trigger に変更して、このトリガーにわかりやすい名前を付けています。また、この例では後で HTTP アクションを追加します。どちらの名前も一意である必要があります。
ターゲットエンドポイントへの呼び出しに含める HTTP トリガーパラメーターの値を指定します。トリガーでターゲットエンドポイントを確認する頻度を設定します。

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

HTTP アクションの追加

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

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

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

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

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

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

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

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

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

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

シングルテナント 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 を使用します。このアクションは次のようになります。

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"
}

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 型をサポートするとします。このアクションは次のようになります。

Screenshot that shows an HTTP request with the 'content-type' header set to 'application/x-www-form-urlencoded'

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

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

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

ロジックアプリデザイナーでは、HTTP アクション (トリガーではありません) に非同期パターン設定があります。これは既定で有効になっています。この設定では、呼び出し元は処理が終了するのを待たずに次のアクションに進むことができますが、処理が停止するまで状態のチェックは継続されます。無効にした場合、この設定は次のアクションに進む前に、呼び出し元が処理の終了を待機することを指定します。

この設定を見つけるには、次の手順を実行します。
1. HTTP アクションのタイトルバーで、省略記号 ( ... ) ボタンを選択します。これにより、アクションの設定が開きます。
2. [非同期パターン] 設定を探します。
HTTP アクションの基になる JavaScript Object Notation (JSON) 定義では、暗黙的に非同期操作パターンに従います。

非同期操作の無効化

場合によっては、特定のシナリオで 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 トリガーまたはアクションにこれらのヘッダーが含まれている場合、Logic Apps は警告やエラーを表示することなく、生成された要求メッセージからこれらのヘッダーを削除します。

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

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

コネクタのリファレンス

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

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

前提条件

HTTP トリガーの追加

HTTP アクションの追加

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

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

TLS/SSL 証明書認証

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

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

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

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

非同期操作の無効化

[非同期パターン] 設定をオフにします

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

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

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

場所ヘッダーの確認の無効化

既知の問題

省略された HTTP ヘッダー

コネクタのリファレンス

次のステップ

その他のリソース

その他のリソース

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

前提条件

HTTP トリガーの追加

HTTP アクションの追加

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

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

TLS/SSL 証明書認証

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

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

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

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

非同期操作の無効化

[非同期パターン] 設定をオフにします

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

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

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

ページ付けの対応

場所ヘッダーの確認の無効化

既知の問題

省略された HTTP ヘッダー

コネクタのリファレンス

次のステップ

その他のリソース

その他のリソース

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

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