キュートリガー

重要:

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

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

短時間に大量のキュー アイテムを追加した場合 (たとえば、[キュー アイテムを追加] や [キュー アイテムを一括追加] を使用)、プロセスがすぐに開始されない場合があります。このような状況に対処するために、リソースが利用可能になった後にプロセスをトリガーする再確認メカニズムが実装されています。

重要:

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

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

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

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

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

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

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

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

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

変数

変数	説明
newItems	キューで利用可能な新しいキュー アイテムの数です。
minItemsToTrigger	最初のジョブをトリガーするために必要なアイテムの最小数。最初のジョブは、少なくともこの数の新しいアイテムがある場合にのみ開始されます。
maxConcurrentJobs	同時に許可される保留中および実行中のジョブの最大数。これは並行ジョブの上限です。
itemsPerJob	各後続ジョブをトリガーするために必要な追加アイテムの数。minItemsToTriggerに達すると、1 つのジョブが開始されます。minItemsToTriggerを超えるitemsPerJob アイテムごとに、ジョブが 1 つ増え (最大 maxConcurrentJobs個) 開始されます。
pendingJobs	現在 [保留中] ステートにあるジョブの数です。
runningJobs	[再開]、[実行中]、[停止中]、または [終了中] ステートのジョブの数。
enablePendingJobsStrategy	実行中のジョブを残りの容量に対してカウントするかどうかを決定する Boolean 設定です。

[トリガー - キュー トリガー - 保留中ジョブのストラテジを有効化] の設定では、Orchestrator による残りのキャパシティ (スケジュールできる追加ジョブの数) の計算方法を指定します。

• True – 残容量 = maxConcurrentJobs から pendingJobsを引いた値です。この設定は、実行中のジョブが、既にキュー アイテムを 「新規 」ステータスから要求していると予想される場合に使用します。
• False – 残容量 = maxConcurrentJobs から pendingJobs を引いた runningJobs。この設定は、実行中のジョブが「 新規 」ステータスのキュー アイテムをまだ要求していないと予想される場合に使用します。

Orchestrator では、残り容量と必要なジョブの数という 2 つの値のうち小さい方をキュー アイテム数に基づいてスケジュールされます。したがって、この設定は、新しいジョブをどの程度保守的または積極的にスケジュールするかを制御します。

数式

1. 残容量

if enablePendingJobsStrategy = true:
    remainingCapacity = maxConcurrentJobs - pendingJobs

if enablePendingJobsStrategy = false:
    remainingCapacity = maxConcurrentJobs - pendingJobs - runningJobs

2. 希望するジョブ (定員制限前)

if newItems < minItemsToTrigger:
    desiredJobs = 0
else:
    desiredJobs = 1 + (newItems - minItemsToTrigger) / itemsPerJob   [integer division]

3. スケジュールするジョブ

jobsToSchedule = min(desiredJobs, remainingCapacity)

重要

• この評価は、一括追加を含め、1 つのキュー アイテムが追加されるたびに実行されます。
• 延期されたキュー アイテムが確実に考慮されるよう、上記のアルゴリズム全体を再確認するスケジュールがすべてのキュー トリガーに関連付けられています。既定では 30 分ごとに再確認されますが、頻度を増やしたい場合は、テナント設定 [キュー - 未処理のキュー アイテムの確認頻度 (分)] の値を 10 分まで短縮することができます。
  注:

  延期されたアイテムは、延期時間が経過すると処理されます。延期された項目をチェックする組み込みジョブは 30 分間隔で実行されます。ただし、延期されたアイテムがすでに利用可能になった後に同じキューに新しいアイテムが追加された場合は、キュー トリガーがすぐに再トリガーされ、次回のスケジュールされたチェックを待たずに延期されたアイテムがピックアップされる場合があります。

• このアルゴリズムは、しきい値に達したらジョブが開始され、しきい値を超えた場合は増加したバックログを処理するための追加のジョブが開始されるように設計されています。ワークロードをマシン間で均一に分散させるようには設計されていませんが、十分な数のジョブを存在させるように設計されています。
• 開始されたジョブと、それらのジョブが処理するキュー アイテムとの間にハード リンクはありません。ジョブ J は、必ずしもキュー アイテム a、b、c に割り当てられているとは限りません。
• アルゴリズムの結果は、キュー アイテムが一括で追加されたか個別に追加されたかによって異なります。それが、実行される評価の数に影響するからです。
• キュー トリガーの使用時に、「ジョブの最大数に達したため、トリガーがジョブを作成できませんでした。」というアラートが表示される場合があります。このアラートは情報です。通常は、ジョブがすでに実行中のときに、Orchestrator が別のジョブを開始しようとしたことを意味します。現在のジョブのキャパシティに問題がなければ、無視してかまいません。

例

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

このシナリオでは、[ 保留中ジョブのストラテジを有効化 ] パラメーターを Falseに設定します。値の更新方法の詳細については、「 テナント設定」をご覧ください。

このシナリオでは、次の 2 つのジョブが使用されます。

• 1 つは、毎秒 3 個のアイテムを 20 秒間、対象のキューに追加します (合計 60 個のアイテム)。
• 1 つは、対象のキューから 1 秒あたり 1 つのアイテムを処理します。

トリガーは次のように設定されます。

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

キューにアイテムを追加するジョブが開始された後:

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

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

残りの 45 個のアイテム (60 − 15) は、3 つのジョブによってそれぞれ 1 秒あたり 1 個のアイテムで処理され、さらに 15 秒で完了します。合計処理時間: 35 秒

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

このシナリオでは、[ 保留中ジョブのストラテジを有効化 ] パラメーターを Falseに設定します。値の更新方法の詳細については、「 テナント設定」をご覧ください。

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

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

保留中ジョブを有効化する ストラテジの例

次の例は、[ 保留中ジョブのストラテジを有効化 ] 設定によって、有効化されている場合はスケジュール超過、無効化されている場合はスケジュール不足が発生する可能性があることを示しています。

トリガーの設定

設定	値 (Value)
トリガーするキュー アイテムの最小数	1
保留中および実行中のジョブの最大数	1,000
それぞれに対して別のジョブがトリガーされます。	1つの新しいアイテム
ジョブの完了後に再評価する	True
保留中ジョブのストラテジを有効化	True (パート 1)

仮定： ジョブがキュー アイテムを [新規 ] ステータスから移行するのに 30 秒かかります。

パート 1: Enable pending jobs strategy を有効にしたスケジュール超過

手順 1: 1,100 個のアイテムが一括でキューに追加され、1,000 個のジョブがトリガーされます。

手順 2: 利用可能なロボットは 200 台のみです。200 件のジョブが実行され、800 件が保留中です。

ジョブ	Count
Running (実行中)	200
保留中	800

キュー アイテム	ステータス
200	処理中
900	New

手順 3: 実行中の 200 個のジョブが完了し、さらに 200 個のジョブの実行がトリガーされます。

ジョブ	Count
Running (実行中)	200
保留中	600

キュー アイテム	ステータス
200	成功
200	処理中
700	New

手順 4:ジョブの完了後、再評価が有効化されているため、トリガーは数秒以内に再度実行されます。[保留中ジョブのストラテジを有効化] を有効にすると、Orchestrator では、実行中の 200 個のジョブすべてで、すでにキュー アイテムが「新規」ステータスから移行しているとみなされます。実際には 30 秒かかります。

手順 5: この時点でのトリガーの計算は、以下のとおりです。

remainingCapacity = maxConcurrentJobs - pendingJobs = 1000 - 600 = 400
desiredJobs       = newItems - pendingJobs          = 700 - 600  = 100
jobsToSchedule    = min(100, 400)                               = 100

さらに 100 件のジョブがスケジュールされています。ただし、実行中の 200 個のジョブによってアイテムがまだ 「新規 」ステータスから移行していないため (30 秒かかります)、実際に新しいジョブを必要としているのは ~500 個のみであるにもかかわらず、Orchestrator では 700 個の 新しい アイテムが未発見として扱われます。その結果、約 100 個のジョブがスケジュール超過になります。

注:

Orchestrator は個々のジョブと個々のキュー アイテムの関係を追跡しないため、それ自体で過剰なスケジュールを検出することはできません。過剰スケジュールを特定するには、外部の状態を追跡する必要があります。

手順 6:[保留中ジョブのストラテジを有効化] を無効化しても、同じ状況で以下の結果が生成されます。

remainingCapacity = maxConcurrentJobs - pendingJobs - runningJobs = 1000 - 600 - 200 = 200
desiredJobs       = newItems - pendingJobs - runningJobs           = 700 - 600 - 200 = -100 → 0
jobsToSchedule    = min(0, 200)                                                      = 0

追加のジョブはスケジュールされません。このシナリオでは、ほぼ修正されます。

パート 2: 保留中ジョブ戦略を無効化したスケジュール不足

手順 1: このシナリオでは、ジョブは同時には完了しません。最初の 200 個のジョブのうち、100 個は 60 秒後に完了し、残りの 100 個は 90 秒後に完了します。

手順 2: 最初の 100 個のジョブが完了し、さらに 100 個のジョブがトリガーされます。

ジョブ	Count
Running (実行中)	200
保留中	700

キュー アイテム	ステータス
100	成功
200	処理中
700	New

手順 3:ジョブの完了後、再評価が有効化されているため、トリガーは数秒以内に再度実行されます。

手順 4:[保留中ジョブのストラテジを有効化] が有効な場合

remainingCapacity = maxConcurrentJobs - pendingJobs          = 1000 - 700 = 300
desiredJobs       = newItems - pendingJobs                   = 700 - 700  = 0
jobsToSchedule    = min(0, 300)                                           = 0

追加のジョブはスケジュールされていません。これは正しいです。700 個の新しい アイテムに対して 700 個の保留中のジョブがあります。

手順 5:[保留中ジョブのストラテジを有効化] が無効化されている場合

remainingCapacity = maxConcurrentJobs - pendingJobs - runningJobs = 1000 - 700 - 200 = 100
desiredJobs       = newItems - pendingJobs - runningJobs           = 700 - 700 - 200 = -200 → 0
jobsToSchedule    = min(0, 100)                                                       = 0

ここでも、追加のジョブはスケジュールされていません。ただし、保留中のジョブが少ない場合、計算式はスケジュールを下回ることになります。つまり、実行中の 200 個のジョブのうち、100 個がすでにアイテムを 「新規 」ステータスから要求しているにもかかわらず、まだ取得していないと想定されます。

手順 6: スケジュール不足のためにスケジュールされていないジョブは、最終的に [未処理のキュー アイテム] チェック が定期的なスケジュールに従って実行されるとピックアップされます。これがこのチェックの目的です。

概要

設定	ジョブの実行に関する仮定	結果
有効 (True)	キュー アイテムを既に要求している	スケジュール超過の場合あり
無効 (False)	キュー アイテムをまだ要求していない	スケジュール不足の場合(定期的な再チェックで軽減)

実行ターゲット

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

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

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

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

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

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

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