2020.10.14

Release date: 7 December 2021

What’s New

New Mechanism for Launching Jobs Via Queue Triggers

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 would exceed the number of target jobs (i.e. actively processing queue 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.

   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 2020.10.14. If you are unsure, stay tuned for the next patches in which we will further address the behavior.

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.

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.

Setup Improvements

We introduced four new command line parameters to add flexibility in configuring and customizing the connections to your Orchestrator databases. Include them in an Orchestrator silent installation command, either clean installations or upgrades. You can also add the new parameters in the parameters.JSON file.

Find out which are the new parameters and see some examples on how to use them in our installation guide.

Known Issues

Upon changing the mechanism behind GenerateReportsJob (the background job computing stats on the Queues page) from incremental to partition swapping you will run into following error: "The 'LastQueueItemEventProcessed' property on 'UiQueueProcessingRecordBase' could not be set to a 'null' value". As a workaround set the QueueProcessingRecords.LastQueueItemEventProcessedd field in the database to 0 by using the following query: UPDATE [dbo].[QueueProcessingRecords] SET [LastQueueItemEventProcessed] = 0 WHERE [LastQueueItemEventProcessed] IS NULL.

Bug Fixes

• The GetPassword command did not work correctly when the Plugins.SecureStores.CyberArk.UsePowerShellCLI app setting was enabled - the output was not formatted correctly. The issue has been fixed and the output fields for the GetPassword command are now properly formatted.
• Using CyberArk AAM credential stores with Path authentication (Plugins.SecureStores.CyberArk.UsePowershellCLI set to true) failed with the following error message: Failed to retrieve robot password from UiPath.Orchestrator.SecureStore.CyberArk.CyberArkAimSecureStore storeUiPath.Orchestrator.Extensibility.SecureStores.SecureStoreException: Could not find password! Reason: '.\GetCredential.bat : The term '.\GetCredential.bat' is not recognized as the name of a cmdlet, function, script file, or operable program.
  This happened due to the GetCredentials.bat file being published to Orchestrator installation folder instead of the Plugins folder. The file is now published to the Plugins folder.
• Deadlocks would occur in Orchestrator 2020.10.10 environments where queue item processing took less than a second per queue item. Processes would throw multiple "An error has occurred. Error code: 0" errors before crashing. The issue has been fixed and you are now able to process queue items without running into deadlocks.
• Deleting execution media by making POST requests to the /odata/ExecutionMedia/UiPath.Server.Configuration.OData.DeleteMediaByJobId endpoint now requires Delete permissions on Execution Media, whereas previously you needed View permissions.
• The Set Asset and Set Credential activities timed out for assets targeting a large number of robots. We added a new improved mechanism for setting robot values that involves a new API endpoint: /odata /Assets /UiPath.Server.Configuration.OData.SetRobotAssetByRobotKey.
• The decryption of the Orchestrator connection string was affected by an issue causing the Webhooks client not to work. We have fixed the problem.
• In multi-node environments, the connection string of all nodes must be identical. Make sure there are no inconsistencies as this would cause the nodes to have different connection strings and could trigger errors. Note that even small mismatches such as an extra space would lead to an issue.