通知を受け取る

UiPath Orchestrator

UiPath Orchestrator ガイド

トリガーについて

トリガーを使用すると、事前に計画された方法で、定期的に (タイム トリガー)、または新しいアイテムがキューに追加されるたびに (キュー トリガー) ジョブを実行できます。[トリガー] ページでは、新しいトリガーの作成、既存トリガーの管理、既存トリガーのジョブの即座起動を実行できます。

🚧

重要

トリガーの実行時間は、特定のタイム ゾーンに合わせて調整できます。トリガーに設定されているタイム ゾーンは、テナントのタイム ゾーン ([設定 ] ページで設定します) と連携していません。

Learn more about jobs and job execution.

タイム トリガー


Enable you to schedule a recurrent time to start a job. Input values for processes that support input and output parameters can be managed at this level as well.

実行ターゲット

実行する関連プロセスに応じて、いくつかのルールを設定できます。

説明

動的に割り当て

動的に割り当て

所定のトリガーに従ってプロセスを実行する回数を定義します。このオプションにより、リソースを最大限活用できるようになります。ロボットが使用可能になると、設定されたトリガーに従って対象のプロセスが実行されます。

アカウント

The process is executed under a specific account. Only specifying the account results in Orchestrator allocating the machine dynamically. Specifying both the account and the machine means the job launches on that very account-machine pair.

マシン

The process is executed on one of the host machines attached to the selected machine template. Only specifying the machine results in Orchestrator allocating the account dynamically. Specifying both the account and the machine means the job launches on that very account-machine pair.

ジョブの種類に一致したランタイムが、関連するマシン テンプレートに割り当てられていることを確認してください。アクティブなフォルダーに関連付けられた、接続済みのホスト マシンだけが表示されます。

Select valid account-machine Mappings

The process can be executed on multiple specific account-machine pairs. Learn more about account-machine mappings.

📘

重要

何らかの理由で 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 のトリガーがまだ保留中の場合は、11:25 のトリガーは実行されず、キューにも追加されません。そして、「ロボットには既にこのプロセスに対する保留中のジョブがあります」というメッセージが表示されます。
  3. 使用可能な任意のロボットでプロセスを複数回実行する場合、[実行ターゲット] タブで [動的に割り当て] オプションを使用することでその動作を実現できます。これらのジョブは、該当のロボット グループでキューに置かれ、保留中のステートになります。ロボットが使用可能になるたびに、保留中のステートの最初のジョブがそのロボットで実行されます。このように、保留中のジョブが存在する間は、ロボットに空きができません。
    それでは、プロセスを 7 回実行する場合を考えてみましょう。トリガーが起動されると、7 つの保留中のジョブがロボット グループのワークロードに追加されます。このとき、特定のロボットへの割り当ては行われません。いくつかのシナリオが考えられます。
    • トリガー時に 7 台以上のロボットが使用可能な場合には、1 台のロボットが 1 つのジョブに割り当てられ、すべてのジョブが一度に処理されます。
    • トリガー時に 7 台未満のロボット、たとえば 4 台しか使用可能にならなかった場合には、4 台のロボットが 1 台ずつ 1 つのジョブに割り当てられ、新たなロボットまたは 4 台のうちの 1 台が使用可能になると、残りの 3 つのジョブのうち 1 つを引き受けます。残りのジョブがなくなるまで、使用可能なロボットのそれぞれでこのような処理が発生します。
  4. 同じプロセスが複数のトリガーによって異なる回数実行される場合、次回のトリガーが起動されるときにロボット グループのワークロードに置かれるジョブの数は、各トリガーに設定されている中で最も大きい実行回数までに限られます。ジョブは蓄積されません。たとえば、トリガー 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 個のジョブが追加されます。
  5. トリガーで同じプロセスを複数回実行する場合、キューに置かれる関連ジョブの数は、トリガーの定義時に [実行ターゲット] タブで指定した実行回数までに制限されます。これらのジョブは、それぞれのトリガーが起動するたびに蓄積されることはありません。
    それでは、30 分ごとに同じプロセスを 10 回実行する場合を考えてみましょう。初めてトリガーが起動されると、10 件のジョブがキューに入ります。次のトリガーの前に実行されたジョブが 10 件未満である場合 (たとえば 4 件)、次のトリガーが起動されるときは、新しいジョブは 6 件しかキューに入りません。保留中のジョブの数は最大で 10 件までであるからです。

キュートリガー


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

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

説明

最初のジョブをトリガーするアイテムの最小数

アイテム処理ジョブは、ターゲット キューに少なくともこの数の新しいアイテムが追加された後にのみ開始されます。
延期済みのキュー アイテムはカウントされません。

同時に許可される保留中および実行中のジョブの最大数

一緒にカウントされる、許可された保留中および実行中のジョブの最大数。
同時に 2 つ以上のジョブを許容する場合は、次に示す 3 番目のオプションを定義する必要があります。

指定した数のアイテムが追加されるたびにジョブをトリガー

最初のオプションで定義されたアイテムの数に追加された新しいアイテムごとに、新しいジョブがトリガーされます。
2 つ以上のジョブの同時実行が許可されている場合にのみ有効になります(上記のオプションを使用して定義)。

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 秒です。

実行ターゲット

実行する関連プロセスに応じて、いくつかのルールを設定できます。

説明

アカウント

The process is executed under a specific account. Only specifying the account results in Orchestrator allocating the machine dynamically. Specifying both the account and the machine means the job launches on that very account-machine pair.

マシン

The process is executed on one of the host machines attached to the selected machine template. Only specifying the machine results in Orchestrator allocating the account dynamically. Specifying both the account and the machine means the job launches on that very account-machine pair.

ジョブの種類に一致したランタイムが、関連するマシン テンプレートに割り当てられていることを確認してください。アクティブなフォルダーに関連付けられた、接続済みのホスト マシンだけが表示されます。

ジョブのカウント方法

The Triggers.JobsCountStrategy parameter enables you to choose the strategy for launching jobs through triggers. The following options are available:

  • PerProcess (プロセスごと) - 必要な数のジョブをトリガーが開始するにあたって、指定したプロセスで保留中のジョブの数が考慮されます。たとえば、同じプロセスに対して定義された 2 つのトリガーが、それぞれ 3 個のジョブと 5 個のジョブを開始するよう設定されているとします。ある時点で 1 つ目のトリガーが 3 個のジョブを開始している場合、2 つ目のトリガーが実行される際は、必要なジョブ数 (5 個) に達するように 2 個のジョブが開始されます。

  • PerTrigger (トリガーごと) - 必要な数のジョブをトリガーが開始するにあたって、同じトリガーによってこれまでに開始された既存のジョブの数が考慮されます。たとえば、あるトリガーがある時点で 9 個のジョブを開始するよう定義されているとします。既に 2 個のジョブが正常に完了している状態でトリガーが再び実行されると、必要なジョブ数 (9 個) に達するようにさらに 2 個のジョブが開始されます。

  • NoLimit (制限なし) - 必要な数のジョブをトリガーが開始するにあたって、既存のジョブや保留中のジョブは考慮されません。たとえば、あるトリガーがある時点で 5 個のジョブを開始するよう定義されているとします。同じトリガーが 2 度目に実行される際は、さらに 5 個のジョブが開始されます。

非稼働日


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

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

📘

カレンダーの制限は異なるタイムゾーンに適用できないため、テナント レベル ([設定] ページ > [全般] タブ) で設定されたタイムゾーンとは異なるタイムゾーンではトリガーを保存できません。タイムゾーンが明示的に定義されていないテナントは、ホストからタイムゾーンを継承します。

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

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

約 1 か月前に更新


トリガーについて


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

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