トリガーを使用して外部イベントを検出する

  • 8 分

Azure Logic Apps 内のトリガーは常に最初のステップとしてワークフローを開始します。 ワークフローを正常に実行するには、適切なトリガーを見つけ、シナリオに合わせてトリガーのプロパティを設定する必要があります。 この例では、Bing 検索トリガーを使用して、業界に関する記事が公開されたときにワークフローを実行します。

このユニットでは、トリガーの種類に加えて、最も一般的なオプションに関する長所と短所、およびトリガーが入力と出力をどのように処理するかを調べます。

トリガーの種類

企業がロジック アプリ ワークフローを実行するために使用する可能性がある、さまざまなトリガー条件について考えてみましょう。 これまで見てきたほとんどの例は、サービスまたはシステム内のデータまたはイベントが特定の条件を満たしているかどうかを検出するトリガーです。 たとえば、新しい記事が公開される、データベースに新しい行が追加される、新しいメールが届く、新しいファイルがクラウド ストレージにアップロードされるなどがあります。 データまたはイベントを検出するトリガーには、次のいずれかの手法を使用できます。

  • 条件を満たす特定のデータまたはイベントの有無をサービスまたはシステムに対して定期的に "ポーリング" またはチェックするトリガー

  • 特定のデータまたはイベントが条件を満たしたときの、サービスまたはシステムからの "プッシュ" 通知を待機し、受信するトリガー

ただし、サービスまたはシステム内のデータやイベントにバインドされていないトリガーが必要な場合は、どうしたらよいでしょうか。 毎週土曜日の午前 0 時またはその他のスケジュールでワークフローを実行するとします。 繰り返しトリガーを使用して、ワークフローのアクションを実行するタイミングをスケジュールできます。 たとえば、バックアップの実行や古いデータのアーカイブなどの管理タスクを実行するワークフローをスケジュールできます。

コードまたは別のソースから呼び出された場合にのみワークフローを実行するとします。 要求または "手動" トリガーを使用して、Web アプリやモバイル アプリのコードから送信される要求を待機できます。

次の図は、前述のトリガーの種類をまとめたものです。

図は、ポーリング、プッシュ、繰り返し、要求の 4 種類のトリガーを示しています。

以下のセクションでは、ポーリング トリガーとプッシュ トリガーについて詳しく説明します。

ポーリング トリガーとは

"ポーリング" トリガーは、サービスまたはシステムで、特定の条件を満たすデータまたはイベントの有無を定期的にチェックします。 このチェックの後、データまたは条件を満たすイベントがトリガーによって検出された場合、トリガーによってワークフローの実行が新たに開始されます。 たとえば、RSS コネクタには、RSS フィード内の新しい投稿の有無を定期的にチェックできるポーリング トリガーがあります。

ワークフローにポーリング トリガーを追加した後、[頻度] と [間隔] を設定して、トリガーの実行頻度を制御します。 頻度は、[秒]、[分]、[時間]、[日]、[週]、[月] などの時間単位です。 間隔は、トリガーによってデータまたはイベントの有無が再びチェックされるまでに経過する時間単位数です。 たとえば、頻度が "分" で間隔が 5 に指定されたポーリング トリガーの場合、5 分ごとにチェックが実行されます。

ポーリング トリガーの場合、トリガーの実行頻度と実行にかかるコストの関係を踏まえて選択することが必要です。 多くの場合、新しいデータまたはイベントが発生してから、そのデータまたはイベントがトリガーによって検出されるまでに遅延が発生します。 たとえば、ポーリング トリガーで 5 分ごとにデータをチェックするとします。 7 分後に新しいデータが使用できるようになります。 新しいデータは、10 分後に行われる次のポーリングまで、トリガーによって検出されることはありません。 次の図は、このポーリングのしくみを示しています。

この図には、タイムラインと共に、5 分ごとに新しいデータの有無をチェックするポーリング トリガーが示されています。7 分後に新しいデータが使用可能になっています。新しいデータは、10 分後に行われる次のポーリングまで、トリガーによって検出されることはありません。

最悪の場合、新しいデータを検出するときの潜在的な遅延は、ポーリング間隔と同じになります。 それにもかかわらず、なぜより短い間隔を使用しないのでしょうか。 新しいデータの有無をチェックするには、Azure Logic Apps の実行エンジンでワークフローを実行する必要があり、それにはコストがかかります。 一般に、間隔が短いほどコストは高くなりますが、新しいデータまたはイベントに対するトリガーの反応が速くなります。 自分のトリガーに最適なポーリング間隔は、ビジネス プロセスと遅延に対する許容度によって異なります。

プッシュ トリガーとは

"プッシュ" トリガーは、データまたはイベントが特定の条件を満たしたときの、サービスまたはシステムからの通知を待機します。 このトリガーは、他のサービスまたはシステム上のエンドポイントにサブスクライブされます。 新しいデータまたはイベントが条件を満たすと、サービスまたはシステムからトリガーに通知されます。これにより、直ちに新しいワークフローの実行が開始されます。 たとえば、Azure Service Bus コネクタには、メッセージが Azure Service Bus のキューに追加されたときに検出するプッシュ トリガーがあります。

注

プッシュ トリガーには "Webhook" が使用されます。これにより、外部サービスまたはシステムにトリガーがサブスクライブされます。 サブスクリプション時に、Azure Logic Apps によってトリガーのコールバック URL が生成され、その URL が外部サービスまたはシステムに登録されます。 同様に、ワークフローを無効にしたか削除した場合など、サブスクリプションが不要になったときは、Azure Logic Apps でコールバック URL のサブスクライブと登録が解除されます。

肯定的な面として、使用可能なデータやイベントがない場合、プッシュ トリガーは実行されません。 そのため、ポーリングほどのコストは発生しません。 また、これらのトリガーは、新しいデータまたはイベントが存在するときはすぐに反応します。 次の図は、このプッシュ プロセスのしくみを示しています。

この図には、新しいデータが使用可能になったことをマーカーで表したタイムラインが示されています。プッシュ トリガーはデータを検出し、直ちに反応します。

プッシュ トリガーがポーリング トリガーよりも高速でコストが低いのなら、なぜ常にプッシュ トリガーを使用しないのでしょうか。 残念ながら、プッシュ トリガーはすべてのコネクタで提供されているとは限りません。 サービスまたはシステムでプッシュ トリガーがサポートされていない場合や、コネクタ作成者がプッシュ トリガーを実装することを選ばなかった場合があります。 一般には、コネクタで提供されるのはポーリング トリガーまたはプッシュ トリガーのいずれかであり、両方ではありません。 まれに、コネクタで両方のオプションが提供されている場合は、効率とコストのメリットを考慮してプッシュ トリガーの使用を検討してください。

次のスクリーンショットは、ニュース監視ロジック アプリ ワークフローを含むデザイナーを示しています。Bing 検索トリガーが最初の手順として表示されています。

スクリーンショットは、デザイナー内のワークフロー例を示しています。操作を結ぶ矢印で、ワークフローを通じた実行を示しています。

トリガーのパラメーターと戻り値

トリガー操作は、パラメーター (入力) と戻り値 (出力) を持つ関数呼び出しと考えることができます。 トリガーの "パラメーター" を使用すると、操作を構成することができます。 新しいニュース記事という名前の Bing 検索トリガーに、検索クエリというパラメーターがあります。 トリガーでは、このパラメーターを使用して、検索語句に一致するニュース記事を検索します。 一部の操作には、必須と省略可能の両方のパラメーターを使用します。 項目が作成されたときという名前の SQL Server トリガーには、[テーブル名] という名前の必須パラメーターが 1 つと、[並べ替え順] や [クエリの選択] などの複数の省略可能なパラメーターがあります。

トリガーの戻り値は、トリガー操作の結果または出力です。 たとえば、新しいニュース記事という Bing 検索トリガーは、NewsArticle オブジェクトを返します。 このオブジェクトには、Name、URL、Description などの値が含まれます。 Bitbucket コネクタには、pull request がマージされたときという名前のトリガーがあります。 このトリガーからは、リポジトリ ID やマージを承認したアクターなどのデータを含むオブジェクトが返されます。

一部のトリガーは、1 つの項目ではなく、配列またはコレクションを返します。 次の図は、この出力配列またはコレクションがどのように見えるかを示しています。

図は、サービスと連携するトリガーを示しています。トリガーはサービスに入力を送信し、サービスはオブジェクト配列を返します。

各項目を処理するには、For each または Until ループなどのループを使用できます。

一部のトリガーは、配列またはコレクションを入力として受け入れます。 既定では、ほとんどのトリガーは処理のために配列を自動的に分割します。 Azure Logic Apps エンジンは、配列全体を 1 つのワークフロー インスタンスで処理するのではなく、項目ごとに 1 つのワークフロー インスタンスを作成し、すべてのインスタンスを並列で実行します。

次の図は、フィード項目の公開時という名前の RSS トリガーが配列を分割し、処理のために各項目を個々のワークフロー インスタンスに送信する方法を示しています。

図は、トリガーから返された 3 つのオブジェクトと、ロジック アプリ内の 3 つのワークフロー インスタンスを示しています。配列内の各オブジェクトとロジック アプリの各ワークフロー インスタンスが矢印で結ばれています。

デザイナーのトリガー

ワークフロー デザイナーには、ワークフローで使用できるトリガーとアクションを含むコネクタ ギャラリーがあります。 通常、コネクタ ギャラリーの検索ボックスを使用して、自分のシナリオに合ったコネクタを検索して選択します。 次に、コネクタによって提供されるトリガーを確認します。 次のスクリーンショットは、選択するコネクタがワークフロー デザイナーにどのように表示されるかを示しています。

スクリーンショットは、使用可能なコネクタを含むワークフロー デザイナーを示しています。

コネクタを選択すると、そのコネクタで使用できるトリガーが表示されます。

スクリーンショットは、ワークフロー デザイナーと、使用可能なトリガーがある選択済みのコネクタを示しています。

次のユニットでは、Azure portal でロジック アプリのリソースとワークフローを作成する方法と、ワークフロー デザイナーでトリガーを追加および構成する方法を示します。

コネクタ ギャラリーは、コネクタを次の一般的なカテゴリにグループ化します。

コネクタ グループ 説明
組み込み (アプリ内) Azure Logic Apps ランタイムでネイティブに実行されるトリガーとアクション。 一部の操作は、接続を作成しなくても、Azure Functions などの特定の Azure サービスと直接連携します。 その他の操作では、変数の操作、ワークフローを通じたパスの制御、一般的なデータ タスクの実行などのタスクが実行されます。
マネージド (共有) マルチテナント Azure で実行され、Microsoft によって管理されるトリガーとアクション。 通常、これらの操作は 1 つのサービスまたはシステムに関連付けられ、特定のサービスまたはシステムに対する呼び出しを受信または送信します。 通常、これらの操作では、最初に接続を作成する必要があります。