Azure Logic Apps から呼び出しできるカスタム API の作成Create custom APIs you can call from Azure Logic Apps

Azure Logic Apps が提供する数百個の組み込みコネクタをロジック アプリ ワークフローで利用できますが、コネクタとして利用できない API、システム、サービスを呼び出したい場合があります。Although Azure Logic Apps offers hundreds of connectors that you can use in logic app workflows, you might want to call APIs, systems, and services that aren't available as connectors. ロジック アプリで使用するアクションとトリガーを提供する独自の API を作成できます。You can create your own APIs that provide actions and triggers to use in logic apps. ロジック アプリのワークフローから呼び出すことができる独自の API は、次のような理由で作成する場合もあります。Here are other reasons why you might want to create your own APIs that you can call from logic app workflows:

  • 現行システム統合やデータ統合のワークフローを拡張する。Extend your current system integration and data integration workflows.
  • 仕事または個人的な作業の管理にサービスを利用する顧客を支援する。Help customers use your service to manage professional or personal tasks.
  • サービスが届く範囲を拡大する。サービスを見つけやすくする。サービスの用途を拡大する。Expand the reach, discoverability, and use for your service.

基本的に、コネクタはプラグ可能インターフェイスの REST、ドキュメント用の Swagger メタデータ形式、さらにデータ交換形式として JSON を利用する Web API です。Basically, connectors are web APIs that use REST for pluggable interfaces, Swagger metadata format for documentation, and JSON as their data exchange format. コネクタは HTTP エンドポイント経由で通信する REST API であるため、コネクタの構築には、.NET、Java、Python、Node.js など、任意の言語を利用できます。Because connectors are REST APIs that communicate through HTTP endpoints, you can use any language, like .NET, Java, Python, or Node.js, for building connectors. Azure App Service で API をホストすることもできます。Azure App Service は、最も効果的で簡単、かつ拡張可能な方法で API ホスティングを提供する PaaS (サービスとしてのプラットフォーム) です。You can also host your APIs on Azure App Service, a platform-as-a-service (PaaS) offering that provides one of the best, easiest, and most scalable ways for API hosting.

カスタム API をロジック アプリで利用するために、API はロジック アプリ ワークフローで特定のタスクを実行するアクションを提供できます。For custom APIs to work with logic apps, your API can provide actions that perform specific tasks in logic app workflows. API は、新しいデータ、またはあるイベントが指定の条件を満たすときにロジック アプリ ワークフローを開始するトリガーとして機能させることもできます。Your API can also act as a trigger that starts a logic app workflow when new data or an event meets a specified condition. このトピックでは、API のアクションやトリガーを構築するときに採用できる、動作に基づく共通パターンについて説明します。This topic describes common patterns that you can follow for building actions and triggers in your API, based on the behavior that you want your API to provide.

API は Azure App Service でホストできます。Azure App Service は、高い拡張性と容易な API ホスティングを提供するサービスとしてのプラットフォーム (PaaS) です。You can host your APIs on Azure App Service, a platform-as-a-service (PaaS) offering that provides highly scalable, easy API hosting.

ヒント

API は Web アプリとしてデプロイできますが、API アプリとしてデプロイすることを検討してください。クラウドやオンプレミスで API を構築、ホスト、利用するとき、作業が簡単になります。Although you can deploy your APIs as web apps, consider deploying your APIs as API apps, which can make your job easier when you build, host, and consume APIs in the cloud and on premises. API のコードを変更する必要はありません。コードを API アプリにデプロイするだけです。You don't have to change any code in your APIs -- just deploy your code to an API app. たとえば、次の言語で作成された API アプリをビルドする方法について確認してください。For example, learn how to build API apps created with these languages:

ロジック アプリ用の API アプリ サンプルについては、Azure Logic Apps GitHub リポジトリまたはブログをご覧ください。For API App samples built for logic apps, visit the Azure Logic Apps GitHub repository or blog.

カスタム API とカスタム コネクタの違いHow do custom APIs differ from custom connectors?

カスタム API とカスタム コネクタは、プラグ可能インターフェイスの REST、ドキュメント用の Swagger メタデータ形式、さらにデータ交換形式として JSON を利用する Web API です。Custom APIs and custom connectors are web APIs that use REST for pluggable interfaces, Swagger metadata format for documentation, and JSON as their data exchange format. また、これらの API とコネクタは HTTP エンドポイント経由で通信する REST API であるため、カスタム API とコネクタの構築には、.NET、Java、Python、Node.js など、任意の言語を利用できます。And because these APIs and connectors are REST APIs that communicate through HTTP endpoints, you can use any language, like .NET, Java, Python, or Node.js, for building custom APIs and connectors.

カスタム API を使用すると、コネクタではない API を呼び出すことができ、HTTP + Swagger、Azure API Management、または App Services で呼び出せるエンドポイントを提供できます。Custom APIs let you call APIs that aren't connectors, and provide endpoints that you can call with HTTP + Swagger, Azure API Management, or App Services. カスタム コネクタはカスタム API と同じように動作しますが、次の属性も備えています。Custom connectors work like custom APIs but also have these attributes:

  • Azure の Logic Apps コネクタ リソースとして登録されます。Registered as Logic Apps Connector resources in Azure.
  • Logic Apps デザイナーで Microsoft が管理するコネクタに並んでアイコンと共に表示されます。Appear with icons alongside Microsoft-managed connectors in the Logic Apps Designer.
  • ロジック アプリがデプロイされているリージョンで同じ Azure Active Directory テナントと Azure サブスクリプションを所有しているコネクタの作成者とロジック アプリ ユーザーのみが利用できます。Available only to the connectors' authors and logic app users who have the same Azure Active Directory tenant and Azure subscription in the region where the logic apps are deployed.

また、登録されたコネクタの Microsoft 認定を申請することもできます。You can also nominate registered connectors for Microsoft certification. このプロセスは、登録されたコネクタが一般的な使用基準を満たしていることを確認し、Power Automate および Microsoft Power Apps のユーザーがそれらのコネクタを利用できるようにします。This process verifies that registered connectors meet the criteria for public use and makes those connectors available for users in Power Automate and Microsoft Power Apps.

カスタム コネクタの詳細については、次のトピックを参照してくださいFor more information about custom connectors, see

便利なツールHelpful tools

API の操作やパラメーターを説明する Swagger ドキュメントも API に含まれるとき、カスタム API はロジック アプリと最も効果的に連動します。A custom API works best with logic apps when the API also has a Swagger document that describes the API's operations and parameters. Swashbuckle のようなライブラリの多くは、Swagger ファイルを自動的に生成できます。Many libraries, like Swashbuckle, can automatically generate the Swagger file for you. 表示名やプロパティの種類などに関して Swagger ファイルに注釈を付けるために、TRex を利用することもできます。Swagger ファイルとロジック アプリが効果的に連動します。To annotate the Swagger file for display names, property types, and so on, you can also use TRex so that your Swagger file works well with logic apps.

アクション パターンAction patterns

ロジック アプリがタスクを実行するには、カスタム API でアクションを提供する必要があります。For logic apps to perform tasks, your custom API should provide actions. API の各操作はアクションにマッピングされます。Each operation in your API maps to an action. 基本アクションは、HTTP 要求を受け取り、HTTP 応答を返すコントローラーです。A basic action is a controller that accepts HTTP requests and returns HTTP responses. そのため、たとえば、あるロジック アプリは HTTP 要求を Web アプリまたは API アプリに送信します。So for example, a logic app sends an HTTP request to your web app or API app. 次に、アプリはロジック アプリが処理できるコンテンツと共に HTTP 応答を返します。Your app then returns an HTTP response, along with content that the logic app can process.

標準的アクションの場合、API に HTTP 要求メソッドを記述し、そのメソッドについて Swagger ファイルで説明できます。For a standard action, you can write an HTTP request method in your API and describe that method in a Swagger file. その後、HTTP アクションまたは HTTP + Swagger アクションで API を直接呼び出すことができます。You can then call your API directly with an HTTP action or an HTTP + Swagger action. 既定では、応答は要求のタイムアウト期限内に返す必要があります。By default, responses must be returned within the request timeout limit.

標準的アクション パターン

API が時間のかかるタスクを完了するまでロジック アプリに待機させるには、API はこのトピックで説明する非同期ポーリング パターンまたは非同期 webhook パターンに従う必要があります。To make a logic app wait while your API finishes longer-running tasks, your API can follow the asynchronous polling pattern or the asynchronous webhook pattern described in this topic. これらのパターンのさまざまな動作を視覚化する際、類推が役立ちます。ケーキ屋さんにケーキを特注する過程を想像してください。For an analogy that helps you visualize these patterns' different behaviors, imagine the process for ordering a custom cake from a bakery. ポーリング パターンの場合、20 分ごとにケーキ屋さんに電話し、ケーキができているか確認する動作を再現します。The polling pattern mirrors the behavior where you call the bakery every 20 minutes to check whether the cake is ready. webhook パターンの場合、ケーキができたときに電話できるようにケーキ屋さんがあなたの電話番号を尋ねる動作を再現します。The webhook pattern mirrors the behavior where the bakery asks you for your phone number so they can call you when the cake is ready.

サンプルが必要であれば、Logic Apps GitHub リポジトリにアクセスしてください。For samples, visit the Logic Apps GitHub repository. アクションの使用状況測定については、こちらをご覧ください。Also, learn more about usage metering for actions.

ポーリング アクション パターンで長時間タスクを実行するPerform long-running tasks with the polling action pattern

要求のタイムアウト期限より長く実行される可能性があるタスクを API に実行させるには、非同期ポーリング パターンを利用できます。To have your API perform tasks that could run longer than the request timeout limit, you can use the asynchronous polling pattern. このパターンでは、API は別個のスレッドで作業しますが、ロジック アプリ エンジンとの有効な接続を維持します。This pattern has your API do work in a separate thread, but keep an active connection to the Logic Apps engine. この方法では、API が作業を完了する前にロジック アプリがタイムアウトしたり、ワークフローの次の段階に進んだりすることがありません。That way, the logic app does not time out or continue with the next step in the workflow before your API finishes working.

一般的なパターン:Here's the general pattern:

  1. API が要求を受け取り、作業を開始したことをエンジンが認識していることを確認します。Make sure that the engine knows that your API accepted the request and started working.
  2. エンジンがその後、ジョブの状態確認を要求したら、API がタスクを完了するタイミングをエンジンに知らせます。When the engine makes subsequent requests for job status, let the engine know when your API finishes the task.
  3. ロジック アプリのワークフローが続行できるように、関連データをエンジンに返します。Return relevant data to the engine so that the logic app workflow can continue.

ここで、前のパン屋さんの類推をポーリング パターンに適用します。パン屋さんに電話し、特注ケーキの配送を注文するところを想像してください。Now apply the previous bakery analogy to the polling pattern, and imagine that you call a bakery and order a custom cake for delivery. ケーキ作りの過程には時間がかかりますが、ケーキ屋さんがケーキを作っている間、あなたは電話の前で待ちたくありません。The process for making the cake takes time, and you don't want to wait on the phone while the bakery works on the cake. そこでケーキ屋さんが注文を確定したら、あなたは 20 分ごとに電話をかけることにします。ケーキの状態を確認するための電話です。The bakery confirms your order and has you call every 20 minutes for the cake's status. 20 分後、あなたはケーキ屋さんに電話しますが、ケーキはまだできておらず、さらに 20 分後に電話して欲しいと言われます。After 20 minutes pass, you call the bakery, but they tell you that your cake isn't done and that you should call in another 20 minutes. この往復プロセスは、あなたが電話し、ケーキ屋さんがあなたにケーキができたので届けると伝えるまで続きます。This back-and-forth process continues until you call, and the bakery tells you that your order is ready and delivers your cake.

それでは、このポーリング パターンをマッピングしましょう。So let's map this polling pattern back. ケーキ屋さんはカスタム API です。顧客であるあなたはロジック アプリ エンジンです。The bakery represents your custom API, while you, the cake customer, represent the Logic Apps engine. エンジンが API を呼び出し、要求を伝えると、API は要求を確定し、エンジンがジョブの状態を確認できる時間間隔を応答として返します。When the engine calls your API with a request, your API confirms the request and responds with the time interval when the engine can check job status. エンジンはジョブの状態確認を続け、API が応答でジョブが完了したと伝えたらデータをロジック アプリに返します。ロジック アプリはワークフローを続行します。The engine continues checking job status until your API responds that the job is done and returns data to your logic app, which then continues workflow.

ポーリング アクション パターン

API が従う手順を API の観点から説明すると次のようになります。Here are the specific steps for your API to follow, described from the API's perspective:

  1. API は HTTP 要求を受け取って作業を開始すると、この手順の後半で説明する location ヘッダーを付けた HTTP 202 ACCEPTED 応答をすぐに返します。When your API gets an HTTP request to start work, immediately return an HTTP 202 ACCEPTED response with the location header described later in this step. この応答により、API が要求を受け、要求ペイロード (データ入力) を受け取り、現在処理中であることをロジック アプリ エンジンは知ります。This response lets the Logic Apps engine know that your API got the request, accepted the request payload (data input), and is now processing.

    202 ACCEPTED 応答には次のヘッダーを含める必要があります。The 202 ACCEPTED response should include these headers:

    • 必須:ロジック アプリ エンジンが API のジョブの状態を確認できる URL の絶対パスを指定する location ヘッダーRequired: A location header that specifies the absolute path to a URL where the Logic Apps engine can check your API's job status

    • 省略可能: 待機時間を秒単位で指定する retry-after ヘッダー。この時間が経過しないとエンジンは location URL にジョブの状態を確認できません。Optional: A retry-after header that specifies the number of seconds that the engine should wait before checking the location URL for job status.

      既定では、エンジンは 20 秒ごとに確認します。By default, the engine checks every 20 seconds. 別の時間間隔を指定するには、retry-after ヘッダーと次のポーリングまでの秒数を追加します。To specify a different interval, include the retry-after header and the number of seconds until the next poll.

  2. 指定した時間が経過したら、ロジック アプリ エンジンは location URL に問い合わせ、ジョブの状態を確認します。After the specified time passes, the Logic Apps engine polls the location URL to check job status. API は次のような確認を実行し、次のような応答を返す必要があります。Your API should perform these checks and return these responses:

    • ジョブが完了したら、HTTP 200 OK 応答と応答ペイロード (次の手順の入力) を返します。If the job is done, return an HTTP 200 OK response, along with the response payload (input for the next step).

    • ジョブがまだ処理中の場合、別の HTTP 202 ACCEPTED 応答を返します。ただし、ヘッダーは元の応答と同じです。If the job is still processing, return another HTTP 202 ACCEPTED response, but with the same headers as the original response.

API がこのパターンに従うとき、ロジック アプリ ワークフロー定義で何もしなくてもジョブの状態確認が続行します。When your API follows this pattern, you don't have to do anything in the logic app workflow definition to continue checking job status. エンジンは HTTP 202 ACCEPTED 応答と有効な location ヘッダーを受け取ると、非同期パターンに従い、API が 202 以外の応答を返すまで location ヘッダーを確認します。When the engine gets an HTTP 202 ACCEPTED response and a valid location header, the engine respects the asynchronous pattern and checks the location header until your API returns a non-202 response.

ヒント

非同期パターンの例が必要であれば、ここで GitHub の非同期コントローラー応答サンプルをご覧ください。For an example asynchronous pattern, review this asynchronous controller response sample in GitHub.

webhook アクション パターンで長時間タスクを実行するPerform long-running tasks with the webhook action pattern

代替として、長時間タスクや非同期処理に webhook パターンを使用できます。As an alternative, you can use the webhook pattern for long-running tasks and asynchronous processing. このパターンでは、API からの "コールバック" があるまでロジック アプリは一時停止し、待機します。コールバックの後に処理を完了し、ワークフローを続行します。This pattern has the logic app pause and wait for a "callback" from your API to finish processing before continuing workflow. このコールバックは、イベントの発生時にメッセージを URL に送信する HTTP POST です。This callback is an HTTP POST that sends a message to a URL when an event happens.

ここで、前のパン屋さんの類推を webhook パターンに適用します。パン屋さんに電話し、特注ケーキの配送を注文するところを想像してください。Now apply the previous bakery analogy to the webhook pattern, and imagine that you call a bakery and order a custom cake for delivery. ケーキ作りの過程には時間がかかりますが、ケーキ屋さんがケーキを作っている間、あなたは電話の前で待ちたくありません。The process for making the cake takes time, and you don't want to wait on the phone while the bakery works on the cake. そこでケーキ屋さんがあなたの注文を確定するとき、あなたはケーキ屋さんに電話番号を伝えます。ケーキができたときに電話できるようにです。The bakery confirms your order, but this time, you give them your phone number so they can call you when the cake is done. ケーキ屋さんは注文の品ができたとあなたに伝え、品物を届けます。This time, the bakery tells you when your order is ready and delivers your cake.

この webhook パターンをマッピングするとき、ケーキ屋さんはカスタム API です。顧客であるあなたはロジック アプリ エンジンです。When we map this webhook pattern back, the bakery represents your custom API, while you, the cake customer, represent the Logic Apps engine. エンジンは API を呼び出し、要求と "コールバック" URL を与えます。The engine calls your API with a request and includes a "callback" URL. ジョブが完了すると、API は URL を利用し、エンジンにジョブ完了を通知し、ロジック アプリにデータを返します。ロジック アプリはワークフローを続行します。When the job is done, your API uses the URL to notify the engine and return data to your logic app, which then continues workflow.

このパターンでは、コントローラーに subscribeunsubscribe という 2 つのエンドポイントを設定します。For this pattern, set up two endpoints on your controller: subscribe and unsubscribe

  • subscribe エンドポイント:ワークフローで API のアクションまで実行が到達すると、ロジック アプリ エンジンは subscribe エンドポイントを呼び出します。subscribe endpoint: When execution reaches your API's action in the workflow, the Logic Apps engine calls the subscribe endpoint. この手順では、ロジック アプリは API が保存するコールバック URL を作成し、作業の完了時に API からコールバックが届くまで待機します。This step causes the logic app to create a callback URL that your API stores and then wait for the callback from your API when work is complete. API は URL に HTTP POST でコールバックし、ロジック アプリの入力として返すコンテンツやヘッダーがあれば、それを渡します。Your API then calls back with an HTTP POST to the URL and passes any returned content and headers as input to the logic app.

  • unsubscribe エンドポイント:ロジック アプリの実行が取り消された場合、ロジック アプリ エンジンは unsubscribe エンドポイントを呼び出します。unsubscribe endpoint: If the logic app run is canceled, the Logic Apps engine calls the unsubscribe endpoint. API はコールバック URL を登録解除し、プロセスがあれば必要に応じて停止できます。Your API can then unregister the callback URL and stop any processes as necessary.

webhook アクション パターン

注意

現在のところ、ロジック アプリ デザイナーでは、Swagger で webhook エンドポイントを検出できません。Currently, the Logic App Designer doesn't support discovering webhook endpoints through Swagger. そこでこのパターンの場合、webhook アクションを追加し、要求の URL、ヘッダー、本文を指定する必要があります。So for this pattern, you have to add a Webhook action and specify the URL, headers, and body for your request. ワークフローのアクションとトリガー」も参照してください。See also Workflow actions and triggers. コールバック URL を渡すために、必要に応じて、前のいずれかのフィールドで @listCallbackUrl() ワークフロー機能を利用できます。To pass in the callback URL, you can use the @listCallbackUrl() workflow function in any of the previous fields as necessary.

ヒント

webhook パターンのサンプルについては、ここで GitHub の webhook トリガー サンプルを参照してください。For an example webhook pattern, review this webhook trigger sample in GitHub.

トリガー パターンTrigger patterns

カスタム API は、新しいデータ、またはあるイベントが指定の条件を満たすときにロジック アプリを開始するトリガーとして機能させることができます。Your custom API can act as a trigger that starts a logic app when new data or an event meets a specified condition. このトリガーはサービス エンドポイントの新しいデータまたはイベントを定期的に確認するか、待ち受けることができます。This trigger can either check regularly, or wait and listen, for new data or events at your service endpoint. 新しいデータ、またはあるイベントが指定の条件を満たした場合、トリガーが発動し、トリガーを待ち受けていたロジック アプリが起動します。If new data or an event meets the specified condition, the trigger fires and starts the logic app, which is listening to that trigger. この方法でロジック アプリを開始するには、API でポーリング トリガー パターンまたは webhook トリガー パターンを利用します。To start logic apps this way, your API can follow the polling trigger or the webhook trigger pattern. これらのパターンは、ポーリング アクションwebhook アクションのそれに似ています。These patterns are similar to their counterparts for polling actions and webhook actions. トリガーの使用状況測定については、こちらをご覧ください。Also, learn more about usage metering for triggers.

ポーリング トリガー パターンで新しいデータまたはイベントを定期的に確認するCheck for new data or events regularly with the polling trigger pattern

ポーリング トリガーは、このトピックの前半で説明したポーリング アクションに似た動作をします。A polling trigger acts much like the polling action previously described in this topic. ロジック アプリ エンジンはトリガー エンドポイントに定期的に問い合わせ、新しいデータまたはイベントがないか確認します。The Logic Apps engine periodically calls and checks the trigger endpoint for new data or events. 指定の条件に一致する新しいデータまたはあるイベントをエンジンが見つけると、トリガーが発動します。If the engine finds new data or an event that meets your specified condition, the trigger fires. データを入力として処理するロジック アプリ インスタンスをエンジンが作成します。Then, the engine creates a logic app instance that processes the data as input.

ポーリング トリガー パターン

注意

ロジック アプリ インスタンスが作成されなくても、ポーリング要求はアクション実行として数えられます。Each polling request counts as an action execution, even when no logic app instance is created. 同じデータが複数回処理されることを防止するには、すでに読まれ、ロジック アプリに渡されたデータをトリガーは消去する必要があります。To prevent processing the same data multiple times, your trigger should clean up data that was already read and passed to the logic app.

ポーリング トリガーの手順を API の観点から説明すると次のようになります。Here are specific steps for a polling trigger, described from the API's perspective:

新しいデータまたはイベントが見つかったか?Found new data or event? API 応答API response
FoundFound 応答ペイロード (次の手順の入力) と共に HTTP 200 OK 状態を返します。Return an HTTP 200 OK status with the response payload (input for next step).
この応答でロジック アプリ インスタンスが作成され、ワークフローが開始されます。This response creates a logic app instance and starts the workflow.
見つかりませんNot found location ヘッダーと retry-after ヘッダーと共に HTTP 202 ACCEPTED 状態を返します。Return an HTTP 202 ACCEPTED status with a location header and a retry-after header.
トリガーの場合、location ヘッダーに triggerState クエリ パラメーターも含める必要があります。このクエリ パラメーターは通常、"timestamp" です。For triggers, the location header should also contain a triggerState query parameter, which is usually a "timestamp." API はこの識別子を利用し、ロジック アプリがトリガーがされた最後の時間を追跡記録できます。Your API can use this identifier to track the last time that the logic app was triggered.

たとえば、新しいファイルがないか、サービスに定期的に確認するには、次の動作を含むポーリング トリガーを構築できます。For example, to periodically check your service for new files, you might build a polling trigger that has these behaviors:

要求に triggerState が含まれていますか?Request includes triggerState? API 応答API response
いいえNo HTTP 202 ACCEPTED 状態と location ヘッダーを返します。ヘッダーの triggerState を現在の時刻に設定し、retry-after 間隔を 15 秒に設定します。Return an HTTP 202 ACCEPTED status plus a location header with triggerState set to the current time and the retry-after interval to 15 seconds.
はいYes triggerStateDateTime 後に追加されたファイルがないか、サービスに確認します。Check your service for files added after the DateTime for triggerState.
見つかったファイルの数Number of files found API 応答API response
1 つのファイルSingle file HTTP 200 OK 状態とコンテンツ ペイロードを返し、返すファイルの triggerStateDateTime に更新し、retry-after 間隔を 15 秒に設定します。Return an HTTP 200 OK status and the content payload, update triggerState to the DateTime for the returned file, and set retry-after interval to 15 seconds.
複数のファイルMultiple files 一度に 1 つのファイルと HTTP 200 OK 状態を返し、triggerState を更新し、retry-after 間隔を 0 秒に設定します。Return one file at a time and an HTTP 200 OK status, update triggerState, and set the retry-after interval to 0 seconds.
これらの手順で、さらに多くのデータが利用できること、エンジンは location ヘッダーの URL からデータをすぐに要求しなければならないことがエンジンに知らされます。These steps let the engine know that more data is available, and that the engine should immediately request the data from the URL in the location header.
ファイルなしNo files HTTP 202 ACCEPTED 状態を返します。triggerState は変更しません。retry-after 間隔を 15 秒に設定します。Return an HTTP 202 ACCEPTED status, don't change triggerState, and set the retry-after interval to 15 seconds.

ヒント

ポーリング トリガー パターンのサンプルについては、ここで GitHub のポーリング トリガー コントローラー サンプルを参照してください。For an example polling trigger pattern, review this poll trigger controller sample in GitHub.

webhook トリガー パターンで新しいデータまたはイベントを待ち受けるWait and listen for new data or events with the webhook trigger pattern

webhook トリガーは、サービス エンドポイントで新しいデータまたはイベントを待ち受けるプッシュ トリガーです。A webhook trigger is a push trigger that waits and listens for new data or events at your service endpoint. 新しいデータまたはあるイベントが指定の条件を満たす場合、トリガーが発動し、ロジック アプリ インスタンスが作成されます。このインスタンスはデータを入力として処理します。If new data or an event meets the specified condition, the trigger fires and creates a logic app instance, which then processes the data as input. webhook トリガーはこのトピックの前半で説明した webhook アクションに似た動作をします。subscribe エンドポイントと unsubscribe エンドポイントで設定されます。Webhook triggers act much like the webhook actions previously described in this topic, and are set up with subscribe and unsubscribe endpoints.

  • subscribe エンドポイント:ロジック アプリに webhook トリガーを追加し、保存するとき、ロジック アプリ エンジンは subscribe エンドポイントを呼び出します。subscribe endpoint: When you add and save a webhook trigger in your logic app, the Logic Apps engine calls the subscribe endpoint. この手順により、API が保存するコールバック URL をロジック アプリが作成します。This step causes the logic app to create a callback URL that your API stores. 新しいデータまたはあるイベントが指定の条件を満たす場合、API は URL に HTTP POST でコールバックします。When there's new data or an event that meets the specified condition, your API calls back with an HTTP POST to the URL. コンテンツ ペイロードとヘッダーは入力としてロジック アプリに渡されます。The content payload and headers pass as input to the logic app.

  • unsubscribe エンドポイント:webhook が発動するか、ロジック アプリ全体が削除されると、ロジック アプリ エンジンは unsubscribe エンドポイントを呼び出します。unsubscribe endpoint: If the webhook trigger or entire logic app is deleted, the Logic Apps engine calls the unsubscribe endpoint. API はコールバック URL を登録解除し、プロセスがあれば必要に応じて停止できます。Your API can then unregister the callback URL and stop any processes as necessary.

webhook トリガー パターン

注意

現在のところ、ロジック アプリ デザイナーでは、Swagger で webhook エンドポイントを検出できません。Currently, the Logic App Designer doesn't support discovering webhook endpoints through Swagger. そこでこのパターンの場合、webhook トリガーを追加し、要求の URL、ヘッダー、本文を指定する必要があります。So for this pattern, you have to add a Webhook trigger and specify the URL, headers, and body for your request. HTTPWebhook トリガー」もご覧ください。See also HTTPWebhook trigger. コールバック URL を渡すために、必要に応じて、前のいずれかのフィールドで @listCallbackUrl() ワークフロー機能を利用できます。To pass in the callback URL, you can use the @listCallbackUrl() workflow function in any of the previous fields as necessary.

同じデータが複数回処理されることを防止するには、すでに読まれ、ロジック アプリに渡されたデータをトリガーは消去する必要があります。To prevent processing the same data multiple times, your trigger should clean up data that was already read and passed to the logic app.

ヒント

webhook パターンのサンプルについては、ここで GitHub の webhook トリガー コントローラー サンプルを参照してください。For an example webhook pattern, review this webhook trigger controller sample in GitHub.

ロジック アプリからの API の呼び出しのセキュリティ保護Secure calls to your APIs from logic apps

カスタム API を作成した後、ロジック アプリから安全に呼び出すことができるように API の認証を設定します。After creating your custom APIs, set up authentication for your APIs so that you can call them securely from logic apps. ロジック アプリからカスタム API の呼び出しをセキュリティで保護する方法について確認してください。Learn how to secure calls to custom APIs from logic apps.

API をデプロイして呼び出すDeploy and call your APIs

認証を設定した後は、API のデプロイを設定します。After you set up authentication, set up deployment for your APIs. ロジック アプリからカスタム API をデプロイして呼び出す方法について確認してください。Learn how to deploy and call custom APIs from logic apps.

カスタム API を Azure に公開するPublish custom APIs to Azure

カスタム API を Azure の他の Logic Apps ユーザーが使用できるようにするには、セキュリティを追加したうえで Logic Apps コネクタとして登録する必要があります。To make your custom APIs available for other Logic Apps users in Azure, you must add security and register them as Logic App connectors. 詳細については、「Custom connectors overview (カスタム コネクタの概要)」を参照してください。For more information, see Custom connectors overview.

Logic Apps、Power Automate、および Microsoft Power Apps のすべてのユーザーがカスタム API を使用できるようにするには、セキュリティを追加したうえで API を Logic Apps コネクタとして登録し、Microsoft Azure 認定プログラムにコネクタを申請する必要があります。To make your custom APIs available to all users in Logic Apps, Power Automate, and Microsoft Power Apps, you must add security, register your APIs as Logic App connectors, and nominate your connectors for the Microsoft Azure Certified program.

サポートを受けるGet support

次の手順Next steps