Azure Logic Apps ワークフローで繰り返し実行されるトリガーのスケジュール

適用対象: Azure Logic Apps (従量課金 + Standard)

Azure Logic Apps は、自動化された定期的なワークフローを作成し、スケジュールに従って実行するのに役立ちます。 繰り返しトリガーまたはスライディング ウィンドウ トリガー (スケジュール タイプのトリガー) で始まるロジック アプリ ワークフローを作成することによって、直ちに、後で、または定期的な間隔でタスクを実行できます。 Azure の内部および外部のサービス (HTTP または HTTPS エンドポイントなど) を呼び出したり、Azure Storage や Azure Service Bus などの Azure サービスにメッセージを投稿したり、ファイル共有にアップロードされたファイルを取得したりできます。 繰り返しトリガーを使うと、タスクの実行に対して複雑なスケジュールと高度な繰り返しを設定することもできます。 スケジュール組み込みトリガーおよびアクションの詳細については、「スケジュール トリガー」および「スケジュールのアクション」を参照してください。

次の一覧には、スケジュール組み込みトリガーで実行できるタスクのいくつかの例が示されています。

• 内部データを取得する。毎日 SQL ストアド プロシージャを実行する、など。

• 外部データを取得する。15 分ごとに NOAA から天気予報を取り込む、など。

• レポート データを送信する。過去 1 週間について特定の金額を超えるすべての注文の概要をメールする、など。

• データを処理する。平日に毎日、ピーク時間帯を避けて、その日にアップロードした画像を圧縮する、など。

• データをクリーンアップする。3 か月より前のツイートをすべて削除する、など。

• データをアーカイブする。毎日午前 1 時 00 分に、今後 9 か月間保管する請求書をバックアップ サービスにプッシュする、など。

また、スケジュール組み込みアクションを使って、次のアクションが実行される前にワークフローを一時停止することもできます。次はその例です。

• 電子メールで状態の更新情報を送信するのを平日まで待つ。

• HTTP 呼び出しが終了するまでワークフローを遅らせてから、再開して結果を取得する。

このガイドでは、スケジュール型の組み込みトリガーとアクションの機能について説明します。

複数のロジック アプリを作成せずに定期的なワークロードを実行する

スケジュールされたジョブごとに個別の従量課金ロジック アプリを作成したり、リージョンおよびサブスクリプションあたりのワークフロー数に関する制限に達したりすることなく、繰り返しのワークロードをスケジュールして実行できます。 代わりに、複数のワークフローを使用して Standard ロジック アプリを作成、または Azure クイック スタート テンプレート: Logic Apps ジョブ スケジューラによって作成された従量課金ロジック アプリ パターンを使用できます。

Azure Logic Apps ジョブ スケジューラ テンプレートは、TimerJob ロジック アプリを呼び出す CreateTimerJob という名前のロジック アプリを作成します。 その後、HTTP 要求を作成し、その要求の入力としてスケジュールを渡すことによって、CreateTimerJob ロジック アプリを API として呼び出すことができます。 CreateTimerJob ロジック アプリを呼び出すたびに、TimerJob ロジック アプリも呼び出されます。これにより、指定されたスケジュールに基づいて、または指定された制限を満たすまで継続的に実行される新しい TimerJob インスタンスが作成されます。 それにより、インスタンスが個々のロジック アプリ ワークフロー定義またはリソースではなくなるため、ワークフローの制限を気にすることなく、TimerJob インスタンスを必要な数だけ実行できます。

スケジュール トリガー

特定のどのサービスまたはシステムにも関連していない繰り返しトリガーまたはスライディング ウィンドウ トリガーを使用してロジック アプリ ワークフローを開始できます。 これらのトリガーでは、指定された繰り返しに基づいてワークフローが開始されて実行されます。その間隔と頻度を選択する場合、秒数、分数、時間数、日数、週数、または月数を使用できます。 また、開始日時をタイム ゾーンと共に設定することもできます。 トリガーが起動されるたびに、Azure Logic Apps は、ロジック アプリの新しいワークフロー インスタンスを作成して実行します。

これらのトリガーの違いを以下に示します。

• 繰り返し: 指定されたスケジュールに基づいて、一定の間隔でワークフローが実行されます。 中断やワークフローの無効化などが原因でトリガーで繰り返しが実行されなかった場合、その実行されなかった繰り返しは繰り返しトリガーによって処理されず、スケジュールされている次の間隔によって繰り返しが再開されます。

  頻度として [日] を選択した場合は、時間と分を指定できます (毎日 2:30 など)。 頻度として [週] を選択した場合は、曜日も選択できます (水曜日と土曜日など)。 また、開始日時を、繰り返しスケジュールのタイムゾーンと共に指定することもできます。 タイムゾーンの書式設定の詳細については、繰り返しトリガーの追加に関する記事を参照してください。

  重要

  頻度として [日]、[週]、または [月] を使用し、将来の日付と時刻を指定する場合、次のように事前に繰り返しを設定するようにしてください。

  • [日]: 事前に少なくとも 24 時間の日単位の繰り返しを設定します。

  • [週]: 事前に少なくとも 7 日間の週単位の繰り返しを設定します。

  • [月]: 少なくとも 1 か月前に毎月の繰り返しを設定します。

  そうしないと、ワークフローで最初の繰り返しがスキップされる場合があります。

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

  将来の繰り返しを実行する特定時刻など、その他の詳細なスケジュール オプションが繰り返しに指定されていない場合、それらの繰り返しは前回の実行時刻に基づいて行われます。 その結果、ストレージ呼び出し中の待機時間などの要因によって、それらの繰り返しの開始時刻がずれる可能性があります。 ワークフローで繰り返しが行われないことがないようにするには (特に頻度が日単位以上のとき)、次のいずれかのオプションを試してください。

  • [設定時刻 (時間)] と [設定時刻 (分)] という名前のプロパティ ( [日] と [週] の頻度でのみ使用可能) を使用して、繰り返しの開始日時と後続の繰り返しを実行する特定の時刻を指定します。

  • 繰り返しトリガーではなく、スライディング ウィンドウ トリガーを使用します。

  詳しくは、繰り返しトリガーで繰り返されるタスクとワークフローを作成、スケジュール設定、実行する方法に関する記事をご覧ください。

• スライディング ウィンドウ: 一定の間隔でワークフローが実行され、データは連続したチャンクで処理されします。 中断または無効になったワークフローなどが原因でトリガーで繰り返しが行われなかった場合は、スライディング ウィンドウ トリガーが前に戻って、実行されなかった繰り返しを処理します。

  開始日時、タイム ゾーン、およびワークフローで各繰り返しを遅延する期間を指定できます。 このトリガーでは、1 日の特定の時間帯、1 時間の特定の分、週の特定の曜日などの詳細スケジュールはサポートされていません。 詳しくは、「Create, schedule, and run recurring tasks and workflows with the Sliding Window trigger」(スライディング ウィンドウ トリガーで繰り返されるタスクとワークフローを作成、スケジュール設定、実行する) をご覧ください。

スケジュールのアクション

ロジック アプリ ワークフローでの任意のアクションの後、遅延アクションと延期期限アクションを使って、次のアクションを実行する前にワークフローに待機させることができます。

• [遅延] : 指定した時間単位数 (秒、分、時間、日、週、月など) だけ、次のアクションの実行を延期します。 詳しくは、ワークフローの次のアクションの遅延に関する記事をご覧ください。

• [延期期限] : 指定した日時まで、次のアクションの実行を延期します。 詳しくは、ワークフローの次のアクションの遅延に関する記事をご覧ください。

開始日時のパターン

開始日時で繰り返しを制御する方法と、これらの繰り返しが Azure Logic Apps によって実行される方法を示すいくつかのパターンを次に示します。

開始時刻が過去、繰り返しあり、スケジュールなしの例

現在の日時が、2017 年 9 月 8 日午後 1:00 であるとします。 2017 年 9 月 7 日午後 2:00 (これは過去の時刻です) の開始日時と、2 日ごとに実行される繰り返しを指定します。

繰り返しトリガーの場合、Azure Logic Apps エンジンでは、開始時刻に基づいて実行時刻が計算されます。過去の実行時刻は放棄され、最初の実行には次に訪れる将来の開始時刻が使われて、最後の実行時刻に基づいて将来の実行が計算されます。

この繰り返しは次のようになります。

したがって、開始時刻としてどれだけ古い日付 (2017-09-05 の 2:00 PM や 2017-09-01 の 2:00 PM など) を指定したとしても、最初の実行には常に次の将来の開始時刻が使われます。

スライディング ウィンドウ トリガーの場合、Logic Apps エンジンでは、開始時刻に基づいて実行時刻が計算されます。過去の実行時刻が考慮され、最初の実行には開始時刻が使われて、開始時刻に基づいて将来の実行が計算されます。

この繰り返しは次のようになります。

したがって、開始時刻としてどれだけ古い日付 (2017-09-05 の 2:00 PM や 2017-09-01 の 2:00 PM など) を指定したとしても、最初の実行には指定した開始時刻が使われます。

繰り返しの動作

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

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

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

繰り返しの組み込みトリガーでは、指定されたタイム ゾーンを含め、設定したスケジュールに従います。 ただし、将来の繰り返しを実行する特定時刻など、その他の詳細なスケジュール オプションが繰り返しに指定されていない場合は、それらの繰り返しは最後のトリガー実行に基づいて行われます。 その結果、ストレージ呼び出し中の待機時間などの要因によって、それらの繰り返しの開始時刻がずれる可能性があります。 [週単位] の繰り返しに対する [設定時刻 (時間)] や [設定時刻 (日)] などの高度なスケジュール オプションは、Azure Logic Apps ランタイムで直接ネイティブに実行される繰り返しやスライディング ウィンドウ トリガーなどの組み込みのポーリング トリガーでのみ使用できます。

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

• 夏時間と標準時間での繰り返しのトリガー
• 繰り返しの問題をトラブルシューティングする

マネージド トリガーの繰り返し

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

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

[週単位] の繰り返しに対する [設定時刻 (時間)] や [設定時刻 (日)] などの高度なスケジュール オプションは、Microsoft が管理し、ホストし、Azure で実行するコネクタでは使用できません。または、サポートされていません。 これらのポーリング トリガーは、[間隔] と [頻度] の値のみを使用して、次の繰り返しを計算します。

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

• 夏時間と標準時間での繰り返しのトリガー
• 夏時間と標準時間の間でのトリガーの繰り返しシフトとドリフトのトリガー
• 繰り返しの問題をトラブルシューティングする

夏時間と標準時間での繰り返しのトリガー

Azure Logic Apps では、ジョブをスケジュールするために、処理するメッセージをキューに入れ、最後のジョブが実行された UTC 時刻と、次のジョブの実行がスケジュールされている UTC 時刻に基づいて、そのメッセージが使用可能になる時刻を指定します。 繰り返しにおいて開始時刻を指定する場合は、"タイム ゾーンを選択" して、指定した開始時刻にロジック アプリ ワークフローが実行されるようにしてください。 そうすることで、ロジック アプリの UTC 時刻も、季節の時間変化に合わせてシフトされます。 繰り返しのトリガーは、指定したタイム ゾーンを含め、設定したスケジュールに従います。

タイムゾーンを選択しない場合、トリガーが実行されるタイミングが夏時間 (DST) イベントの影響を受ける可能性があります。 たとえば、開始時刻が DST の開始時には 1 時間先に、DST の終了時には 1 時間前にシフトされます。

夏時間と標準時間の間でのトリガーの繰り返しシフトとドリフトのトリガー

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

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

DST が有効になったときに繰り返し時刻がシフトされないようにするには、繰り返しを手動で調整します。 このようにすると、ワークフローは引き続き予期された、または指定された開始時刻に実行されます。 そうしないと、開始時刻が DST の開始時には 1 時間先に、DST の終了時には 1 時間前にシフトされます。

たとえば、毎日実行される 2 つのロジック アプリがあるとします。 1 つのロジック アプリは 1:30 AM (ローカル時刻) に実行され、もう 1 つのロジック アプリは 2:30 AM (ローカル時刻) に実行されます。 DST が開始されたとき、および終了したときに、これらのアプリの開始時刻はどうなるでしょうか。

• 時間が 1 時間進められると、トリガーは実行されるでしょうか。

• 時間が 1 時間戻されると、トリガーは 2 回実行されるのでしょうか。

これらのロジック アプリで UTC-6:00 中部標準時 (米国とカナダ) のゾーンが使用されている場合、このシミュレーションでは、DST の変化に対応するために、UTC 時刻が 2019 年にどのように変化したかを示します。実行がスキップされたり重複して実行されたりすることなく、アプリが継続して想定されたローカル時刻に実行されるように、必要に応じて時間を 1 時間進めたり戻したりする変化です。

• 2019 年 3 月 10 日:DST が 2:00 AM に開始される。時間を 1 時間進める

  DST の開始後に時刻補正を行うために、UTC 時刻は 1 時間戻されます。これにより、ロジック アプリは引き続き同じローカル時刻に実行されます。

  • ロジック アプリ #1

    Date	時刻 (ローカル)	時刻 (UTC)	Notes
    2019 年 3 月 9 日	1:30:00 AM	7:30:00 AM	DST が有効になる日より前の UTC。
    2019 年 3 月 10 日	1:30:00 AM	7:30:00 AM	DST が有効になっていないため、UTC は同じです。
    2019 年 3 月 11 日	1:30:00 AM	6:30:00 AM	DST が有効になった後、UTC は 1 時間戻されます。

  • ロジック アプリ #2

    Date	時刻 (ローカル)	時刻 (UTC)	Notes
    2019 年 3 月 9 日	2:30:00 AM	8:30:00 AM	DST が有効になる日より前の UTC。
    2019 年 3 月 10 日	3:30:00 AM*	8:30:00 AM	DST は既に有効になっています。UTC-6:00 のタイムゾーンが UTC-5:00 に変わっているため、ローカル時刻は 1 時間進んでいます。 詳細については、2:00 AM - 3:00 AM の間に開始されるトリガーに関する記事を参照してください。
    2019 年 3 月 11 日	2:30:00 AM	7:30:00 AM	DST が有効になった後、UTC は 1 時間戻されました。

• 2019 年 11 月 3 日: DST は 2:00 AM に終了し、時間が 1 時間戻される

  時刻補正を行うために、UTC 時刻は 1 時間進められます。これにより、ロジック アプリは引き続き同じローカル時刻に実行されます。

  • ロジック アプリ #1

    Date	時刻 (ローカル)	時刻 (UTC)	Notes
    2019 年 11 月 2 日	1:30:00 AM	6:30:00 AM
    2019 年 11 月 3 日	1:30:00 AM	6:30:00 AM
    2019 年 11 月 4 日	1:30:00 AM	7:30:00 AM

  • ロジック アプリ #2

    Date	時刻 (ローカル)	時刻 (UTC)	Notes
    2019 年 11 月 2 日	2:30:00 AM	7:30:00 AM
    2019 年 11 月 3 日	2:30:00 AM	8:30:00 AM
    2019 年 11 月 4 日	2:30:00 AM	8:30:00 AM

1 回だけ実行

ワークフローを今後 1 回だけ実行するには、 [Scheduler: ジョブを 1 回実行する] ワークフロー テンプレートを使用できます。

月の最終日に 1 回実行する

繰り返し トリガーを月の最終日に 1 回だけ実行するには、「月の最後の日に 1 回実行する」を参照してください。

繰り返しの例

次に、オプションをサポートするトリガーに対して設定できるさまざまな繰り返しの例を示します。

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

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

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

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

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

次のステップ

• 繰り返しトリガーを使用して繰り返しタスクおよびワークフローを作成、スケジュール設定、および実行する
• スライディング ウィンドウ トリガーを使用して繰り返されるタスクとワークフローを作成、スケジュール設定、実行する
• 遅延アクションを使用してワークフローを一時停止する