通知を受け取る

UiPath Orchestrator

UiPath Orchestrator ガイド

トリガーについて

トリガーを使用すると、事前に計画された方法で、定期的に (タイム トリガー)、または新しいアイテムがキューに追加されるたびに (キュー トリガー) ジョブを実行できます。

🚧

重要

トリガーの実行時間は、特定のタイム ゾーンに合わせて調整できます。スケジュールに設定されたタイムゾーンは、テナントのタイム ゾーン ([設定] ページで設定) とは関連がありません。

Attended のユース ケースではスケジューリングが不可能であり、モダン フォルダーは Attended ユース ケースでのみ機能するので、スケジューリングはクラシック フォルダーでのみ使用できます。

タイム トリガー

ジョブを開始するための繰り返し時間をスケジュールできます。 入力および出力パラメーターをサポートするプロセスでの入力値も、このレベルでも管理できます。ロボットが実行する関連プロセスに応じて、いくつかのルールを設定できます。

  1. All Robots - 特定の環境のすべてのロボットによりスケジュールが実行されます。
  2. Specific Robots - ユーザーが選択したロボットにより、スケジュールが実行されます。
  3. 動的に割り当て - 所定のスケジュールに従ってプロセスを実行する回数を定義します。このオプションにより、リソースを最大限活用できるようになります。ロボットが使用可能になると、設定されたスケジュールに従って対象のプロセスが実行されます。

特定のトリガーに関連付けられているジョブを表示するには、[その他のアクション] > [ジョブを表示] をクリックします。
To stop a triggered job after a custom amount of time, use the Stop or Kill options on the Add Trigger window > Actions tab.

📘

重要

何らかの理由で SQL データベースへの接続が失われた場合、その時点で発生されるはずのトリガーが失敗し、エラー レベルのアラートが生成されます。

キューに置かれたジョブがある場合

  1. 同じロボット上に複数のスケジュールを設定し、実行時間が少なくとも 1 度重複すると、ジョブのキューが保留ステートに置かれます。ロボットは、時間順でジョブを実行します。
  2. 同じプロセスが同じロボット上に複数回スケジュールされていて、それらの実行時間が重複している場合は、1 つのプロセスのみが保留中ステートでキューに入ります。たとえば、ロボット X 上のプロセス A が 11:20、11:21、および 11:25 で実行されるようにスケジュールされている場合、その動作は次のようになります。
    • 11:20 に最初のプロセスが実行されます。
    • 最初の実行が 2 番目のスケジュール前に完了した場合:
      • 2 番目のスケジュールが処理されます。
        • この実行が 11:25 のスケジュール以前に完了した場合は、後者のスケジュールも実行されます。
        • 11:21 のスケジュールの実行が 11:25 スケジュールの前に終了しない場合、後の方が保留中ステートでキューに追加されます。
    • 最初の実行が 2 番目のスケジュール前に終了しない場合:
      • 11:21 のスケジュールが、キュー内に保留中ステートとなっています。
        • 11:21 のスケジュールの実行が 11:25 のスケジュール以前に終了した場合は、後者のスケジュールも実行されます。
        • 11:21 のスケジュールの実行が開始され、11:25 のスケジュールの前に完了しない場合、最後のスケジュールは保留中ステートでキューに置かれます。
        • 11:25 のスケジュールが開始される際に 11:21 のスケジュールがまだ保留中の場合は、後者のスケジュールは実行されず、キューにも追加されません。また、次のメッセージが表示されます。「The Robots already have pending jobs for this process.」(ロボットには、既にこのプロセスで保留中のジョブがあります。)
  3. 使用可能な任意のロボットでプロセスを複数回実行する場合、[実行ターゲット] タブで [動的に割り当て] オプションを使用することでその動作を実現できます。これらのジョブは、該当の環境でキューに置かれ、保留ステートになります。ロボットが使用可能になるたびに、保留ステートになっている最初のジョブがそのロボットで実行されます。このように、保留中のジョブが存在する間は、ロボットに空きができません。
    それでは、プロセスを 7 回実行する場合を考えてみましょう。スケジュールがトリガーされると、7 つの保留中のジョブが環境ワークロードに追加されます。このとき、特定のロボットへの割り当ては行われません。いくつかのシナリオが考えられます。
    • トリガー時に 7 台以上のロボットが使用可能な場合には、1 台のロボットが 1 つのジョブに割り当てられ、すべてのジョブが一度に処理されます。
    • トリガー時に 7 台未満のロボット、たとえば 4 台しか使用可能にならなかった場合には、4 台のロボットが 1 台ずつ 1 つのジョブに割り当てられ、新たなロボットまたは 4 台のうちの 1 台が使用可能になると、残りの 3 つのジョブのうち 1 つを引き受けます。残りのジョブがなくなるまで、使用可能なロボットのそれぞれでこのような処理が発生します。

📘

[動的に割り当て] オプションを使用すれば、1 つのジョブでプロセスを最高 10,000 回実行できます。

  1. 同じジョブが2 つ以上のスケジュールにより異なる回数で実行される場合、次回のトリガー時に、その中でのジョブの最大数が環境ワークロードに追加され、ジョブが蓄積されることはありません。たとえば、スケジュール A ではプロセスを 13 回実行し、スケジュール B では 20 回実行するとします。これにより、次のシナリオが考えられます。
    • A と B が同時にトリガーされた場合 - 20 個のジョブ (13 と 20 のうちの最大数) が環境ワークロードのキューに置かれます。
    • B が最初にトリガーされた場合 - 20 個のジョブがキューに置かれます。
      • B のトリガー時刻と A のトリガー時刻の間に、7 個以上のジョブ、たとえば 9 個のジョブが実行されたとします (残りのジョブは 11 個になります)。この場合、13 個のジョブ (11 と 13 の間の最大値) が環境ワークロードのキューに置かれます。
      • B のトリガー時刻と A のトリガー時刻の間に、7 個未満のジョブ、たとえば 5 個のジョブが実行されたとします (残りのジョブは 15 個になります)。この場合、13 個超のジョブが既に保留中となっているため、これ以上のジョブがキューに置かれることはありません。また、次のメッセージが表示されます。「The Robots already have pending jobs for this process.」(ロボットには、既にこのプロセスで保留中のジョブがあります。)
    • A が最初にトリガーされた場合 - 13 個のジョブがキューに置かれます。
      • A の実行中に B がトリガーされた場合は常に、20 個以下のジョブが環境に追加されます。追加されるジョブ数は、A で進行中のジョブ数および実行済みのジョブ数によって変わります。たとえば、6 個のジョブが実行されたとします。B がトリガーされると、最大数である 20 個が達成されるように、14 個のジョブが追加されます。
  2. スケジュールで同じプロセスを複数回実行する場合、キューに置かれる関連ジョブの数は、スケジュールの定義時に [実行ターゲット] タブで指定した実行回数までに制限されます。これらのジョブは、スケジュールのトリガーが起動するたびに蓄積されることはありません。
    それでは、30 分ごとに同じプロセスを 10 回実行する場合を考えてみましょう。初めてスケジュールのトリガーが起動されると、10 件のジョブがキューに入ります。次のトリガーの前に実行されたジョブが 10 件未満である場合 (たとえば 4 件)、次のトリガーが起動されるときは、新しいジョブは 6 件しかキューに入りません。保留中のジョブの数は最大で 10 件までであるからです。

📘

特定のロボットに直接割り当てられたジョブは、動的に割り当てられたジョブに優先してされます。また、ロボットが 2 つ以上の環境に属する場合、ジョブは作成された順に実行されます。

キュートリガー

トリガーの作成時またはキューに新しいアイテムを追加するたびに、プロセスを即座に開始できます。このトリガーは、選択したプロセスに関連付けられている環境で実行されます。

プロセス トリガーのルールをパラメーター化するのに役立つ 3 つのオプションがあります。

Option

Description

Minimum number of items to trigger the first job

The item-processing job is only started after the targeted queue has at least this number of new items.
Deferred queue items are not counted.

Maximum number of pending and running jobs allowed simultaneously

The maximum number of allowed pending and running jobs, counted together.
For 2 or more jobs allowed simultaneously, the third option needs to be defined as described below.

Another job is triggered for each __ new item(s).

A new job is triggered for each number of new items added on top of the number of items defined for the first option.
Only enabled if there are 2 or more jobs allowed simultaneously (defined using the option described above).

To handle queue items that cannot be processed at the moment they are enqueued, including retried items, once every 30 minutes a check for unprocessed items is performed by default, and if the triggering condition is met, the trigger is launched once again. Note that you can use the Queue.ProcessActivationSchedule parameter to adjust the default 30-minute check interval. This check ensures all items in the queue are processed in the following situations:

  • キュー アイテムがキューに追加されるタイミングが、利用可能なリソースでアイテムを処理できるタイミングより早すぎる場合。
  • 非稼働日にキュー アイテムがキューに追加されたが、それらが処理されるのが稼働時間に限られる場合。
  • キュー アイテムの処理が一定期間延期された場合。その期間が経過すれば、それらのキュー アイテムは 30 分ごとのチェックで検出され次第、処理が可能になります。

📘

注:

既定の 30 分間隔のチェックのため、営業時間外はリソース障害が発生する危険があります。これを避けるために、営業日の終業時に未処理アイテムが存在しないようにしてください。それが不可能な場合は、トリガーされたプロセスがユーザーの介入を必要としないようにしてください。

次の 2 つのジョブがあるとします。

  • 20 秒間にわたって秒ごとに 3 つのアイテム (合計 60 アイテム) をターゲット キューに追加するジョブ
  • ターゲット キューのアイテムを秒ごとに 1 つ処理するジョブ

トリガーを次のように定義します。

  • 最初のジョブをトリガーするアイテムの最小数: 31
  • 同時に許可される保留中および実行中のジョブの最大数: 3
  • 10 個の新しいアイテムごとに別のジョブがトリガーされます。

キューにアイテムを追加するジョブを起動します。

  1. 11 秒後 (33 アイテムの追加後) に 1 番目のアイテム処理ジョブがトリガーされます。
  2. 4 秒後 (12 アイテムの追加後) に 2 番目のアイテム処理ジョブがトリガーされます。
  3. 4 秒後 (12 アイテムの追加後) に 3 番目のアイテム処理ジョブがトリガーされます。

キュー アイテムの追加が終了するまでに、1 番目のジョブでは 9 アイテム、2 番目のジョブでは 5 アイテム、3 番目のジョブでは 1 アイテムが処理されています。つまり、これら 3 つのジョブで 20 秒間に 15 アイテムを処理することになります。

これは、45 アイテム (60-15) が未処理で残っていることを意味します。3 つのジョブがあり、それぞれ秒ごとに 1 アイテムが処理されるので、残りのアイテムの処理に 15 秒を要することになります。

処理に要する時間は合計で 35 秒です。

非稼働日

それぞれが独自の日付セットを持つ、テナントごとに非稼働日の複数のリストを定義し、必要に応じてトリガーを実行しないように設定できます。つまり、祝日、土日など、通常業務がない日には、長期トリガーが起動されないように設定できます。[設定] ページの [非稼働日] タブでは、そのようなカレンダーを定義またはアップロードできます。既定では、BankHoliday カレンダーが作成され、最初の非稼働日を簡単に定義できます。選択されたカレンダーで定義された非稼働日を過ぎると、スケジュールは通常どおりにトリガーされます。

14401440

トリガーにこのような制限を適用するには、新規トリガーの作成時または既存トリガーの編集時に、[非稼働日の制限] ドロップダウンから希望するカレンダーを選択する必要があります。トリガーにはカレンダーを 1 つだけ選択できます。[非稼働日] タブでカレンダーの編集を行うと、[非稼働日の制限] ドロップダウン内で既に選択されているトリガーにも影響します。

📘

テナント レベルで設定されているタイムゾーン ([設定] ページ > [全般] タブ) とは異なるタイムゾーンのトリガーについては、[非稼働日の制限] ドロップダウンが無効化されます。

非稼働日の管理方法の詳細については、こちらをご覧ください。

14081408

非稼働日の追加/削除は、テナント レベルで監査されます。監査の詳細については、こちらをご覧ください。

トリガーを無効化

スケジュールを将来の特定の日時に自動的に無効化する場合は、スケジュールの新規作成時または既存スケジュールの編集時に、[指定日時でスケジュールを無効化] オプションを有効化します。

スケジュールを自動的に無効化する方法の詳細については、こちらをクリックしてください。

1 年前に更新



トリガーについて


改善の提案は、API リファレンスのページでは制限されています

改善を提案できるのは Markdown の本文コンテンツのみであり、API 仕様に行うことはできません。