キュートリガー

タイム ゾーン設定や非稼働日カレンダーなどのキュー トリガーを作成および構成します。

重要:

• 1 つのキューに対して作成できるキュー トリガーは 1 つです。これは、複数のフォルダーで共有されているキューにも適用されます。
• トリガーのタイム ゾーン: トリガーに設定されたタイム ゾーンは、テナントのタイム ゾーンによって制限されません。ただし、非稼働日カレンダーを使用する場合は、異なるタイム ゾーンを設定することはできません。キュー トリガーは、トリガー レベルで定義されたタイム ゾーンに従って起動されます。キュー トリガーは、キュー アイテムの処理に基づいて起動されます。キュー トリガーは、トリガーのタイム ゾーンに基づいて無効化されます。

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

重要:

キュー トリガーを実装するのに最適なケースは、処理可能なすべてのキュー アイテムを内部ループで処理してからループを抜けるプロセスを実行する場合です。プロセスにこのストラテジが実装されていない場合、得られる結果は最適なものではなく、求められるビジネス要件を満たさない可能性があります。

プロセス トリガーのルールは、以下のオプションでパラメーター化できます。

	説明
最初のジョブをトリガーするアイテムの最小数	アイテム処理ジョブは、ターゲット キューに少なくともこの数の新しいアイテムが追加された後にのみ開始されます。 延期済みのキュー アイテムはカウントされません。
同時に許可される保留中および実行中のジョブの最大数	一緒にカウントされる、許可された保留中および実行中のジョブの最大数。 同時に 2 つ以上のジョブを許容する場合は、次に示す 3 番目のオプションを定義する必要があります。
指定した数のアイテムが追加されるたびにジョブをトリガー	最初のオプションで定義されたアイテムの数に追加された新しいアイテムごとに、新しいジョブがトリガーされます。 2 つ以上のジョブの同時実行が許可されている場合にのみ有効化されます（上記のオプションを使用して定義）。
ジョブの完了後に条件を見直し、可能な場合は新しいジョブを開始	選択すると、各ジョブの完了後にキュー トリガーが評価され、ロボットが利用可能な場合は新しいジョブが開始されます。 これは、30 分ごとに行われる自動チェックを補完するものであり、可能な場合は残りのキュー アイテムが遅れることなく処理されるようになります。

キューに登録する段階で処理できないキュー アイテム (リトライ アイテムを含む) を処理するために、未処理のアイテムがないかのチェックが既定で 30 分ごとに実行され、トリガーの条件が満たされると再度トリガーが起動されます。

Queue.ProcessActivationSchedule パラメーターを使用すれば、既定の 30 分のチェック間隔を調整できます。ただし、 Queue.ProcessActivationSchedule の値を変更しても、すぐには処理中の既存のキュー アイテムに影響しないことに注意してください。変更は、キュー トリガーが更新された後に有効になります。

これにより、以下の状況でもキュー内のすべてのアイテムが確実に処理されるようになります。

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

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

キュー トリガーの処理アルゴリズム

アルゴリズムで使用される数

• キューで利用可能な新しいキュー アイテムの数: N
• 最初のジョブをトリガーするために必要なアイテムの最小数: x
  • つまり、新しいアイテムが x 個はないとジョブがトリガーされません。
• 同時に許可される保留中および実行中のジョブの最大数: y
  • つまり、並行して実行できるジョブの数を上限 (y) に設定します。
• 指定した数のアイテムが追加されるたびにジョブをトリガー: z
  • つまり、キュー アイテムが x 個に達すると 1 個のジョブが開始されます。残りの N-x 個のキュー アイテムについては、(N-x)/z 個のジョブの開始を試みます。これが y 個を超える場合は、合計 y 個を超えない数のジョブを作成します。

追加で作成できるジョブの数を評価するときに、現在の実行中のジョブ (w) が考慮されます。[トリガー - キュー トリガー - 保留中ジョブのストラテジを有効化] の設定に基づき、この数値が以下のように計算されます。

• True - 新しく利用可能になるキュー アイテムに基づいて作成される追加ジョブの最大数 = y から [保留中] ステートのジョブの数を引いた数 (このオプションは、Orchestrator で、実行中のすべてのジョブのキュー アイテムが [新規] ステータスから既に移行したと見なされるようにする場合に最適です)。
• False - 新しく利用可能になるキュー アイテムに基づいて作成される追加ジョブの最大数 = y から [保留中]、[再開]、[実行中]、[停止中]、[終了中] のいずれかのステートのジョブの数を引いた数 (このオプションは、Orchestrator で、実行中のすべてのジョブのキュー アイテムが [新規] ステータスからまだ移行していないと見なされるようにする場合に最適です)。

重要

• この評価は、一括追加を含め、1 つのキュー アイテムが追加されるたびに実行されます。
• 延期されたキュー アイテムが確実に考慮されるよう、上記のアルゴリズム全体を再確認するスケジュールがすべてのキュー トリガーに関連付けられています。既定では 30 分ごとに再確認されますが、頻度を増やしたい場合は、テナント設定 [キュー - 未処理のキュー アイテムの確認頻度 (分)] の値を 10 分まで短縮することができます。
• このアルゴリズムの目的は従来と変わりません。しきい値に達したらジョブが確実に開始され、そのしきい値を超えた場合は増加したバックログを処理するための追加のジョブが開始されるようにするためのものです。ワークロードを分散可能なマシン全体に均一に分散させることではなく、十分な数のジョブを存在させることのみを意図しています。
• 開始されたジョブと、それらのジョブに対応するキュー アイテムとの間にハード リンクはありません。つまり、ジョブ J は必ずしもキュー アイテム a、b、c などを処理する必要はありません。
• アルゴリズムの結果は、キュー アイテムが一括で追加されたか個別に追加されたかによって異なります。それが、実行される評価の数に影響するからです。

例

シナリオ 1 - 個別に追加されたキュー アイテム

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

• 20 秒間にわたって秒ごとに 3 つのアイテム (合計 60 アイテム) をターゲット キューに追加するジョブ
• 対象のキューから 1 秒あたり 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 秒かかります。

シナリオ 2 - 一括で追加されたキュー アイテム

上記のシナリオで説明した 60 個のキュー アイテムを 1 回の一括操作で追加すると (実行中または保留中のジョブがない場合)、3 つのジョブが作成されます。

再評価スケジュールの前に少なくとも 1 つのジョブが完了すると、さらにジョブが作成されます。

実行ターゲット

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

説明
アカウント	The process is executed under a specific account. Specifying only the account results in Orchestrator allocating the machine dynamically. Specifying both the account and the machine template 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. Specifying only the machine template results in Orchestrator allocating the account dynamically. Specifying both the account and the machine template means the job launches on that very account-machine pair. 注: ジョブの実行に必要なランタイム ライセンスが、関連するマシン テンプレートに割り当てられていることを確認してください。
ホスト名	ホスト名 マシン テンプレートを選択すると、[ホスト名] オプションが表示され、プロセスを実行する任意のワークステーション/ロボット セッションを選択できます。 アクティブなフォルダーで利用可能なすべてのセッション (未接続、切断、または接続済み) が表示されます。 注: ジョブの実行に必要なランタイム ライセンスが、関連するマシン テンプレートに割り当てられていることを確認してください。

UiPath Activities を使用して作成されたキュー トリガー

キュー トリガーは、Studio での設計時に UiPath.Core.Activities パッケージの [キューへの新しいアイテムの追加時] アクティビティを使用して RPA 開発者が作成することもできます。

Orchestrator では、これらの種類のトリガーはパッケージ要件として識別されるので、Orchestrator にこれらのトリガーを追加する場合、[パッケージ要件] ページから追加する方法しかありません。

設計時に設定した構成はすべて Orchestrator に反映され、変更できません。

例: キューに キュー アイテムが追加されたときに、そのメタデータをログ メッセージとして受け取りたいと考えています。ここでの違いは、このキュー トリガーはワークフローの内部からオートメーションに開始を指示するのに対し、Orchestrator のキュー トリガーはワークフローの外部から開始を指示するところです。