2021.10.4

Fecha de publicación: 7 de abril de 2022

Mecanismo (más) reciente para lanzar trabajos a través de desencadenadores de colas

Tras una serie de avances y retrocesos en el ámbito de los desencadenadores de cola, se ha reajustado la forma en que los desencadenadores de cola lanzan los trabajos con lo que se espera que sea la última y mejor implementación de todos ellos.

Planteamiento del problema: cada vez que sus colas contenían menos elementos nuevos que elementos en curso, no se lanzaba ningún trabajo a pesar de que los robots estaban inactivos. Esto ocurría porque el número de trabajos en ejecución (que procesan activamente los elementos de cola) superaba el número de trabajos objetivo (trabajos necesarios para procesar los nuevos elementos).

Corrección inicial: Orchestrator tenía en cuenta tanto los elementos de cola nuevos como los que estaban en curso al calcular el número de trabajos de destino, en lugar de tener en cuenta solo los nuevos. Suena bien. No funcionaba.

Nueva y brillante solución: Orchestrator tiene en cuenta los nuevos elementos al calcular el número de trabajos de destino, pero tiene en cuenta el número de trabajos pendientes a la hora de decidir si se lanza un nuevo trabajo o no.

• Supongamos que tienes 2 nuevos artículos en una cola y que existen 2 trabajos pendientes => en ese caso, no se lanzan nuevos trabajos.
• Supongamos que tienes 2 nuevos artículos y que existe 1 trabajo pendiente => en ese caso, se lanza 1 nuevo trabajo.

Esto garantiza que Orchestrator lance suficientes trabajos para procesar todos los nuevos elementos sin excederse.

Mejoras

• Sabemos que las tablas de las bases de datos de Ledger pueden llegar a estar saturadas, por lo que deben limpiarse con relativa frecuencia. Para ello, te proporcionamos un nuevo script de limpieza que permite eliminar los datos de Ledger cada 7 días y aplicar un tamaño de 1000 entradas a los lotes. Descubre el nuevo script en nuestra documentación:

  • Instalación independiente de Orchestrator
  • Instalación de Automation Suite

Problemas conocidos

• Como host, intentar detener una ventana de mantenimiento a través de la interfaz de usuario de Swagger puede fallar. Esto ocurre porque la interfaz de usuario de Swagger utiliza cookies para la autenticación, las cuales se pierden al cerrar el navegador.

  Para detener el modo de mantenimiento a través de API, sigue alguno de los siguientes métodos:

  • No cierres el navegador y realiza la solicitud POST a /api/Maintenance/End desde la interfaz de usuario de Swagger.

  • Utiliza una aplicación de pruebas de API (por ejemplo, Postman) para:

    • recuperar un token de acceso intercambiando sus credenciales en el punto final /api.Account/Authenticate y
    • realiza una solicitud POST al punto final /api/Maintenance/End utilizando el encabezado Authorization: Bearer {access_token}.

  • Ejecute el siguiente script de PowerShell:

$orchestratorUrl="https://localhost:6234"
$hostTenant="host"
$hostUser="admin"
$hostPassword=""
$tenantId="" #number

# Authenticate
$body=@{
    "tenancyName"="$hostTenant";
    "usernameOrEmailAddress"="$hostUser";
    "password"="$hostPassword"
}

$response = Invoke-WebRequest -Uri "$orchestratorUrl/api/account/authenticate" -Method Post -Body ($body | ConvertTo-Json) -ContentType "application/json"
$token = "Bearer " + ($response | ConvertFrom-Json).result

# End maintenance mode

$headers=@{
    "Authorization"="$token"
}

$res = Invoke-WebRequest -Uri "$orchestratorUrl/api/maintenance/end?tenantId=$tenantId" -Headers $headers -Method Post -ContentType "application/json" -ErrorAction Stop

if ($res -and ($res.StatusCode -eq 200)) {
    Write-Host "Maintenance mode ended successfully for tenant $tenantId"
}

Corrección de errores

• Se ha solucionado un problema que permitía que un atacante con privilegios de acceso a un robot recuperara el valor de LicenseKey (MachineKey) de otros robots dentro del mismo tenant forzando las llamadas a API a Orchestrator. Esto permitía teóricamente que al atacante accediese a los recursos restringidos solo a ese robot.

  Lee la alerta de seguridad para UiPath: Apropiación de cuentas de robots.

• Ocasionalmente, las ejecuciones de trabajos de flujos de trabajo de larga duración se quedaban bloqueadas en el estado de "Ejecución" sin pasar al estado de "Suspendido". Cuando se eliminaban, los trabajos pasaban de fase y se bloqueaban en el estado de «Terminando». El problema subyacente se ha solucionado y los trabajos de larga duración ahora pasan por los distintos estados según lo previsto y se ejecutan sin complicaciones.
• Para la versión en inglés, hemos cometido un error tipográfico en la ventana Asignar roles a una cuenta de robot. Concretamente, en el campo correspondiente a la búsqueda de una cuenta de robot (Search for a robot account). El nombre del campo ya está escrito correctamente.
• Los nombres de los paquetes cargados manualmente no se mostraban en los detalles de auditoría. Este problema afectaba a los paquetes cargados tanto de manera individual como en bloque. Ahora, los nombres de todos los paquetes cargados se registran correctamente en los detalles de auditoría.
• Los usuarios que no tenían un Apellido especificado en Active Directory no podían iniciar sesión.