2021.10.1

Release date: 7 December 2021

What’s New

New Mechanism for Launching Jobs Via Queue Triggers

Important: This release marks a significant change in how Orchestrator launches jobs via queue triggers. The new behavior is enabled by default and cannot be turned off. Read the release note carefully before upgrading to 2021.10.1. If you are unsure, stay tuned for the next patches in which we will further address the behavior.

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:

1. 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.
2. 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.
3. 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:

1. 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.
2. 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.

Logging Runtime Exceptions to Elasticsearch

To provide better visibility into runtime issues such as permission problems or connection failures, Orchestrator now logs runtime exceptions to Elasticsearch.

S3 Compatible Storage

Plug and play your S3 compatible storage with Orchestrator and take advantage of all its unique benefits: scale, cost and reliability.

Learn how to enable S3 compatible providers for creating storage buckets in Orchestrator.

Learn how to create and configure storage buckets.

Azure AD at the Organization/tenant Level

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.

Custom AIMWebserviceName

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.

Improvements

Setup

• In both clean installations and upgrades, Update Server now defaults to the existing Orchestrator database instead of its own database.

Password Policy

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.

Known Issues

• The default SignalR setting in Orchestrator (with only the Websocket transport selected) prevents the corresponding remote robot utility UiPath.RemoteDebugging.Agent.exe from 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.