Azure Logic Apps のカスタム コネクタの概要

Azure Logic Apps を使用してワークフローを構築する場合、"コネクタ" を使用して他のアプリ、サービス、システム、プロトコル、プラットフォームのデータ、イベント、リソースにすばやく簡単にアクセスすることができます (多くの場合、コードを書く必要はありません)。 コネクタには、ワークフローのステップとして使用できる事前構築済みの操作が用意されています。 Azure Logic Apps には、使用できる数多くのコネクタが用意されています。 アクセス対象のリソースに使用できるコネクタがない場合は、一般的な HTTP 操作を使用してサービスと通信するか、カスタム コネクタを作成することができます。

この概要では、コネクタの概要と、一般的な動作について説明します。

コネクタとは

技術的に、多くのコネクタは、基礎となるサービスが Azure Logic Apps との通信に使用する API のプロキシまたはラッパーを提供します。 このコネクタには、ワークフローでタスクを実行するために使用する操作が用意されています。 操作は、構成できるプロパティがある "トリガー" または "アクション" として使用できます。 トリガーとアクションの中には、たとえば、ユーザー アカウントへのアクセスを認証するために、まず基礎となるサービスやシステムへの接続を作成し、構成する必要があるものもあります。 さらなる概要情報については、Azure Logic Apps、Microsoft Power Automate、Microsoft Power Apps のコネクタの概要に関するページを確認してください。

Azure Logic Apps でよく使用されるコネクタの詳細については、次のドキュメントを参照してください。

トリガー

"トリガー" は、ワークフローを開始するイベントを指定するものであり、どのワークフローでも常に最初のステップになります。 各トリガーはまた、トリガーがイベントを監視したり、それに応答したりする方法を制御する特定の起動パターンに従います。 通常、トリガーは "ポーリング" パターンまたは "プッシュ" パターンに従いますが、トリガーを両方のバージョンで使用できる場合もあります。

  • "ポーリング トリガー" を使って、指定されたスケジュールで特定のサービスまたはシステムを定期的にチェックして、新しいデータまたは特定のイベントをチェックします。 新しいデータが利用可能な場合、または特定のイベントが発生した場合、ワークフローの新しいインスタンスが、このトリガーによって作成および実行されます。 この新しいインスタンスから、入力として渡されたデータを使用できます。

  • "プッシュ トリガー" を使って、新しいデータまたはイベントの発生をリッスンし、ポーリングは行いません。 新しいデータが使用可能になった場合、またはイベントが発生した場合、これらのトリガーではワークフローの新しいインスタンスを作成して実行します。 この新しいインスタンスから、入力として渡されたデータを使用できます。

たとえば、ファイルが FTP サーバーにアップロードされたときに何か処理を行うワークフローを構築したいとします。 ワークフローの最初のステップとして、ポーリング パターンに従う [ファイルの追加または変更時] という名前の FTP トリガーを使用できます。 その後、アップロード イベントを定期的にチェックするようにスケジュールを指定できます。

トリガーを使って、入力やその他の必要なデータをワークフローに渡し、後のアクションでそのデータを参照し、ワークフロー全体で使用することもできます。 たとえば、新しい電子メールを受け取ったときにワークフローを開始するために、 [新しい電子メールが届いたとき] という名前の Office 365 Outlook トリガーを使用するとします。 このトリガーは、新しい電子メールの内容に沿って、送信者、件名、本文、添付ファイルなどを渡すことができるように構成できます。 ワークフローでは、その後、他のアクションを使用してそれらの情報を処理できます。

アクション

"アクション" は、トリガーに従い、ワークフローで何らかのタスクを実行する操作です。 ワークフローでは、複数のアクションを使用できます。 たとえば、SQL データベース内の新しい顧客データを検出する SQL トリガーを使用してワークフローを開始するとします。 このトリガーに従って、ワークフローに、その顧客データを取得する SQL アクションを含めることができます。 この SQL アクションに続けて、ワークフローに、そのデータを処理する別のアクションを含めることができます。

コネクタのカテゴリ

Azure Logic Apps では、ほとんどのトリガーとアクションが "組み込み" バージョンまたは "マネージド コネクタ" バージョンのどちらかで使用できます。 両方のバージョンで使用できるトリガーとアクションは少数です。 使用できるバージョンは、マルチテナントの Azure Logic Apps で実行される従量課金ロジック アプリを作成するか、シングル テナントの Azure Logic Apps で実行する Standard ロジック アプリを作成するかによって異なります。

  • 組み込みコネクタは、Azure Logic Apps ランタイムでネイティブに実行されます。

  • マネージド コネクタは、Microsoft によってデプロイ、ホスト、および管理されます。 これらのコネクタにより、クラウドサービス、オンプレミス システム、またはその両方に対してトリガーとアクションが提供されます。

    Standard ロジック アプリでは、すべてのマネージド コネクタが Azure コネクタとして編成されます。 ただし、従量課金ロジック アプリでは、マネージド コネクタは価格レベルに基づいて Standard または Enterprise として編成されます。

ロジック アプリの種類の詳細については、リソースの種類とホスト環境の違いに関するセクションを参照してください。

接続の構成

従量課金ロジック アプリでは、ロジック アプリとその接続を作成または管理する前に、特定のアクセス許可が必要です。 これらのアクセス許可の詳細については、セキュリティで保護された操作 - Azure Logic Apps でのアクセスとデータのセキュリティ保護に関するページを参照してください。

ワークフローでマネージド コネクタのトリガーまたはアクションを使用するには、多くのコネクタので、まずターゲット サービスまたはシステムへの接続を作成しておく必要があります。 ロジック アプリ ワークフロー デザイナー内で接続を作成するには、アカウントの資格情報、および場合によっては他の接続情報を使用してご自分の ID を認証する必要があります。 たとえば、ワークフローで Office 365 Outlook 電子メール アカウントにアクセスしてそれを操作するには、そのアカウントへの接続を認可しておく必要があります。 一部の組み込みコネクタとマネージド コネクタの場合は、認証情報を提供する代わりに、マネージド ID を設定して認証に使用することができます。

ワークフロー内から接続を作成しますが、実際にはそれらの接続は独自のリソース定義を持つ個別の Azure リソースです。 これらの接続リソース定義を確認するには、従量課金ロジック アプリと Standard ロジック アプリのどちらを使用しているかに基づいて、次の手順に従います。

接続のセキュリティと暗号化

サーバー アドレス、ユーザー名、パスワード、資格情報、シークレットなどの接続構成の詳細は暗号化され、セキュリティで保護された Azure 環境に格納されます。 この情報は、ロジック アプリ リソースでのみ使用することができ、リンクされたアクセス確認を使用して適用される接続リソースに対するアクセス許可を持つクライアントによってのみ使用できます。 Office 365、Salesforce、GitHub など、Azure Active Directory Open Authentication (Azure AD OAuth) を使用する接続では、サインインが必要ですが、Azure Logic Apps ではアクセス トークンと更新トークンだけがシークレットとして格納され、サインイン資格情報は格納されません。

サービスまたはシステムが許可する限り、確立された接続から、対象のサービスまたはシステムにアクセスできます。 Office 365 や Dynamics など、Azure AD OAuth 接続を使用するサービスについては、アクセス トークンは Azure Logic Apps によって無制限に更新されます。 その他のサービスでは、Logic Apps が更新なしでトークンを使用できる期間が制限されることがあります。 一部のアクション (パスワードの変更など) では、すべてのアクセス トークンが無効になります。

ヒント

組織が Azure Logic Apps のコネクタを介して特定のリソースにアクセスすることを許可していない場合は、Azure Policy を使用して、そのような接続を作成する機能をブロックすることができます。

ロジック アプリと接続をセキュリティで保護する方法の詳細については、「Azure Logic Apps におけるアクセスとデータのセキュリティ保護」を参照してください。

接続のためのファイアウォール アクセス

トラフィックを制限するファイアウォールを使用しており、かつロジック アプリ ワークフローがそのファイアウォール経由で通信する必要がある場合は、そのロジック アプリ ワークフローが存在する Azure リージョン内の Azure Logic Apps プラットフォームまたはランタイムによって使用される受信 IP アドレスと送信 IP アドレスの両方のアクセスを許可するようにファイアウォールを設定する必要があります。 また、ワークフローでマネージド コネクタ (Office 365 Outlook コネクタや SQL コネクタなど) を使用する場合や、カスタム コネクタを使用する場合は、ファイアウォールで、ロジック アプリの Azure リージョン内の "すべての" マネージド コネクタ送信 IP アドレスのアクセスも許可する必要があります。 詳細については、ファイアウォールの構成に関するページを確認してください。

繰り返しの動作

繰り返しの組み込みトリガー (繰り返しトリガーなど) は、Azure Logic Apps ランタイムでネイティブに実行され、最初に接続を作成する必要がある繰り返しの接続ベースのトリガー (Office 365 Outlook コネクタ トリガーなど) とは異なります。

どちらの種類のトリガーでも、特定の開始日時が繰り返しに指定されていない場合は、トリガーの繰り返し設定にかかわらず、ロジック アプリを保存またはデプロイすると、直ちに最初の繰り返しが実行されます。 この動作を回避するには、最初の繰り返しを実行する開始日時を指定してください。

一部のマネージド コネクタでは、繰り返しベースのトリガーと Webhook ベースのトリガーの両方があります。そのため、繰り返しベースのトリガーを使用する場合は、繰り返しの動作の概要を確認してください。

組み込みトリガーの繰り返し

繰り返しの組み込みトリガーでは、指定されたタイム ゾーンを含め、設定したスケジュールに従います。 ただし、将来の繰り返しを実行する特定時刻など、その他の詳細なスケジュール オプションが繰り返しに指定されていない場合は、それらの繰り返しは最後のトリガー実行に基づいて行われます。 その結果、ストレージ呼び出し中の待機時間などの要因によって、それらの繰り返しの開始時刻がずれる可能性があります。

詳細については、次のドキュメントを確認してください。

接続ベース トリガーの繰り返し

Office 365 Outlook など、繰り返しの接続ベースのトリガーでは、実行を制御するドライバーはスケジュールだけではありません。 タイム ゾーンにより、最初の開始時刻のみが決定されます。 後続の実行は、繰り返しのスケジュール、最後のトリガーの実行、"および" 実行時間の移動や予期しない動作を引き起こす可能性があるその他の要因によって決まります。次に例を示します。

  • より多くのデータがあるサーバーにトリガーがアクセスするかどうか。これは、トリガーによってすぐに取り込みが試行されます。
  • トリガーによって発生するエラーまたは再試行。
  • ストレージ呼び出し中の待機時間。
  • 夏時間 (DST) の開始および終了時に、指定されたスケジュールが維持されない。
  • 次回の実行時刻の発生に影響を与える可能性があるその他の要因。

詳細については、次のドキュメントを確認してください。

繰り返しの問題をトラブルシューティングする

ワークフローが指定した開始時刻に確実に実行され、特に頻度が数日以上の期間である場合、繰り返しが決して見逃されないようにするには、次のソリューションを試してください。

  • DST が有効になったときに、ワークフローが引き続き予定時刻に実行されるように、繰り返しを手動で調整します。 そうしないと、開始時刻が DST の開始時には 1 時間先に、DST の終了時には 1 時間前にシフトされます。 詳細および例については、「夏時間と標準時間での繰り返し」を確認してください。

  • 繰り返しトリガーを使用している場合は、タイム ゾーン、開始日、開始時刻を指定します。 また、 [設定時刻 (時間)] および [設定時刻 (分)] プロパティ ( [日][週] の頻度でのみ使用可能) で、後続の繰り返しを実行する特定の時刻を構成します。 ただし、一部の時間枠では、時間がシフトするときに引き続き問題が発生することがあります。

  • 繰り返しが必ず行われるように、繰り返しトリガーの代わりにスライディング ウィンドウ トリガーを使用することを検討してください。

カスタム コネクタと API

マルチテナント Azure Logic Apps で実行される従量課金ロジック アプリでは、既定のコネクタとして使用できない Swagger ベースまたは SOAP ベースの API を呼び出すことができます。 カスタム API アプリを作成してカスタム コードを実行することもできます。 詳細については、次のドキュメントを確認してください。

シングルテナント Azure Logic Apps で実行される Standard ロジック アプリでは、任意の Standard ロジック アプリで使用できるネイティブ実行のサービス プロバイダー ベースのカスタム組み込みコネクタを作成できます。 詳細については、次のドキュメントを確認してください。

ISE とコネクタ

Azure 仮想ネットワーク内のリソースに直接アクセスする必要があるワークフローの場合は、専用のリソースでワークフローをビルド、デプロイ、および実行できる、専用の統合サービス環境 (ISE) を作成できます。 ISE の作成の詳細については、Azure Logic Apps から Azure 仮想ネットワークへの接続に関するページを確認してください。

ISE 内で作成されたカスタム コネクタは、オンプレミス データ ゲートウェイでは動作しません。 ただし、これらのコネクタでは、ISE がホストされている Azure 仮想ネットワークに接続されているオンプレミス データ ソースに直接アクセスできます。 そのため、ISE 内のロジック アプリでは、ほとんどの場合、それらのリソースと通信するときにデータ ゲートウェイは不要です。 ISE の外部で作成したカスタム コネクタがあり、オンプレミス データ ゲートウェイを必要とする場合、ISE 内のロジック アプリから、それらのコネクタを使用できます。

ワークフロー デザイナーでは、組み込みコネクタまたは ISE でロジック アプリに使用するマネージド コネクタを参照すると、組み込みコネクタでは CORE ラベルが表示されるに対して、ISE で動作するように設計されたマネージド コネクタでは ISE ラベルが表示されます。

CORE コネクタの例

CORE

このラベルが付いた組み込みコネクタは、ロジック アプリと同じ ISE 内で動作します。

ISE コネクタの例

ISE

このラベルが付いたマネージド コネクタは、ロジック アプリと同じ ISE 内で動作します。

Azure 仮想ネットワークに接続されているオンプレミス システムがある場合は、ISE により、ワークフローはオンプレミス データ ゲートウェイを使用しなくても、そのシステムに直接アクセスできます。 代わりに、そのシステムの ISE コネクタ (使用可能な場合)、HTTP アクション、またはカスタム コネクタを使用できます。

ISE コネクタのないオンプレミス システムの場合は、オンプレミス データ ゲートウェイを使用します。 使用できる ISE コネクタを見つけるには、ISE コネクタを確認してください。

ISE 以外のコネクタの例

ラベルなし

ラベルのないその他のすべてのコネクタ (これも引き続き使用できます) の場合は、グローバルなマルチテナント Logic Apps サービスで実行します。

既知の問題

次の表には、Logic Apps コネクタに関する既知の問題が含まれています。

エラー メッセージ 説明 解決方法
Error: BadGateway. Client request id: '{GUID}' このエラーは、 1 つ以上の接続で SFTP や SQL などの Azure Active Directory (Azure AD) OAuth 認証がサポートされていないロジック アプリでタグを更新した場合に発生し、それらの接続が切断されます。 この動作を回避するには、それらのタグを更新しないようにします。

次のステップ