Azure Logic Apps で HTTPS エンドポイントを使用して呼び出したり、トリガーしたり、入れ子にしたりできるワークフローを作成する
適用対象: Azure Logic Apps (従量課金プラン + Standard)
シナリオによっては、他のサービスやワークフローから受信要求を受信できるロジック アプリ ワークフロー、または URL を使って呼び出すことができるワークフローを作成することが、必要になる場合があります。 このタスクでは、次の要求ベースのトリガーの種類のいずれを使うときにでも、ワークフローでネイティブ同期 HTTPS エンドポイントを公開できます。
- Request
- HTTP Webhook
- ApiConnectionWebhook 型であり、受信 HTTPS 要求を受信できるマネージド コネクタ トリガー
このガイドでは、要求トリガーを追加してワークフロー用の呼び出し可能なエンドポイントを作成する方法と、別のワークフローからそのエンドポイントを呼び出す方法について説明します。 すべての原則は、受信要求を受信できる他の要求ベースのトリガーの種類にも同じように適用されます。
前提条件
Azure アカウントとサブスクリプション。 サブスクリプションをお持ちでない場合には、無料の Azure アカウントにサインアップしてください。
要求ベースのトリガーを使って呼び出し可能なエンドポイントを作成するロジック アプリ ワークフロー。 空のワークフローから、または現在のトリガーを置き換えることができる既存のワークフローから、始めることができます。 この例では、空のワークフローから始めます。
作成した呼び出し可能なエンドポイントの URL をテストするには、Postman などのツールまたはアプリが必要です。
呼び出し可能なエンドポイントを作成する
お使いのロジック アプリ ワークフローが Standard または従量課金のどちらであるかに基づいて、対応する手順に従ってください。
Azure portal で、Standard ロジック アプリ リソースと空のワークフローをデザイナーで開きます。
必要に応じて、 [要求本文の JSON スキーマ] ボックスで、トリガーで受信することが予測されるペイロードまたはデータが記述された JSON スキーマを入力できます。
デザイナーは、このスキーマを使用して、トリガー出力を表すトークンを生成します。 その後は、これらの出力をロジック アプリのワークフロー全体で容易に参照できます。 詳細については、JSON スキーマから生成されるトークンに関するセクションを参照してください。
この例では、次のスキーマを入力します。
{ "type": "object", "properties": { "address": { "type": "object", "properties": { "streetNumber": { "type": "string" }, "streetName": { "type": "string" }, "town": { "type": "string" }, "postalCode": { "type": "string" } } } } }
または、サンプル ペイロードを指定することによって JSON スキーマを生成できます。
[要求] トリガーで、 [サンプルのペイロードを使用してスキーマを生成する] を選択します。
[サンプルの JSON ペイロードを入力するか、貼り付けます] ボックスで、サンプル ペイロードを入力します。たとえば、次のようにします。
{ "address": { "streetNumber": "00000", "streetName": "AnyStreet", "town": "AnyTown", "postalCode": "11111-1111" } }準備ができたら、 [完了] を選択します。
[要求本文の JSON スキーマ] ボックスに、生成されたスキーマが表示されます。
ワークフローを保存します。
[HTTP POST の URL] ボックスに、他のサービスがロジック アプリ ワークフローの呼び出しやトリガーに使用できる生成されたコールバック URL が表示されます。 この URL には、認証に使用される Shared Access Signature (SAS) キーを指定するクエリ パラメーターが含まれています。
コールバック URL をコピーするには、次のオプションがあります。
[HTTP POST の URL] ボックスの右にある [URL のコピー] (ファイル コピー アイコン) を選びます。
ワークフローの [概要] ページからコールバック URL をコピーします。
ワークフローのメニューで、[概要] を選択します。
[概要] ページの [ワークフロー URL] で、ポインターを URL の上に移動して、[クリップボードにコピー] を選びます。
要求トリガーのコールバック URL をテストするには、Postman などのツールまたはアプリを使用し、要求トリガーが期待するメソッドを使用して要求を送信します。
この例では、
POSTメソッドを使用します。POST https://{logic-app-name}.azurewebsites.net:443/api/{workflow-name}/triggers/{trigger-name}/invoke?api-version=2022-05-01&sp=%2Ftriggers%2F{trigger-name}%2Frun&sv=1.0&sig={shared-access-signature}
待機する要求メソッドの選択
既定では、要求トリガーは POST 要求を待機します。 呼び出し元が使用する必要のある別のメソッドを指定できますが、指定できるメソッドは 1 つだけです。
要求トリガーで、[高度なパラメーター] の一覧を開き、[メソッド] を選びます。これにより、このプロパティがトリガーに追加されます。
[メソッド] 一覧から、代わりにトリガーで待機する別のメソッドを選択します。 または、カスタム メソッドを指定できます。
たとえば、後でエンドポイントの URL をテストできるように [GET] メソッドを選択します。
エンドポイント URL を使用してパラメーターを渡す
エンドポイントの URL 経由でパラメーター値を受け取るとき、次の選択肢が与えられます。
GET パラメーター経由で値を受け取るか、URL パラメーター経由で値を受け取ります。
これらの値は、エンドポイントの URL で名前と値のペアとして渡されます。 このオプションでは、要求トリガーで GET メソッドを使用する必要があります。 後続のアクションでは、式で
triggerOutputs()関数を使用することで、パラメーター値をトリガー出力として取得できます。要求トリガーのパラメーターに対して相対パス経由で値を受け取ります。
これらの値は、エンドポイントの URL で相対パスから渡されます。 また、明示的に、トリガーで待機するメソッドを選択する必要があります。 後続のアクションでは、これらの出力を直接参照することで、パラメーター値をトリガー出力として取得できます。
GET パラメーター経由で値を受け取る
要求トリガーで、[高度なパラメーター] の一覧を開き、[メソッド] プロパティをトリガーに追加して、GET メソッドを選びます。
詳細については、「待機する要求メソッドの選択」を参照してください。
デザイナーで、 次の一般的な手順に従って、パラメーター値を使用する場所にアクションを追加します。
この例では、Response という名前のアクションを選択します。
パラメーター値を取得する
triggerOutputs()式を作成するには、次の手順を実行します。応答アクションで、[本体] プロパティ内を選んで、動的なコンテンツ (稲妻アイコン) と式エディター (数式アイコン) のオプションを表示します。 数式アイコンを選んで式エディターを開きます。
式ボックスに次の式を入力し、
parameter-nameを自分のパラメーター名に置き換えて、[OK] を選びます。triggerOutputs()['queries']['parameter-name']
Body プロパティでは、式が
triggerOutputs()トークンに解決されます。
ワークフローを保存し、デザイナーから離れてデザイナーに戻ると、トークンには指定したパラメーター名が表示されます。次はその例です。
コード ビューでは、Body プロパティが [応答] アクションの定義に次のように表示されます。
"body": "@{triggerOutputs()['queries']['parameter-name']}",たとえば、
postalCodeという名前のパラメーターに値を渡すとします。 Body プロパティでは、文字列、Postal Code:と末尾のスペース、それに続く対応する式が指定されます。
呼び出し可能なエンドポイントをテストする
要求トリガーからワークフロー URL をコピーし、別のブラウザー ウィンドウにその URL を貼り付けます。 URL で、パラメーターの名前と値を次の形式で URL に追加して、Enter キーを押します。
...invoke/{parameter-name}/{parameter-value}?api-version=2022-05-01...次に例を示します。
https://mystandardlogicapp.azurewebsites.net/api/Stateful-Workflow/triggers/When_a_HTTP_request_is_received/invoke/address/12345?api-version=2022-05-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig={shared-access-signature}ブラウザーから応答が返され、
Postal Code: 123456というテキストが表示されます。
Note
ハッシュまたはシャープ記号 ( # ) を URI に含める場合、エンコードされたバージョン %25%23 を代わりに使用します。
相対パス経由で値を受け取る
要求トリガーで、[高度なパラメーター] の一覧を開いて [相対パス] を選びます。これにより、このプロパティがトリガーに追加されます。
[相対パス] プロパティで、URL で受け入れるようにする JSON スキーマ内のパラメーターの相対パス (
/address/{postalCode}など) を指定します。
要求トリガーで、こちらの一般的な手順に従って、パラメーターの値を使うアクションを追加します。
この例では、 [応答] アクションを追加します。
応答アクションの [本文] プロパティで、トリガーの相対パスで指定したパラメーターを表すトークンを含めます。
たとえば、応答アクションで
Postal Code: {postalCode}を返すようにするとします。[本文] プロパティで、
Postal Code:を末尾にスペースを付けて入力します。 動的コンテンツの一覧が開いたままでいるように、編集ボックスの中にカーソルを置いたままにします。動的なコンテンツの一覧の "HTTP 要求を受信したとき" セクションで、[Path Parameters postalCode] (パス パラメーター postalCode) トリガー出力を選びます。
[本文] プロパティに、選択されたパラメーターが含まれています。
ワークフローを保存します。
要求トリガーでコールバック URL が更新され、たとえば次のように、相対パスが含まれます。
https://mystandardlogicapp.azurewebsites.net/api/Stateful-Workflow/triggers/When_a_HTTP_request_is_received/invoke/address/%7BpostalCode%7D?api-version=2022-05-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig={shared-access-signature}呼び出し可能なエンドポイントをテストするには、要求トリガーから更新後のコールバック URL をコピーし、その URL を別のブラウザー ウィンドウに貼り付け、URL の
%7BpostalCode%7Dは123456に変更し、Enter キーを押します。ブラウザーから応答が返され、
Postal Code: 123456というテキストが表示されます。
Note
ハッシュまたはシャープ記号 ( # ) を URI に含める場合、エンコードされたバージョン %25%23 を代わりに使用します。
エンドポイント URL を使用してワークフローを呼び出す
エンドポイントを作成したら、そのエンドポイントの完全な URL に HTTPS 要求を送信して、ワークフローをトリガーできます。 Azure Logic Apps ワークフローには、直接アクセス エンドポイントのサポートが組み込まれています。
スキーマから生成されるトークン
要求トリガーで JSON スキーマを指定すると、ワークフロー デザイナーでは、そのスキーマ内のプロパティ用のトークンが生成されます。 その後、これらのトークンを使い、ワークフローを通じてデータを渡すことができます。
たとえば、"suite" のようなプロパティを JSON スキーマにさらに追加すると、これらのプロパティのトークンをワークフローの後の手順で使用できます。 完全な JSON スキーマを次に示します。
{
"type": "object",
"properties": {
"address": {
"type": "object",
"properties": {
"streetNumber": {
"type": "string"
},
"streetName": {
"type": "string"
},
"suite": {
"type": "string"
},
"town": {
"type": "string"
},
"postalCode": {
"type": "string"
}
}
}
}
}
他のワークフローを呼び出す
要求を受信できる他のワークフローを、現在のワークフロー内に入れ子にして、呼び出すことができます。 これらのワークフローを呼び出すには、次の手順に従います:
デザイナーで、こちらの一般的な手順に従って、"このワークフロー アプリ内でワークフローを呼び出す" という名前のワークフロー操作アクションを追加します。
[ワークフロー名] の一覧に、選べるワークフローが表示されます。
[ワークフロー名] の一覧で、呼び出すワークフローを選びます。次に例を示します。
受信要求のコンテンツを参照する
受信要求のコンテンツの種類が application/json である場合は、受信要求内のプロパティを参照できます。 そうでない場合、このコンテンツは、他の API に渡すことができる 1 つのバイナリ ユニットとして扱われます。 このコンテンツをロジック アプリのワークフローの内部で参照するには、まず、そのコンテンツを変換する必要があります。
たとえば、application/xml の種類を持つコンテンツを渡す場合は、@xpath() 式を使用して XPath 抽出を実行するか、または @json() 式を使用して XML を JSON に変換することができます。 詳細については、サポートされているコンテンツの種類を参照してください。
受信要求から出力を取得するには、@triggerOutputs 式を使用できます。 たとえば、次の例のような出力があるとします。
{
"headers": {
"content-type" : "application/json"
},
"body": {
"myProperty" : "property value"
}
}
明確に body プロパティにアクセスするには、@triggerBody() 式をショートカットとして使用できます。
要求に応答する
ワークフローをトリガーする特定の要求に応答するため、呼び出し元にコンテンツを返したい場合があります。 応答の状態コード、ヘッダー、および本文を構築するには、応答アクションを使用します。 このアクションは、ワークフローの最後のみでなく、ワークフローの任意の場所で使用できます。 ワークフローに応答アクションが含まれていない場合、エンドポイントは 202 Accepted 状態で "直ちに" 応答します。
元の呼び出し元が応答を正常に取得するには、トリガーされたワークフローが入れ子にされたワークフローとして呼び出されているのでない限り、応答に必要なすべての手順が要求タイムアウト制限内に完了する必要があります。 この制限内に応答が返されない場合、受信要求はタイムアウトし、408 Client timeout 応答を受信します。
入れ子にされたワークフローの場合は、必要な時間の長さに関係なく、親ワークフローはすべての手順が完了するまで応答を待ち続けます。
応答を作成する
応答本文には、複数のヘッダーと任意の種類のコンテンツを含めることができます。 たとえば、次の応答のヘッダーでは、このトピックで要求トリガーについて先に説明した JSON スキーマに基づいて、この応答のコンテンツ タイプが application/json であり、本体に town と postalCode プロパティの値が含まれることが指定されています。
応答には、次のプロパティがあります。
| プロパティ (表示) | プロパティ (JSON) | 説明 |
|---|---|---|
| 状態コード | statusCode |
受信要求への応答で使用する HTTPS 状態コード。 2xx、4xx、または 5xx で始まる任意の有効な状態コードを使用できます。 ただし、3xx 状態コードは許可されません。 |
| ヘッダー | headers |
応答に含める 1 つ以上のヘッダー |
| 本文 | body |
文字列、JSON オブジェクト、場合によっては前のステップから参照されるバイナリ コンテンツから成る本文オブジェクト |
応答アクションの JSON 定義とワークフローの完全な JSON 定義を見るには、デザイナー ビューからコード ビューに変更します。
"Response": {
"type": "Response",
"kind": "http",
"inputs": {
"body": {
"postalCode": "@triggerBody()?['address']?['postalCode']",
"town": "@triggerBody()?['address']?['town']"
},
"headers": {
"content-type": "application/json"
},
"statusCode": 200
},
"runAfter": {}
}
Q & A
Q: 受信呼び出しの URL セキュリティはどうなっていますか?
A: Azure では、Shared Access Signature (SAS) を使用してロジック アプリのコールバック URL を安全に生成します。 この署名はクエリ パラメーターとして渡され、ワークフローを実行する前に検証される必要があります。 Azure では、ロジック アプリごとの秘密キー、トリガー名、および実行される操作の一意の組み合わせを使用して署名が生成されます。 そのため、ロジック アプリの秘密キーにアクセスできなければ、有効な署名を生成できません。
重要
運用環境とセキュリティの厳しいシステムでは、次の理由により、ブラウザーから直接ワークフローを呼び出さないことを強くお勧めします。
- 共有アクセス キーが URL に表示されます。
- Azure Logic Apps の顧客にまたがる共有ドメインのために、セキュリティ コンテンツ ポリシーを管理できません。
トランスポート層セキュリティ (TLS) (以前の Secure Sockets Layer (SSL))、Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth)、Azure API Management でのロジック アプリ ワークフローの公開、受信呼び出しを開始する IP アドレスの制限など、ワークフローへの受信呼び出しのセキュリティ、認可、暗号化について詳しくは、アクセスとデータのセキュリティ保護に関するページの「要求ベースのトリガーへの受信呼び出しへのアクセス」をご覧ください。
Q:呼び出し可能なエンドポイントをさらに構成することは可能でしょうか。
A: はい。HTTPS エンドポイントは、Azure API Management を通してより高度な構成をサポートしています。 このサービスでは、次のような、ロジック アプリを含むすべての API の一貫した管理、カスタム ドメイン名の設定、他の認証方法の使用などの機能も提供します。
- 要求メソッドを変更する
- 要求の URL セグメントを変更する
- Azure portal で API Management ドメインをセットアップする
- 基本認証を確認するためのポリシーをセットアップする