適用対象: Azure Logic Apps (従量課金 + Standard)
シナリオによっては、他のサービスやワークフローから受信要求を受信できるロジック アプリ ワークフロー、または URL を使って呼び出すことができるワークフローを作成することが、必要になる場合があります。 このタスクでは、次の要求ベースのトリガーの種類のいずれを使うときにでも、ワークフローでネイティブ同期 HTTPS エンドポイントを公開できます。
- 依頼
- HTTP webhook
- ApiConnectionWebhook 型であり、受信 HTTPS 要求を受信できるマネージド コネクタ トリガー
このガイドでは、 要求 トリガーを追加してワークフローの呼び出し可能なエンドポイントを作成し、別のワークフローからそのエンドポイントを呼び出す方法について説明します。 すべての原則は、受信要求を受信できる他の要求ベースのトリガーの種類にも同じように適用されます。
前提条件
Azure アカウントとサブスクリプション。 サブスクリプションをお持ちでない場合には、無料の Azure アカウントにサインアップしてください。
呼び出し可能なエンドポイントを作成するワークフローを含むロジック アプリ リソース。
空のワークフローから、または現在のトリガーを置き換えることができる既存のワークフローから、始めることができます。 この例では、空のワークフローから始めます。
HTTP 要求を送信してソリューションをテストできるツールをインストールまたは使用します。次に例を示します。
- Visual Studio Code を Visual Studio Marketplace からの拡張機能と一緒に使用する
- PowerShell Invoke-RestMethod
- Microsoft Edge - ネットワーク コンソール ツール
- ブルーノ
- curl
注意
資格情報、シークレット、アクセス トークン、API キーなどの機密データがあるシナリオでは、必要なセキュリティ機能でデータを保護するツールを必ず使用してください。 このツールはオフラインまたはローカルで動作する必要があり、オンライン アカウントへのサインインやクラウドへのデータの同期は必要ありません。 これらの特性を持つツールを使用すると、機密データを一般に公開するリスクが軽減されます。
呼び出し可能なエンドポイントを作成する
お使いのロジック アプリ ワークフローが Standard または従量課金のどちらであるかに基づいて、対応する手順に従ってください。
Azure portal で、Standard ロジック アプリ リソースを開きます。
リソース サイドバー メニューの [ ワークフロー] で [ ワークフロー] を選択し、空のワークフローを選択します。
ワークフロー サイドバー メニューの [ ツール] で、デザイナーを選択してワークフローを開きます。
トリガーを追加する一般的な手順に従って、要求トリガーをワークフローに追加します。
この例では、 HTTP 要求を受信したときにという名前のトリガーを続行します。
必要に応じて、[要求本文の 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 URL ] ボックスに、他のサービスがロジック アプリ ワークフローの呼び出しとトリガーに使用できる、生成されたコールバック URL が表示されるようになりました。 この URL には、認証に使用される Shared Access Signature (SAS) キーを指定するクエリ パラメーターが含まれています。
HTTP URL ボックスの横にあるファイルのコピー アイコンを選択して、コールバック 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}
![ワークフローの URL を含む従量課金ロジック アプリの [概要] ページを示すスクリーンショット。](media/logic-apps-http-endpoint/find-trigger-url-consumption.png#lightbox)
待機する要求メソッドの選択
既定では、Request トリガーは POST 要求を待機します。 呼び出し元が使用する必要のある別のメソッドを指定できますが、指定できるメソッドは 1 つだけです。
要求トリガーのメソッド一覧から、トリガーが必要とするメソッドを選択します。 または、カスタム メソッドを指定できます。
たとえば、後でエンドポイントの URL をテストできるように [GET] メソッドを選択します。
エンドポイント URL を使用してパラメーターを渡す
エンドポイントの URL 経由でパラメーター値を受け取るとき、次の選択肢が与えられます。
GET パラメーター経由で値を受け取るか、URL パラメーター経由で値を受け取ります。
これらの値は、エンドポイントの URL で名前と値のペアとして渡されます。 このオプションでは、要求トリガーで GET メソッドを使用する必要があります。 後続のアクションでは、式で
triggerOutputs()関数を使用することで、パラメーター値をトリガー出力として取得できます。要求トリガーのパラメーターの相対パスを使用して値を受け入れます。
これらの値は、エンドポイントの URL で相対パスから渡されます。 また、明示的に、トリガーで待機するメソッドを選択する必要があります。 後続のアクションでは、これらの出力を直接参照することで、パラメーター値をトリガー出力として取得できます。
GET パラメーター経由で値を受け取る
要求トリガーで、メソッドの一覧から GET メソッドを選択します。
詳細については、「待機する要求メソッドの選択」を参照してください。
アクションを追加する一般的な手順に従って、応答アクションをワークフローに追加します。
パラメーター値を取得する
triggerOutputs()式を作成するには、次の手順を実行します。応答アクションで、Body プロパティ内を選択して、動的コンテンツ (稲妻アイコン) と式エディター (数式アイコン) のオプションが表示されるようにします。 数式アイコンを選んで式エディターを開きます。
式ボックスに次の式を入力し、
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}ブラウザーは、"郵便番号: 123456" というテキストを含む応答を返します。
注
ハッシュまたはシャープ記号 (#) を URI に含める場合、エンコードされたバージョン %25%23 を代わりに使用します。
相対パス経由で値を受け取る
Request トリガーで、[高度なパラメーター] の一覧を開いて [相対パス] を選びます。これにより、このプロパティがトリガーに追加されます。
[相対パス] プロパティで、URL で受け入れるようにする JSON スキーマ内のパラメーターの相対パス (
/address/{postalCode}など) を指定します。
応答アクションの Body プロパティに、トリガーの相対パスで指定したパラメーターを表すトークンを含めます。
たとえば、 応答 アクションで
Postal Code: {postalCode}を返す必要があるとします。[本文] プロパティで、
Postal Code:を末尾にスペースを付けて入力します。 動的コンテンツの一覧が開いたままでいるように、編集ボックスの中にカーソルを置いたままにします。稲妻アイコンを選択して、動的コンテンツ リストを開きます。 [ HTTP 要求の受信時 ] セクションで、 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}呼び出し可能エンドポイントをテストするには、要求トリガーから更新されたコールバック URL をコピーし、別のブラウザー ウィンドウに URL を貼り付け、URL の
%7BpostalCode%7Dを 123456 に置き換えて、 Enter キーを押します。ブラウザーは、"郵便番号: 123456" というテキストを含む応答を返します。
注
ハッシュまたはシャープ記号 (#) を 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"
}
}
}
}
}
他のワークフローを呼び出す
要求を受信できる他のワークフローを、現在のワークフロー内に入れ子にして、呼び出すことができます。 これらのワークフローを呼び出すには、次の手順に従います。
デザイナーで、[ワークフローの呼び出し] という名前のワークフロー 操作 アクション をこのロジック アプリに追加します。
[ワークフロー名] の一覧に、選べるワークフローが表示されます。
[ワークフロー名] の一覧で、呼び出すワークフローを選びます。次に例を示します。
![[標準ワークフロー]、[このワークフロー アプリでワークフローを呼び出す]、[ワークフロー名] リストを開いたアクション、および呼び出す使用可能なワークフローを示すスクリーンショット。](media/logic-apps-http-endpoint/select-workflow-standard.png)
![[操作の選択] ボックスと呼び出し対象の使用可能なワークフローを含む従量課金ワークフローを示すスクリーンショット。](media/logic-apps-http-endpoint/select-workflow-consumption.png)
受信要求のコンテンツを参照する
受信要求のコンテンツの種類が application/json である場合は、受信要求内のプロパティを参照できます。 そうでない場合、このコンテンツは、他の API に渡すことができる 1 つのバイナリ ユニットとして扱われます。 このコンテンツをロジック アプリのワークフローの内部で参照するには、まず、そのコンテンツを変換する必要があります。
たとえば、application/xml の種類を持つコンテンツを渡す場合は、xpath() 式を使用して XPath 抽出を実行するか、または json() 式を使用して XML を JSON に変換することができます。 詳細については、サポートされているコンテンツの種類を参照してください。
受信要求から出力を取得するには、triggerOutputs 式を使用できます。 たとえば、次の例のような出力があるとします。
{
"headers": {
"content-type" : "application/json"
},
"body": {
"myProperty" : "property value"
}
}
body プロパティに具体的にアクセスするには、triggerBody()式をショートカットとして使用します。
要求に応答する
ワークフローをトリガーする特定の要求に応答するため、呼び出し元にコンテンツを返したい場合があります。 応答の状態コード、ヘッダー、本文を作成するには、 Response アクションを使用します。 このアクションは、ワークフローの最後のみでなく、ワークフローの任意の場所で使用できます。 ワークフローに応答アクションが含まれていない場合、エンドポイントは 202 Accepted 状態ですぐに応答します。
元の呼び出し元が正常に応答を取得するには、トリガーされたワークフローが入れ子になったワークフローとして呼び出されない限り、応答に必要なすべての手順が要求タイムアウト制限内で完了する必要があります。 この制限内に応答が返されない場合、受信要求はタイムアウトし、408 Client timeout 応答を受信します。
入れ子にされたワークフローの場合は、必要な時間の長さに関係なく、親ワークフローはすべての手順が完了するまで応答を待ち続けます。
応答を作成する
応答本文には、複数のヘッダーと任意の種類のコンテンツを含めることができます。 たとえば、次の応答のヘッダーは、応答のコンテンツ タイプが application/json されていること、および要求トリガーのこのトピックで前述した 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": {}
}
よく寄せられる質問
受信呼び出しの URL セキュリティについて
Azure では、 Shared Access Signature (SAS) を使用してロジック アプリのコールバック URL を安全に生成します。 この署名はクエリ パラメーターとして渡され、ワークフローを実行する前に検証される必要があります。 Azure では、ロジック アプリごとの秘密キー、トリガー名、および実行される操作の一意の組み合わせを使用して署名が生成されます。 そのため、ロジック アプリの秘密キーにアクセスできなければ、有効な署名を生成できません。
重要
運用環境とセキュリティの厳しいシステムでは、次の理由により、ブラウザーから直接ワークフローを呼び出さないことを強くお勧めします。
- 共有アクセス キーが URL に表示されます。
- Azure Logic Apps の顧客にまたがる共有ドメインのために、セキュリティ コンテンツ ポリシーを管理できません。
トランスポート層セキュリティ (TLS)、Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth)、Azure API Management を使用したロジック アプリ ワークフローの公開、受信呼び出しの IP アドレスの制限など、ワークフローへの受信呼び出しのセキュリティ、承認、暗号化の詳細については、「セキュリティで保護されたアクセスとデータ - 要求ベースのトリガーへの受信呼び出しのアクセス」を参照してください。
呼び出し可能なエンドポイントをさらに構成できますか?
はい。HTTPS エンドポイントでは、 Azure API Management を使用したより高度な構成がサポートされます。 このサービスでは、次のような、ロジック アプリを含むすべての API の一貫した管理、カスタム ドメイン名の設定、他の認証方法の使用などの機能も提供します。
- 要求メソッドを設定する
- URL の書き換え
- Azure portal で API Management ドメインをセットアップする
- 基本認証を確認するためのポリシーをセットアップする