2021.10.1
Release date: 7 December 2021
In this patch, we've changed the logic behind queue triggers by accounting for both New and In Progress queue items when computing the number of target jobs that must be reached. Previously, only new items were considered, so whenever there were fewer new items than items in progress, no jobs were launched despite robots being idle. This happened because the number of running jobs (i.e. actively processing queue items) would exceed the number of target jobs (jobs needed to process new items).
Here's an example to better understand the behavior before and after the change:
Say we have a queue trigger defined as follows:
|
Field |
Value |
|---|---|
|
Minimum number of items to trigger the first job: |
1 |
|
Maximum number of pending and running jobs allowed simultaneously |
100 |
|
Another job is triggered for each ___ new item(s) |
1 |
Replication steps and behavior previous to this change:
- Add 3 queue items to the queue. Orchestrator computes the number of target jobs based on the number of new items => 3 target jobs are needed. Orchestrator launches 3 jobs to process the 3 queue items. The 3 items move to In Progress.
- Add another 2 new items to the queue. Orchestrator computes the number of jobs based on the number of new items => 2 target jobs are needed. Orchestrator does not launch any other new jobs since the number of target jobs is lower than the number of running jobs.
- Add another 2 new items to the queue. Orchestrator computes the number of jobs based on the number of new items => 4 (2+2) target jobs are needed. Orchestrator launches 1 job so as to reach the target of 4.
Replication steps and behavior after this change:
- Add 3 queue items to the queue. Orchestrator computes the number of target jobs based on the number of new and in-progress items => 3 target jobs are needed. Orchestrator launches 3 jobs to process the 3 queue items. The 3 items move to In Progress.
- Add another 2 new items to the queue. Orchestrator computes the number of jobs based on the number of new and in-progress items => 5 (3+2) target jobs are needed. Orchestrator launches 2 new jobs to reach the target of 5.
To provide better visibility into runtime issues such as permission problems or connection failures, Orchestrator now logs runtime exceptions to Elasticsearch.
Plug and play your S3 compatible storage with Orchestrator and take advantage of all its unique benefits: scale, cost and reliability.
Starting with this release, the integration with Azure Active Directory (Azure AD) is also available at the organization/tenant level (each organization comprises one tenant).
An integration with Azure AD was already available at the host level, which allows you to leverage it for SSO. With this change, if the Azure AD integration is configured at the organization/tenant level, you benefit from SSO, but also from directory search and automatic user provisioning.
For more information and instructions, see Setting up the Azure AD integration.
From now on, you can give a custom name to the Central Credential Provider web service. To this end, a new field is available when configuring a CyberArk CCP credential store that allows you to set the service name, Web Service Name. Leaving this field empty means the default name is used: AIMWebService.
- In both clean installations and upgrades, Update Server now defaults to the existing Orchestrator database instead of its own database.
We have made the following changes to host-level security settings, available in the host Management portal:
- We now allow the value of the Minimum password length field to be within the range from 1 to 256. Previously, the maximum allowed value was 14.
- We now allow the value of the Days before password expiration field to be within the range from 0 to 1000. Previously, the maximum allowed value was 120.
- The default SignalR setting in Orchestrator (with only the Websocket transport selected) prevents the corresponding remote
robot utility
UiPath.RemoteDebugging.Agent.exefrom executing in multi-node environments (either standalone or Automation Suite installations). To correct this behavior, select all available SignalR transports - WebSocket (default selection), Server-Sent Events (SEE), and Long polling - and enable sticky sessions on the load balancer.
