队列触发器

重要提示：

• 您可以为队列创建一个队列触发器。 这也适用于共享到多个文件夹的队列。
• 触发器时区：在触发器上设置的时区不受租户时区的限制。但是，如果您使用非工作日日历，则无法设置不同的时区。 队列触发器根据在触发器级别定义的时区启动。 队列触发器会基于队列项目处理而启动。 基于触发器时区禁用队列触发器。

队列触发器在创建触发器后或将新项目添加到队列中时立即启动流程。触发器在与所选流程关联的环境中运行。

When a large number of queue items are added in a short time (for example, using AddQueueItem or BulkAddQueueItems), the process may not start immediately. To handle such situations, there is a recheck mechanism implemented to ensure the process is triggered once resources are available.

重要提示：

队列触发器的实现针对使用具有内部循环的流程进行了优化，以便在退出之前处理所有可用的队列项目。如果流程不实施此策略，则不会产生最佳体验，并且可能无法满足所需的业务要求。

以下这些选项可帮助您参数化流程触发的规则：

	描述
触发第一个作业的最小项目数	项目处理作业仅在目标队列中具有至少此数量的新项目之后才开始。延迟的队列项目不计算在内。
允许同时等待和运行的最大作业数	允许的待处理作业和正在运行的作业的最大数量（一起计算）。对于同时允许的 2 个或多个作业，需要按如下所述定义第三个选项。
每 __ 个新项目触发另一个作业。	触发新作业的新项目的数量（在为第一个选项定义的项目数的基础上增加）。 仅在允许同时两个或更多作业（使用上述选项定义）时启用。
完成作业后，重新评估条件，并在可能的情况下开始新作业	如果选中，则会在每个作业完成后评估队列触发器，并在机器人可用时启动新作业。这是对每 30 分钟一次的自动检查的补充，并有助于确保尽可能以无延迟的方式处理剩余队列项目。

为了处理在加入队列时无法处理的队列项目（包括重试项目），默认情况下每 30 分钟执行一次未处理项目检查，如果满足触发条件，则会再次启动触发器。

You can use the Queues - Unprocessed queue items check frequency (minutes) parameter to adjust the default 30-minute check interval.

此检查可确保在以下情况下队列中的所有项目都能得到处理：

• 队列项目添加到队列的速度比使用可用资源处理队列项目的速度要快得多。
• 队列项目是在非工作日添加到队列中的，但是只能在工作时间进行处理。
• 队列项目处理将推迟到以后的时间。经过这段时间后，一旦经过 30 分钟的检查确定，便可以对其进行处理。
  备注：

  默认检查时间为 30 分钟，因此在非工作时间存在资源阻塞的风险。为避免这种情况，请确保在工作日结束时没有未处理的项目。如果不可能，请确保触发的流程不需要人工干预。

队列触发器处理算法

变量

变量	描述
newItems	Number of new queue items available in the queue.
minItemsToTrigger	Minimum number of items required to trigger the first job. The first job starts only when there are at least this many new items.
maxConcurrentJobs	Maximum number of pending and running jobs allowed simultaneously. This is the ceiling on parallel jobs.
itemsPerJob	Number of additional items needed to trigger each subsequent job. When minItemsToTrigger is reached, one job starts. For every additional itemsPerJob items beyond minItemsToTrigger, one more job starts—up to maxConcurrentJobs.
pendingJobs	Number of jobs currently in Pending state.
runningJobs	Number of jobs in Resumed, Running, Stopping, or Terminating states.
enablePendingJobsStrategy	Boolean setting that determines whether running jobs are counted against the remaining capacity.

The Triggers - Queue triggers - Enable pending jobs strategy setting determines how Orchestrator calculates remaining capacity—the number of additional jobs it is allowed to schedule:

• True – Remaining capacity = maxConcurrentJobs minus pendingJobs. Use this setting when running jobs are expected to have already claimed their queue items from New status.
• False – Remaining capacity = maxConcurrentJobs minus pendingJobs minus runningJobs. Use this setting when running jobs are expected to have not yet claimed their queue items from New status.

Orchestrator schedules the smaller of two values: the remaining capacity and the number of desired jobs based on queue item counts. The setting therefore controls how conservatively or aggressively new jobs are scheduled.

公式

1. Remaining capacity

if enablePendingJobsStrategy = true:
    remainingCapacity = maxConcurrentJobs - pendingJobs

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

2. Desired jobs (before capacity limit)

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

3. Jobs to schedule

jobsToSchedule = min(desiredJobs, remainingCapacity)

重要提示

• 每当添加单个队列项目（包括通过批量添加）时，都会发生此评估。
• 为确保将已推迟（延迟）的队列项目考虑在内，每个队列触发器都有一个关联的计划，该计划将重新检查上述整个算法。默认情况下，此操作每 30 分钟进行一次，但可以通过“队列 - 未处理的队列项目检查频率（分钟）”租户设置将其减少到至少 10 分钟。
  备注：

  只有在其推迟时间过后，才会处理推迟的项目。用于检查推迟项目的内置作业每 30 分钟运行一次。但是，如果在推迟的项目已经可用后将新项目添加到同一队列中，则将立即重新触发队列触发器，并且可以选取推迟的项目，而无需等待下一次计划的检查。

• The algorithm is designed to ensure a job starts once a threshold is reached, and that when the threshold is surpassed, additional jobs start to help process the increased backlog. It is not designed to distribute workload uniformly across machines, but to ensure that enough jobs are present.
• There is no hard link between the jobs started and the queue items they process. Job J is not necessarily assigned to queue items a, b, or c.
• 根据是批量添加还是单独添加队列项目，算法结果会有所不同，因为这会影响所执行的评估次数。
• 使用队列触发器时，您可能会遇到以下警示：The trigger could not create a job as the maximum number of jobs has been reached. 此警示仅供参考，通常意味着当 Orchestrator 尝试启动一个作业时，另一个作业已在运行。如果您对当前的作业能力感到满意，可以放心将其忽略。

示例

场景 1 - 单独添加的队列项目

For this scenario, the Enable pending jobs strategy parameter is set to False. For more information on how to update the value, see Tenant Settings.

Two jobs are used in this scenario:

• One adds 3 items per second for 20 seconds to the targeted queue (60 items total).
• One processes 1 item per second from the targeted queue.

The trigger is configured as follows:

• Minimum number of items to trigger the first job: 31
• Maximum number of pending and running jobs allowed simultaneously: 3
• Another job is triggered for each: 10 new item(s)

After the job that adds items to the queue starts:

1. After 11 seconds (33 items), the first item-processing job is triggered.
2. After another 4 seconds (12 items), the second item-processing job is triggered.
3. After another 4 seconds (12 items), the third item-processing job is triggered.

By the time queue item addition ended, the first job had processed 9 items, the second 5 items, and the third 1 item—15 items in 20 seconds processed by three jobs.

The remaining 45 items (60 − 15) are processed by 3 jobs at 1 item per second each, completing in another 15 seconds. Total processing time: 35 seconds.

场景 2 - 批量添加队列项目

For this scenario, the Enable pending jobs strategy parameter is set to False. For more information on how to update the value, see Tenant Settings.

If the 60 queue items from Scenario 1 are added with one bulk operation (when no job is running or pending), 3 jobs are created.

If at least one job finishes before the reevaluation schedule, further jobs are created.

Enable pending jobs strategy examples

These examples show how the Enable pending jobs strategy setting can cause over-scheduling when enabled and under-scheduling when disabled.

Trigger configuration

设置	值
Minimum queue items to trigger	1
Maximum number of pending and running jobs	1,000
Another job triggered for each	1 new item
After completing job, reassess	True
Enable pending jobs strategy	True (Part 1)

Assumption: It takes 30 seconds for a job to move a queue item out of New status.

Part 1: Over-scheduling with Enable pending jobs strategy enabled

Step 1: 1,100 items are added to the queue in bulk, triggering 1,000 jobs.

Step 2: Only 200 robots are available. 200 jobs run and 800 remain pending.

作业	计数
正在运行	200
待处理	800

队列项目	状态
200	In Process
900	新添加

Step 3: The 200 running jobs complete, triggering 200 more jobs to run.

作业	计数
正在运行	200
待处理	600

队列项目	状态
200	成功
200	In Process
700	新添加

Step 4: Because After completing job, reassess is enabled, the trigger runs again within seconds. With Enable pending jobs strategy enabled, Orchestrator assumes that all 200 running jobs have already moved their queue items out of New status—even though this actually takes 30 seconds.

Step 5: The trigger calculation at this point:

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

100 more jobs are scheduled. However, because the 200 running jobs have not yet moved their items out of New status (it takes 30 seconds), Orchestrator is treating 700 New items as uncovered when only ~500 truly need new jobs. The result is approximately 100 over-scheduled jobs.

备注：

Orchestrator does not track the relationship between individual jobs and individual queue items, so it cannot detect over-scheduling on its own. Identifying over-scheduling requires external state tracking.

Step 6: With Enable pending jobs strategy disabled, the same situation produces:

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

No additional jobs are scheduled—which is closer to correct in this scenario.

Part 2: Under-scheduling with Enable pending jobs strategy disabled

Step 1: In this scenario, jobs do not finish simultaneously. Of the initial 200 jobs, 100 complete after 60 seconds and the other 100 complete after 90 seconds.

Step 2: The first 100 jobs complete, triggering 100 more jobs.

作业	计数
正在运行	200
待处理	700

队列项目	状态
100	成功
200	In Process
700	新添加

Step 3: Because After completing job, reassess is enabled, the trigger runs again within seconds.

Step 4: With Enable pending jobs strategy enabled:

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

No additional jobs are scheduled. This is correct—there are 700 pending jobs for 700 New items.

Step 5: With Enable pending jobs strategy disabled:

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

No additional jobs are scheduled here either. However, if there were fewer pending jobs, the formula would under-schedule: it assumes the 200 running jobs have not yet claimed their items from New status, even though 100 of them already have.

Step 6: Jobs not scheduled due to under-scheduling are eventually picked up when the Unprocessed queue items check runs on its periodic schedule. This is the purpose of that check.

摘要

设置	Assumption about running jobs	Consequence
Enabled (true)	Have already claimed their queue items	May over-schedule
Disabled (false)	Have not yet claimed their queue items	May under-schedule (mitigated by periodic re-checks)

执行目标

您可以配置多个规则，具体取决于执行哪些关联的流程。

描述
帐户	该流程在特定帐户下执行。仅指定帐户会导致 Orchestrator 动态分配计算机。同时指定帐户和计算机模板意味着作业将在该帐户-计算机对上启动。
计算机	此流程在附加到所选计算机模板的其中一台主机上执行。仅指定计算机模板会导致 Orchestrator 动态分配帐户。同时指定帐户和计算机模板意味着作业将在该帐户-计算机对上启动。 注意：确保将执行作业所需的运行时许可证分配给关联的计算机模板。
主机名	主机名 选择计算机模板后，系统将显示“主机名”选项，允许您选择所需的工作站/机器人会话以执行流程。 系统将显示活动文件夹中的所有可用会话，包括未连接、已断开连接或已连接的会话。 注意：确保将执行作业所需的运行时许可证分配给关联的计算机模板。

使用 UiPath 活动创建的队列触发器

RPA Developer 也可以在 Studio 的设计时中使用 UiPath.Core.Activities 包的“将新项目添加到队列时”活动创建队列触发器。

Orchestrator 将这些类型的触发器标识为包要求，通过“包要求”页面完成相关操作是在 Orchestrator 中添加这些触发器的唯一方法。

在设计时设置的任何配置都会反映在 Orchestrator 中，并且无法修改。

例如：将队列项目添加到队列时，我希望以日志消息的形式接收其元数据。此处的区别在于，队列触发器指示自动化从工作流内部开始，而 Orchestrator 队列触发器指示自动化从工作流外部开始。