2021.10.1

Fecha de lanzamiento: 7 de diciembre de 2021

Novedades

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

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 2021.10.1. Si no estás seguro, permanece atento a los próximos parches en los que se tratará más a fondo el comportamiento.

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 sucedía porque el número de trabajos en ejecución (es decir, procesando activamente elementos de cola) superaba el número de trabajos objetivo (necesarios para procesar nuevos elementos).

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:

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

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

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.

Almacenamiento compatible con S3

Conecta tu almacenamiento compatible con S3 a Orchestrator y aprovecha todas sus ventajas exclusivas: escalabilidad, coste y fiabilidad.

Descubre cómo habilitar proveedores compatibles con S3 para crear depósitos de almacenamiento en Orchestrator.

Descubre cómo crear y configurar depósitos de almacenamiento.

Azure AD a nivel de organización/tenant

A partir de esta versión, la integración con Azure Active Directory (Azure AD) también está disponible a nivel de organización/tenant (cada organización comprende un tenant).

Ya estaba disponible una integración con Azure AD a nivel de host, que te permite usarla para SSO. Con este cambio, si la integración de Azure AD está configurada a nivel de organización/tenant, te beneficias del SSO, pero también de la búsqueda en el directorio y del aprovisionamiento automático de usuarios.

Para obtener más información e instrucciones, consulta Configurar la integración de Azure AD.

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

Configuración

• Tanto en las instalaciones desde cero como en las actualizaciones, el servidor de actualizaciones ahora utiliza de forma predeterminada la base de datos existente de Orchestrator en lugar de su propia base de datos.

Política de contraseñas

Se han realizado los siguientes cambios en la configuración de seguridad a nivel de host, disponibles en el portal de gestión del host:

• Ahora se permite que el valor del campo Longitud mínima de la contraseña esté comprendido entre 1 y 256. Anteriormente, el valor máximo permitido era 14.
• Se permite que el valor del campo Días restantes para que caduque la contraseña esté comprendido entre 0 y 1000. Anteriormente, el valor máximo permitido era 120.

Problemas conocidos

• La configuración predeterminada de SignalR en Orchestrator (con solo el transporte Websocket seleccionado) impide que la correspondiente utilidad de robot remoto UiPath.RemoteDebugging.Agent.exe se ejecute en entornos multinodo (ya sean instalaciones independientes o de Automation Suite). Para solucionar este comportamiento, selecciona todos los transportes disponibles de SignalR (WebSocket (selección predeterminada), Eventos enviados por el servidor (SEE) y Encuesta prolongada) y habilita las sesiones fijas en el equilibrador de carga.