2020.10.14

Fecha de lanzamiento: 7 de diciembre de 2021

Novedades

Nuevo mecanismo para lanzar trabajos a través de desencadenadores de cola

En este parche, se ha cambiado la lógica de los desencadenadores de cola, teniendo en cuenta tanto los elementos de cola nuevos como los que están en curso, a la hora de calcular el número de trabajos objetivo que deben lograrse. Antes, solo se tenían en cuenta los artículos nuevos, por lo que cuando había menos elementos nuevos que en curso, no se lanzaba ningún trabajo a pesar de que los robots estuvieran inactivos. Esto se debe a que el número de trabajos en ejecución superaba el número de trabajos de destino (es decir, artículos en cola procesándose de forma activa).

A continuación, se muestra un ejemplo para entender mejor el comportamiento antes y después del cambio:

Supongamos que tenemos un desencadenador de cola definido de la siguiente manera:

Campo	Valor
Número mínimo de elementos para desencadenar el primer trabajo:	1
Número máximo de trabajos en ejecución y pendientes permitidos de forma simultánea	100
Se desencadenará otro trabajo para cada __ nuevo elemento	1

Pasos y comportamiento de la replicación previos a este cambio:

Añade 3 elementos de cola a la cola. Orchestrator calcula el número de trabajos de destino en función del número de elementos nuevos => se necesitan 3 trabajos de destino. Orchestrator lanza 3 trabajos para procesar los 3 elementos de cola. Los 3 elementos pasan a estar en curso.
Añade otros 2 nuevos elementos a la cola. Orchestrator calcula el número de trabajos de destino en función del número de elementos nuevos => se necesitan 2 trabajos de destino. Orchestrator no lanza ningún otro trabajo nuevo, ya que el número de trabajos de destino es menor que el número de trabajos en ejecución.
Añade otros 2 nuevos elementos a la cola. Orchestrator calcula el número de trabajos de destino en función del número de elementos nuevos => se necesitan 4 (2+2) trabajos de destino. Orchestrator lanza 1 trabajo para lograr el objetivo de 4.

Pasos y comportamiento de la replicación posteriores a este cambio:

Añade 3 elementos de cola a la cola. Orchestrator calcula el número de trabajos de destino en función del número de elementos nuevos y en curso => se necesitan 3 trabajos de destino. Orchestrator lanza 3 trabajos para procesar los 3 elementos de cola. Los 3 elementos pasan a estar en curso.
Añade otros 2 nuevos elementos a la cola. Orchestrator calcula el número de trabajos de destino en función del número de elementos nuevos y en curso => se necesitan 5 (3+2) trabajos de destino. Orchestrator lanza 2 nuevos trabajos para lograr el objetivo de 5.

Importante: Esta versión marca un cambio significativo en la forma en que Orchestrator lanza trabajos a través de desencadenadores de cola. El nuevo comportamiento está habilitado de forma predeterminada y no se puede desactivar. Lee atentamente la nota de la versión antes de actualizar a la 2020.10.14. Si no estás seguro, permanece atento a los próximos parches en los que se tratará más a fondo el comportamiento.

Registrar excepciones en tiempo de ejecución en Elasticsearch

Con el fin de proporcionar una mejor visibilidad de los problemas en tiempo de ejecución, como los problemas de permisos o los fallos de conexión, Orchestrator ahora registra las excepciones en tiempo de ejecución en Elasticsearch.

Parámetro AIMWebserviceName personalizado

A partir de ahora, puedes asignar un nombre personalizado al servicio web del proveedor de credenciales central. Para ello, al configurar un almacén de credenciales de CyberArk CCP se dispone de un nuevo campo que permite establecer el nombre del servicio, Nombre del servicio Web. Si dejas el campo vacío, se utilizará el nombre predeterminado AIMWebService.

Mejoras en la configuración

Se han introducido cuatro nuevos parámetros de línea de comandos para añadir flexibilidad a la hora de configurar y personalizar las conexiones con las bases de datos de Orchestrator. Inclúyelos en un comando de instalación silenciosa de Orchestrator, ya sean instalaciones desde cero o actualizaciones. También puedes añadir los nuevos parámetros en el archivo parameters.JSON.

Descubre cuáles son los nuevos parámetros y ve algunos ejemplos sobre cómo utilizarlos en nuestra guía de instalación.

Problemas conocidos

Al cambiar el mecanismo detrás de GenerateReportsJob (las estadísticas de cálculo del trabajo en segundo plano en la página Colas) de incremental a intercambio de particiones, se encontrará con el siguiente error: "La propiedad 'LastQueueItemEventProcessed' en 'UiQueueProcessingRecordBase' no se pudo establecer en 'nulo' valor ". Como solución alternativa, establece el campo QueueProcessingRecords.LastQueueItemEventProcessedd de la base de datos en 0 utilizando la siguiente consulta: UPDATE [dbo].[QueueProcessingRecords] SET [LastQueueItemEventProcessed] = 0 WHERE [LastQueueItemEventProcessed] IS NULL.

Corrección de errores

El comando GetPassword no funcionaba correctamente cuando la configuración de la aplicación Plugins.SecureStores.CyberArk.UsePowerShellCLI estaba habilitada; la salida no tenía el formato correcto. El problema se ha solucionado y los campos de salida para el comando GetPassword ahora tienen el formato correcto.
El uso de los almacenes de credenciales de CyberArk AAM con la autenticación Path (Plugins.SecureStores.CyberArk.UsePowershellCLI establecido/a como true) generaba el siguiente mensaje de error: 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.

Esto ocurría debido a que el archivo GetCredentials.bat se publicaba en la carpeta de instalación de Orchestrator en lugar de la carpeta Plugins. El archivo se publica ahora en la carpeta Plugins.
Los interbloqueos se producían en entornos de Orchestrator 2020.10.10 en los que el procesamiento de los artículos en cola tardaba menos de un segundo por cada uno. Los procesos podían mostrar numerosos errores del tipo "An error has occurred. Código de error: 0" antes de bloquearse. El problema se ha solucionado y ya puedes procesar artículos en cola sin bloqueos.
La eliminación de soportes de ejecución mediante solicitudes POST al punto final /odata/ExecutionMedia/UiPath.Server.Configuration.OData.DeleteMediaByJobId requiere ahora permisos de eliminación en los soportes de ejecución, mientras que antes se necesitaban permisos visualización.
El tiempo de espera de las actividades Establecer activo y Establecer credencial se agotaba en el caso de los activos destinados a un gran número de robots. Hemos añadido un nuevo mecanismo mejorado para establecer los valores del robot que implica un nuevo punto final de la API: /odata /Assets /UiPath.Server.Configuration.OData.SetRobotAssetByRobotKey.
El descifrado de la cadena de conexión de Orchestrator se ha visto afectado por un problema que hacía que el cliente de Webhooks no funcionara. Hemos solucionado el problema.
En entornos multinodo, la cadena de conexión de todos los nodos debe ser idéntica. Asegúrate de que no haya incoherencias, ya que esto haría que los nodos tuvieran diferentes cadenas de conexión y podría desencadenar errores. Tenga en cuenta que incluso los pequeños desajustes, como un espacio adicional, podrían generar problemas.