- Getting started
- Best practices
- Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Storing Robot Credentials in CyberArk
- Storing Unattended Robot Passwords in Azure Key Vault (read only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read only)
- Storing Unattended Robot Credentials in AWS Secrets Manager (read only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- Configuring automation capabilities
- Audit
- Resource Catalog Service
- Automation Suite robots
- Folders Context
- Automations
- Processes
- Jobs
- Apps
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Integrations
- Troubleshooting
Queue triggers
Trigger time zones: The time zone set on a trigger is not restricted by the time zone of the tenant. However, if you use non-working days calendars, you cannot set different time zones.
Queuee triggers are launched according to the time zone defined on the trigger level. Queue triggers are launched based on queue items processing.
Queue triggers are disabled based on the trigger time zone.
These options help you parameterize the rules for process triggering:
|
Description | |
|---|---|
| Minimum number of items to trigger the first job |
The item-processing job is only started after the targeted queue has at least this number of new items. Deferred queue items are not counted. |
| Maximum number of pending and running jobs allowed simultaneously |
The maximum number of allowed pending and running jobs, counted together. For 2 or more jobs allowed simultaneously, the third option needs to be defined as described below. |
| Another job is triggered for each __ new item(s). |
A new job is triggered for each number of new items added on top of the number of items defined for the first option. Only enabled if there are 2 or more jobs allowed simultaneously (defined using the option described above). |
| After completing jobs, reassess conditions and start new jobs if possible | If selected, the queue trigger is evaluated after each job completion, and new jobs are started if robots are available.
This complements the automatic check that occurs every 30 minutes, and helps ensure that remaining queue items are processed with no lags when possible. |
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.
You can use the Queue.ProcessActivationSchedule
parameter to adjust the default 30-minute check interval.
Note that changing the value of
Queue.ProcessActivationSchedule does not immediately impact
existing queue items that are in progress. The changes take effect after the queue
trigger is updated.
This check ensures all items in the queue are processed in the following situations:
- Queue items are added to the queue much faster than they can be processed with the available resources.
- Queue items are added to a queue during non-working days, but they can only be processed during working hours.
-
Queue items processing is postponed for a later time. After that time has elapsed, they are ready to be processed once they have been identified by the 30-minute check.
Note: Due to the default 30-minute check, there's a risk of resource obstruction during non-business hours. To avoid this, make sure there are no unprocessed items at the end of the working day. If that is not a possibility, ensure the triggered process does not require human intervention.
Numbers used in the algorithm
-
The number of new queue items available in the queue: N
-
The minimum number of items required to trigger the first job: x
-
This means that we will never trigger a job unless there are at least x new items.
-
-
The maximum number of pending and running jobs allowed simultaneously: y
-
This means that we set a ceiling (y) on how many jobs we allow in parallel.
-
-
Another job is triggered for each __ new items: z
-
This means that 1 job is started if x is reached. For the remaining N-x queue items, we will try to start (N-x)/z jobs. If this were to surpass y, we create just enough jobs to reach y in total.
-
When assessing how many additional jobs can be created, we take the current running jobs (w) into account. Based on the Triggers - Queue triggers - Enable pending jobs strategy setting, this number is computed as follows:
-
True - Maximum additional jobs to be created based on newly available queue items = y minus the number of jobs in a Pending state. (This option is best suited for cases where you want Orchestrator to assume that all running jobs have already moved queue items out of the status New.)
-
False - Maximum additional jobs to be created based on newly available queue items = y minus the number of jobs in one of these states: Pending, Resumed, Running, Stopping, Terminating. (This option is best suited for cases where you want Orchestrator to assume all running jobs have yet to move queue items out of the status New.)
Important notes
-
This evaluation happens whenever a single queue item is added, including through bulk add.
-
In order to ensure postponed (deferred) queue items are taken into account, every queue trigger has an associated schedule that rechecks the entire algorithm above. This happens by default every 30 minutes, but can be lowered to a minimum of 10 via the Queues - Unprocessed queue items check frequency (minutes) tenant setting.
-
Historically, it is meant to ensure a job is started once a threshold is reached, and that when that threshold is surpassed, additional jobs are started to help process the increased backlog. It is not meant to distribute workload uniformly across potential machines, but just to ensure that enough jobs are present.
-
There is no hard link between the jobs started and the queue items they were started for, meaning job J is not necessarily meant to take care of queue items a, b, c etc.
-
Algorithm outcomes differ depending on whether queue items were added in bulk or individually, as this influences the number of evaluations performed.
Scenario 1 - queue items added individually
I have two jobs:
- One that adds 3 items per second for 20 seconds to the targeted queue (60 items in total).
- One that processes 1 item per second from the targeted queue.
I have defined my trigger 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
10new item(s).
I launch the job that adds items to my queue.
- After 11 seconds (33 items) the first item-processing job is triggered.
- After another 4 seconds (12 items) the second item-processing job is triggered.
- 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 one 5 items, the third one 1 item. That's 15 items in 20 seconds processed by three jobs.
That means a remainder of 45 items to be processed (60-15). Having 3 jobs, each processing 1 item per second, that means 15 seconds for the remainder to be processed, which leads to a total of 35 seconds.
Scenario 2 - queue items added in bulk
If the 60 queue items mentioned in the scenario above are added with one bulk operation (when no job is running or pending), 3 jobs are created.
If at least one job finishes prior to the reevaluation schedule, further jobs are created.
You can configure several rules depending on which the associated processes get executed.
|
Description | |
|---|---|
|
Account |
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. |
|
Machine |
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. Note: Make sure the required runtime licenses to execute the job are allocated to the associated machine template.
|
|
Hostname |
Hostname After selecting a machine template, the Hostname option is displayed, allowing you to select the desired workstation/robot session to execute the process. All available sessions in the active folder are displayed, either unconnected, disconnected, or connected. Note: Make sure the required runtime licenses to execute the job are allocated to the associated machine template.
|
Queue triggers can also be created by RPA developers at design-time in Studio, using the When New Item Added to Queue activity of the UiPath.Core.Activities package.
Orchestrator identifies these types of triggers as package requirements, and the only way to add them in Orchestrator is from the Package Requirements page.
Any configuration set at design-time is reflected in Orchestrator and cannot be modified.
For example: When a queue item is added to my queue, I want to receive its metadata as a log message.The difference here is that the queue trigger instructs the automation to start from the inside of the workflow, as opposed to Orchestrator queue triggers, which instructs the automation to start from the outside of the workflow.
