トリガーを使用して外部イベントを検出する
Azure Logic Apps 内のトリガーは常に最初のステップとしてワークフローを開始します。 ワークフローを正しく実行するには、最適なトリガーを見つけ、シナリオに合わせてトリガーのプロパティを設定する必要があります。 この例では、自社の製品名を含むツイートが投稿されたときにワークフローを実行する Twitter トリガーを使用します。
このユニットでは、トリガーの種類と、最も一般的なオプションに関する長所と短所を確認します。 さらに、Azure portal を使用してロジック アプリ ワークフローを作成する方法と、ワークフロー デザイナーでトリガーを追加する方法を説明します。
トリガーの種類
企業がロジック アプリ ワークフローを実行するために使用する可能性がある、さまざまなトリガー条件について考えてみましょう。 これまで見てきたほとんどの例は、サービスまたはシステム内のデータまたはイベントが特定の条件を満たしているかどうかを検出するトリガーです。 たとえば、新しいツイートが投稿される、データベースに新しい行が挿入される、新しい電子メールが着信する、またはクラウド ストレージに新しいファイルがアップロードされるなどの場合です。 データまたはイベントを検出するトリガーには、次のいずれかの手法を使用できます。
- 条件を満たす特定のデータまたはイベントの有無をサービスまたはシステムに対して定期的に "ポーリング" またはチェックするトリガー
- 特定のデータまたはイベントが条件を満たしたときの、サービスまたはシステムからの "プッシュ" 通知を待機し、受信するトリガー
ただし、サービスまたはシステム内のデータやイベントにバインドされていないトリガーが必要な場合は、どうしたらよいでしょうか。 毎週土曜日の午前 0 時またはその他のスケジュールでワークフローを実行するとします。 繰り返しトリガーを使用して、ワークフロー内に任意のアクションをスケジュールして実行できます。 たとえば、バックアップの実行や古いデータのアーカイブなどの管理タスクを実行するワークフローをスケジュールできます。 コードまたは別のソースから呼び出された場合にのみワークフローを実行するとします。 要求または "手動" トリガーを使用して、Web アプリやモバイル アプリのコードから送信される要求を待機できます。
次の図は、前述のトリガーの種類をまとめたものです。
以下のセクションでは、ポーリング トリガーとプッシュ トリガーについて詳しく説明します。
ポーリング トリガーとは
"ポーリング" トリガーは、サービスまたはシステムで、特定の条件を満たすデータまたはイベントの有無を定期的にチェックします。 このチェックの後、データまたは条件を満たすイベントがトリガーによって検出された場合、トリガーによってワークフローの実行が新たに開始されます。 たとえば、RSS コネクタには、RSS フィード内の新しい投稿の有無を定期的にチェックできるポーリング トリガーがあります。
ワークフローにポーリング トリガーを追加した後、[頻度] と [間隔] を設定して、トリガーの実行頻度を制御します。 頻度は、[秒]、[分]、[時間]、[日]、[週]、[月] などの時間単位です。 間隔は、トリガーによってデータまたはイベントの有無が再びチェックされるまでに経過する時間単位数です。 たとえば、頻度が "分" で間隔が 5 に指定されたポーリング トリガーの場合、5 分ごとにチェックが実行されます。
ポーリング トリガーの場合、トリガーの実行頻度とかかるコストの関係を踏まえて選択することが必要です。 多くの場合、新しいデータまたはイベントが発生してから、そのデータまたはイベントがトリガーによって検出されるまでに遅延が発生します。 たとえば、ポーリング トリガーで 5 分ごとにデータをチェックするとします。 7 分後に新しいデータが使用できるようになります。 新しいデータは、10 分後に行われる次のポーリングまで、トリガーによって検出されることはありません。 次の図は、このポーリングのしくみを示しています。
最悪の場合、新しいデータを検出するときの潜在的な遅延は、ポーリング間隔と同じになります。 それにもかかわらず、なぜより短い間隔を使用しないのでしょうか。 新しいデータの有無をチェックするには、Azure Logic Apps の実行エンジンでワークフローを実行する必要があり、それにはコストがかかります。 一般に、間隔が短いほどコストは高くなりますが、新しいデータまたはイベントに対するトリガーの反応が速くなります。 自分のトリガーに最適なポーリング間隔は、ビジネス プロセスと遅延に対する許容度によって異なります。
プッシュ トリガーとは
"プッシュ" トリガーは、データまたはイベントが特定の条件を満たしたときの、サービスまたはシステムからの通知を待機します。 このトリガーは、外部サービスまたはシステム上のエンドポイントにサブスクライブされます。 新しいデータまたはイベントが条件を満たすと、サービスまたはシステムからトリガーに通知されます。これにより、直ちにワークフローの実行が新たに開始されます。 たとえば、Azure Service Bus コネクタには、メッセージが Azure Service Bus のキューに追加されたときに検出するプッシュ トリガーがあります。
Note
プッシュ トリガーには Webhook が使用されます。これにより、外部サービスまたはシステムへのトリガーのサブスクライブができます。 サブスクリプション時に、Azure Logic Apps によってトリガーのコールバック URL が生成され、その URL が外部サービスまたはシステムに登録されます。 同様に、ワークフローを無効にしたか削除した場合など、サブスクリプションが不要になったときは、Azure Logic Apps でコールバック URL のサブスクライブと登録が解除されます。
肯定的な面として、使用可能なデータやイベントがない場合、プッシュ トリガーは実行されません。 そのため、ポーリングのコストは発生しません。 また、これらのトリガーは、新しいデータまたはイベントが存在するときはすぐに反応します。 次の図は、このプッシュ プロセスのしくみを示しています。
プッシュ トリガーがポーリング トリガーよりも高速でコストが低いのなら、なぜ常にプッシュ トリガーを使用しないのでしょうか。 残念ながら、プッシュ トリガーはすべてのコネクタで提供されているとは限りません。 外部サービスでプッシュ トリガーがサポートされていない場合や、コネクタ作成者がプッシュ トリガーを実装することを選ばなかった場合があります。 一般に、コネクタで提供されるのはプッシュ トリガーまたはポーリング トリガーのいずれかであり、両方ではありません。 まれに、コネクタで両方のオプションが提供されている場合は、より効率的という理由でプッシュ トリガーの使用を検討してください。
このモジュールでは、ポーリング トリガーを中心に説明していきます。 これらのトリガーは、最も一般的で、説明してきた "データのルーティングと処理" のシナリオに最適です。
トリガーのパラメーターと戻り値
トリガーの操作は、"パラメーター" と "戻り値" を持つ関数呼び出しと考えることができます。 トリガーの "パラメーター" を使用すると、操作を構成することができます。 新しいツイートが投稿されたらという名前の Twitter トリガーには、[検索テキスト] というパラメーターがあります。 このパラメーターをトリガーで使用して、一致するツイートを選択できます。 一部の操作には、必須と省略可能の両方のパラメーターを使用します。 項目が作成されたときという名前の SQL Server トリガーには、[テーブル名] という名前の必須パラメーターが 1 つと、[並べ替え順] や [クエリの選択] などの複数の省略可能なパラメーターがあります。
トリガーの戻り値は、操作の結果です。 たとえば、Bitbucket コネクタには、pull request がマージされたときという名前のトリガーがあります。 このトリガーからは、リポジトリ ID やマージを承認したアクターなどのデータを含むオブジェクトが返されます。 実際には、ほとんどのトリガーから返されるのは 1 つのオブジェクトではなく、オブジェクト コレクションです。 たとえば、新しいツイートが投稿されたときという名前の Twitter トリガーによって、TweetModel オブジェクトの配列が返されます。 各オブジェクトには、ツイート テキスト、ユーザー名、フォロワー数などの値が含まれています。 次の図は、トリガーから返されるコレクションを示しています。
ループを使用して各項目を処理することも、配列を処理するために分割するようにトリガーを設定することもできます。 Twitter トリガーを含むほとんどのトリガーでは、既定の動作によって配列が自動的に分割されます。 Azure Logic Apps のエンジンによって、各データ項目に対してワークフローのインスタンスが 1 つ作成されます。すべてのインスタンスは並列で実行されます。 次の図は、返された配列内の各項目を処理のために別々のワークフロー インスタンスに送る方法を示しています。
Azure portal でロジック アプリ ワークフローを作成する
Azure portal で、ロジック アプリのリソースの種類を見つけて選択し、リソースに関する情報 ([名前]、[サブスクリプション]、[リソース グループ]、[場所] など) を指定します。 デプロイが完了したら、ロジック アプリ リソースに移動できます。
新しいロジック アプリ リソースを開くと、[作業の開始] ページが表示されます。 このページには、一般的に使用されるトリガーと、一般的なワークフロー パターンとアプリの種類を含む "テンプレート" ギャラリーが含まれています。 たとえば、新しいツイートがハッシュタグと一致する場合に Slack に投稿するや毎日の通知を電子メールで送信されるようにするなどのワークフロー テンプレートがあります。
[作業の開始] ページでは、ワークフローに追加する一般的なトリガーを選ぶことも、完全なワークフローを生成するためのテンプレートを選ぶこともできます。 いずれかのテンプレートが自分のシナリオに適合する場合は、アプリの設定にかかる時間を節約できます。 すべての作業を自分で行うには、空のロジック アプリ テンプレートを選びます。
テンプレートを選ぶと、ワークフロー デザイナーが自動的に開きます。
デザイナーを使用してトリガーを追加する
ワークフロー デザイナーには、ワークフローで使用できるトリガーとアクションを含むコネクタ ギャラリーが表示されます。 通常、空のワークフローから始めるときは、検索ボックスを使用して必要なコネクタを見つけます。 次に、コネクタによって提供されるトリガーを確認します。 この例では、新しいツイートが投稿されたらという名前の Twitter トリガーを選びます。 Twitter の場合は、Twitter アカウントにサインインして接続を作成する必要もあります。
トリガーを追加し、必要に応じてサービスまたはシステムへの接続を作成すると、デザイナーにトリガーのプロパティが表示されます。 Twitter の場合、[検索テキスト]、[頻度]、[間隔] の各パラメーターを設定します。 次のスクリーンショットは、デザイナーに表示されたソーシャル メディア監視ロジック アプリのワークフローです。Twitter のトリガーが最初のステップとして表示されています。
