キュートリガー

重要:

トリガーのタイムゾーン: トリガーに設定されているタイムゾーンは、テナントのタイムゾーンに制限されません。ただし、非稼働日カレンダーを使用する場合は異なるタイムゾーンを設定できません。

キュートリガーは、トリガーレベルで定義されたタイムゾーンに従って起動されます。キュートリガーはキューアイテムの処理に基づいて起動されます。

キュートリガーは、どちらもトリガーのタイムゾーンに基づいて無効化されます。

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

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

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

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

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

既定の確認間隔は 30 分ですが、[キュー - 未処理のキューアイテムの確認頻度 (分)] パラメーターを使用して調整できます。

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

キューアイテムがキューに追加されるタイミングが、利用可能なリソースでアイテムを処理できるタイミングより早すぎる場合。
非稼働日にキューアイテムがキューに追加されたが、それらが処理されるのが稼働時間に限られる場合。
キューアイテムの処理が一定期間延期された場合。その期間が経過すれば、それらのキューアイテムは 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 個の新しいアイテムごとに別のジョブがトリガーされます。

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

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

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

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

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

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

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

実行ターゲット

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

説明
アカウント	プロセスは、特定のアカウントにより実行されます。アカウントのみを指定すると、Orchestrator によりマシンが動的に割り当てられます。アカウントとマシンテンプレートの両方を指定すると、ジョブはそのアカウントとマシンのペアで開始されます。
マシン	プロセスは、選択したマシンテンプレートに接続されたホストマシンのいずれかで実行されます。マシンテンプレートのみを指定すると、Orchestrator によりアカウントが動的に割り当てられます。アカウントとマシンテンプレートの両方を指定すると、ジョブはそのアカウントとマシンのペアで開始されます。注: ジョブの実行に必要なランタイムライセンスが、関連するマシンテンプレートに割り当てられていることを確認してください。
ホスト名	ホスト名マシンテンプレートを選択すると、[ホスト名] オプションが表示され、プロセスを実行する任意のワークステーション/ロボットセッションを選択できます。アクティブなフォルダーで利用可能なすべてのセッション (未接続、切断、または接続済み) が表示されます。注: ジョブの実行に必要なランタイムライセンスが、関連するマシンテンプレートに割り当てられていることを確認してください。

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

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

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

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

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