Azure Logic Apps で HTTPS エンドポイントを使用して呼び出したり、トリガーしたり、入れ子にしたりできるワークフローを作成する
適用対象: Azure Logic Apps (従量課金プラン + Standard)
シナリオによっては、他のサービスやワークフローから受信要求を受信できるロジック アプリ ワークフロー、または URL を使って呼び出すことができるワークフローを作成することが、必要になる場合があります。 このタスクでは、次の要求ベースのトリガーの種類のいずれを使うときにでも、ワークフローでネイティブ同期 HTTPS エンドポイントを公開できます。
- Request
- HTTP Webhook
- ApiConnectionWebhook 型であり、受信 HTTPS 要求を受信できるマネージド コネクタ トリガー
このガイドでは、要求トリガーを追加してワークフロー用の呼び出し可能なエンドポイントを作成する方法と、別のワークフローからそのエンドポイントを呼び出す方法について説明します。 すべての原則は、受信要求を受信できる他の要求ベースのトリガーの種類にも同じように適用されます。
前提条件
Azure アカウントとサブスクリプション。 サブスクリプションをお持ちでない場合には、無料の Azure アカウントにサインアップしてください。
Request トリガーを使って呼び出し可能なエンドポイントを作成するロジック アプリ ワークフロー。 空のワークフローから、または現在のトリガーを置き換えることができる既存のワークフローから、始めることができます。 この例では、空のワークフローから始めます。
HTTP 要求を送信してソリューションをテストできる次のようなツールをインストールまたは使用します。
- Visual Studio Code を Visual Studio Marketplace からの拡張機能と一緒に使用する
- PowerShell Invoke-RestMethod
- Microsoft Edge - ネットワーク コンソール ツール
- Bruno
- curl
注意事項
資格情報、シークレット、アクセス トークン、API キーなどの機密データがあるシナリオでは、必要なセキュリティ機能でデータを保護したうえで、ツールは必ずオフラインまたはローカルで動作し、データをクラウドに同期せず、オンライン アカウントにサインインする必要がないものを使用してください。 このようにすることで、機密データを一般に公開するリスクを軽減できます。
呼び出し可能なエンドポイントを作成する
お使いのロジック アプリ ワークフローが 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 をコピーするには、次のオプションがあります。
コールバック URL をテストしてワークフローをトリガーするには、HTTP 要求ツールとその手順を使用して、Request トリガーが想定するメソッドを含む HTTP 要求を URL に送信します。
この例では、コピーした URL と共に 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}
待機する要求メソッドの選択
既定では、Request トリガーは POST
要求を待機します。 呼び出し元が使用する必要のある別のメソッドを指定できますが、指定できるメソッドは 1 つだけです。
Request トリガーで、[高度なパラメーター] の一覧を開き、[メソッド] を選びます。これにより、このプロパティがトリガーに追加されます。
[メソッド] 一覧から、代わりにトリガーで待機する別のメソッドを選択します。 または、カスタム メソッドを指定できます。
たとえば、後でエンドポイントの URL をテストできるように [GET] メソッドを選択します。
エンドポイント URL を使用してパラメーターを渡す
エンドポイントの URL 経由でパラメーター値を受け取るとき、次の選択肢が与えられます。
GET パラメーター経由で値を受け取るか、URL パラメーター経由で値を受け取ります。
これらの値は、エンドポイントの URL で名前と値のペアとして渡されます。 このオプションでは、Request トリガーで GET メソッドを使用する必要があります。 後続のアクションでは、式で
triggerOutputs()
関数を使用することで、パラメーター値をトリガー出力として取得できます。Request トリガーのパラメーターに対して相対パス経由で値を受け取ります。
これらの値は、エンドポイントの URL で相対パスから渡されます。 また、明示的に、トリガーで待機するメソッドを選択する必要があります。 後続のアクションでは、これらの出力を直接参照することで、パラメーター値をトリガー出力として取得できます。
GET パラメーター経由で値を受け取る
Request トリガーで、[高度なパラメーター] の一覧を開き、[メソッド] プロパティをトリガーに追加して、GET メソッドを選びます。
詳細については、「待機する要求メソッドの選択」を参照してください。
デザイナーで、 次の一般的な手順に従って、パラメーター値を使用する場所にアクションを追加します。
この例では、Response という名前のアクションを選択します。
パラメーター値を取得する
triggerOutputs()
式を作成するには、次の手順を実行します。応答アクションで、[本体] プロパティ内を選んで、動的なコンテンツ (稲妻アイコン) と式エディター (数式アイコン) のオプションを表示します。 数式アイコンを選んで式エディターを開きます。
式ボックスに次の式を入力し、
parameter-name
を自分のパラメーター名に置き換えて、[OK] を選びます。triggerOutputs()['queries']['parameter-name']
Body プロパティでは、式が
triggerOutputs()
トークンに解決されます。ワークフローを保存し、デザイナーから離れてデザイナーに戻ると、トークンには指定したパラメーター名が表示されます。次はその例です。
コード ビューでは、Body プロパティが [応答] アクションの定義に次のように表示されます。
"body": "@{triggerOutputs()['queries']['parameter-name']}",
たとえば、
postalCode
という名前のパラメーターに値を渡すとします。 Body プロパティでは、文字列、Postal Code:
と末尾のスペース、それに続く対応する式が指定されます。
呼び出し可能なエンドポイントをテストする
Request トリガーからワークフロー 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
を代わりに使用します。
相対パス経由で値を受け取る
Request トリガーで、[高度なパラメーター] の一覧を開いて [相対パス] を選びます。これにより、このプロパティがトリガーに追加されます。
[相対パス] プロパティで、URL で受け入れるようにする JSON スキーマ内のパラメーターの相対パス (
/address/{postalCode}
など) を指定します。Request トリガーで、こちらの一般的な手順に従って、パラメーターの値を使うアクションを追加します。
この例では、 [応答] アクションを追加します。
応答アクションの [本文] プロパティで、トリガーの相対パスで指定したパラメーターを表すトークンを含めます。
たとえば、応答アクションで
Postal Code: {postalCode}
を返すようにするとします。ワークフローを保存します。
Request トリガーでコールバック 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}
呼び出し可能なエンドポイントをテストするには、Request トリガーから更新後のコールバック URL をコピーし、その URL を別のブラウザー ウィンドウに貼り付け、URL の
%7BpostalCode%7D
を123456
に変更し、Enter キーを押します。ブラウザーから応答が返され、
Postal Code: 123456
というテキストが表示されます。
Note
ハッシュまたはシャープ記号 ( # ) を URI に含める場合、エンコードされたバージョン %25%23
を代わりに使用します。
エンドポイント URL を使用してワークフローを呼び出す
エンドポイントを作成したら、そのエンドポイントの完全な URL に HTTPS 要求を送信して、ワークフローをトリガーできます。 Azure Logic Apps ワークフローには、直接アクセス エンドポイントのサポートが組み込まれています。
スキーマから生成されるトークン
Request トリガーで 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 応答を受信します。
入れ子にされたワークフローの場合は、必要な時間の長さに関係なく、親ワークフローはすべての手順が完了するまで応答を待ち続けます。
応答を作成する
応答本文には、複数のヘッダーと任意の種類のコンテンツを含めることができます。 たとえば、次の応答のヘッダーでは、このトピックで Request トリガーについて先に説明した 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 ドメインをセットアップする
- 基本認証を確認するためのポリシーをセットアップする