Abril de 2022

18 de abril de 2022

Compatibilidad con conexiones multicuenta

Nota: esta funcionalidad solo está disponible en los espacios de trabajo personales.

Para dar cabida a proyectos de automatización con conexiones multicuenta, hemos implementado una nueva característica que permite a los propietarios de espacios de trabajo personales ver esas cuentas y especificar una para el lanzamiento del trabajo. Puedes cambiar la cuenta en la pestaña Requisitos del paquete al crear un proceso o editar un proceso existente. Hay disponible un menú desplegable para cada conexión con varias cuentas desde el que se puede ver la lista completa de cuentas disponibles y cambiar la cuenta activa según sea necesario.

Para gestionar las conexiones o añadir nuevas, puedes pasar al servicio de integración haciendo clic en el botón .

Consulta más información sobre las conexiones en la guía del servicio de integración.

Transición de una autenticación basada en cookies a una autenticación basada en tokens

Hemos migrado de una autenticación basada en cookies a una autenticación basada en tokens. Después de este cambio, los intentos de inicio de sesión del usuario ya no se guardan en Orchestrator. Como consecuencia, el punto de conexión /odata/UserLoginAttempts({key}) y la sección Intentos de inicio de sesión correspondiente de la página Mi perfil de Orchestrator se consideran ahora obsoletos y solo ofrecen resultados para los intentos de inicio de sesión realizados antes de este cambio (es decir, los intentos de inicio de sesión con cookies). A partir de ahora, solo puedes accederse a los intentos de inicio de sesión con tokens de acceso desde los registros de auditoría en Automation Cloud. Ponte en contacto con tu administrador para solicitar estos datos.

La autenticación basada en tokens cambia la forma en que Orchestrator registra la última hora de inicio de sesión de un usuario. A partir de ahora, la última hora de inicio de sesión se registra una vez por hora para todos aquellos usuarios que utilizan Orchestrator de manera activa.

Digamos que un usuario utiliza Orchestrator entre las 14:10 y las 15:00. Si se ha autenticado a las 14:10, se mostrará "14:10" como hora de último inicio de sesión hasta la siguiente comprobación por hora. Si se utiliza Orchestrator hasta las 16:00, "15:10" será la hora del último inicio de sesión del usuario.

Aquí se muestran los sitios de la interfaz de usuario de Orchestrator en los que se pueden ver los cambios respecto a cómo calculamos la hora del último inicio de sesión de los usuarios:

• Página Asignar roles (Tenant > Gestionar acceso)

• Página Espacios de trabajo personales (Tenant > Carpetas > Espacios de trabajo personales)

  Nota: como excepción a nuestra cadencia típica de versiones, esta característica no estará disponible para los usuarios Enterprise una semana después de la fecha de lanzamiento para los usuarios Community. En su lugar, se enviará a los usuarios Enterprise en la semana del 2 de mayo.

Autorizar llamadas a API en Swagger

Ahora puedes autorizar llamadas a API en la interfaz de usuario de Swagger mediante OAuth2.

Consulta cómo obtener un token de acceso, enviar solicitudes o revocar el acceso.

Otras mejoras

Orquestación de robots elásticos

• Ahora, si se añade un grupo de robots elásticos a una carpeta, también se añade a cualquier subcarpeta. De este modo, cualquier trabajo de las subcarpetas también puede ejecutarse utilizando la orquestación de robots elásticos.
• Hemos eliminado la restricción de tener solo un grupo por carpeta. ¡Sin límites!

CCP de CyberArk

• Orchestrator es ahora compatible con los certificados .cer como certificados CA raíz del servidor.
• Los errores de configuración de los certificados ahora contienen más información sobre la causa del problema.

5 de abril de 2022

Cloud Robots - Sin servidor (vista previa)

Esta característica solo está disponible para usuarios de la Comunidad.

¿Alguna vez se ha preguntado cómo sería su vida si no tuviera que preocuparse por la infraestructura sobre la que se ejecutan sus automatizaciones?

En los dos últimos meses, nuestra prioridad número uno ha sido hacerlo realidad; y hoy le traemos los robots UiPath de automatización CloudTM, sin servidor o Cloud robots sin servidor para abreviar.

Los clouds robots sin servidor hacen que sea fácil ejecutar la automatización de fondo sin preocuparse por la infraestructura necesaria. Estos le otorgan total libertad de aprovisionamiento, administración, mantenimiento y escalado de cualquier infraestructura subyacente. UiPath gestiona todo el trabajo entre bambalinas para que no tenga que lidiar con los contenedores, máquinas virtuales o servidores físicos.

Ver detalles sobre Automation Cloud Robots - Sin servidor e instrucciones sobre cómo configurarlos.

4 de abril de 2022

Cambio de roles y edición de API

API: Nuevo punto de conexión para asignar roles

Orchestrator tiene ahora disponible un nuevo punto de conexión para las asignaciones de roles o para sobrescribir los roles asignados a una cuenta existente:

POST /odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles

Este punto de conexión se ha mejorado en comparación con nuestros puntos de conexión de usuarios porque asigna roles en función del ID del rol en lugar de en el nombre del rol, lo que hace que sea más fiable.

Puedes encontrar el nuevo punto de conexión en la interfaz de Swagger de la API de Orchestrator, disponible en <OrchestratorURL>/swagger.

Guía de API: Asignar roles

API: cambios de última generación

Con las otras mejoras recientes en los roles (detalles aquí y aquí), que causaron el cambio de nombre de algunos roles, cualquier API que haga referencia a los nuevos nombres necesita actualizarse para utilizar el nuevo nombre del rol.

Esto afecta a lo siguiente:

• Las llamadas a API relacionadas con una versión personalizada de un rol predeterminado que ahora se llama Role name - Custom
  Importante: Estas llamadas siguen funcionando sin realizar ningún cambio, pero el resultado no es el esperado. Es decir, ahora la llamada asigna el rol predeterminado en lugar de la versión personalizada del rol.

• Llamadas a API relacionadas con el antiguo rol Tenant Administrator, que ahora se llama Orchestrator Administrator.

  Estas llamadas generaban un error debido a la incapacidad de encontrar ningún rol con el nombre especificado.

Puntos de conexión afectados

Las siguientes solicitudes pueden asignar un rol en función del nombre del rol:

• POST /odata/Users
• PUT /odata/Users({key})
• PATCH /odata/Users({key})
• POST /odata/Users({key})/UiPath.Server.Configuration.OData.ToggleRole

Corrección

Para solucionar este problema, puedes utilizar el nuevo punto de conexión para asignar roles en función del ID del rol en lugar de en función del nombre del rol.

Existen dos formas de actualizar las integraciones que se vieron afectadas por este cambio, para que funcionen según lo previsto:

A. Añadir una segunda llamada a API (recomendada)

Puedes dejar las solicitudes API existentes sin modificar, pero después de la llamada que asigna roles tendrás que hacer una llamada al nuevo punto de conexión para sobrescribir los roles asignados con los correctos.

Por ejemplo, si tienes una solicitud POST a /odata/Users para crear una cuenta Tenant Administrator (que forma parte del proceso de creación de la cuenta y representa los intentos de solicitud para asignar el rol Tenant Administrator, que ahora se llama Orchestrator Administrator), con posterioridad debes hacer una nueva solicitud POST a /odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles para que pase correctamente el ID de rol para el rol Orchestrator Administrator a fin de que su asignación sea correcta.

Para este método de corrección: debes identificar las solicitudes afectadas en tu integración y, luego, para cada solicitud identificada:

1. Anota el ID de usuario y los nombres de los roles que se asignarán por la solicitud afectada.
2. Haz una solicitud GET a /odata/Roles para recuperar la lista actual de roles.
3. Ten a mano los ID de los nombres de roles que anotaste con anterioridad.

4. (Opcional, pero recomendado) En tu integración, actualiza la solicitud afectada para eliminar la propiedad nombre del rol.

   Con este cambio, la solicitud ya no asigna roles y, la solicitud del paso siguiente gestionará la asignación de roles en el futuro.

   Puedes elegir no eliminar la propiedad del rol de esta solicitud, ya que la solicitud del paso siguiente sobrescribe cualquier rol asignado.

5. Inmediatamente después de la solicitud afectada, añade una solicitud POST a /odata/Users({key})/UiPath.Server.Configuration.OData.AssignRoles, e incluye los ID de los roles en el texto de la solicitud.
   El valor {key} debe ser el ID de usuario de la solicitud afectada.

Esto garantiza que cualquier rol asignado por la solicitud identificada como afectada se sobrescriba de forma inmediata con los roles correctos.

B. Actualizar los nombres de los roles

Un método de corrección más sencillo, pero menos eficaz, es actualizar las solicitudes afectadas con los nombres nuevos de los roles.

Nota: aunque este método es más fácil, te recomendamos que consideres la posibilidad de utilizar el método anterior porque mejora la integración frente a cualquier cambio posterior en los nombres de roles.

Para este método de corrección: debes identificar las solicitudes afectadas en tu integración y, luego, para cada solicitud identificada:

1. Haz una solicitud GET a /odata/Roles para recuperar la lista actual de roles.
2. Apunta el nombre actual de los nombres de los roles que asignan las solicitudes afectadas.
3. En tu integración, actualiza los valores para los nombres de los roles en la solicitud afectada con los nombres de los roles actualizados.

API: aviso de obsolescencia

Debido a los recientes cambios y porque queremos conservar la posibilidad de actualizar los roles en el futuro sin afectarte a ti, queremos notificarte nuestra intención de dejar de utilizar la propiedad nombre de rol en la API de Orchestrator.

Seguiremos admitiendo esta propiedad durante mínimo los próximos 6 meses.

No obstante, se recomienda que comiences a utilizar el nuevo punto de conexión para asignar roles a fin de evitar interrupciones con posterioridad a la obsolescencia.

Mejoras

Hemos aumentado el número máximo de caracteres permitidos para los nombres de los roles de 32 a 64.

Errata del 02 de noviembre de 2022: la carga útil del webhook jobs.created de Test Case ahora muestra la ID del robot concreto y la máquina usada para la ejecución del trabajo.

Corrección de errores

Hemos añadido los permisos Ver a Robots como requisito para poder iniciar o poder crear trabajos en carpetas modernas. Como consecuencia, el botón Iniciar trabajo no estará activo hasta que asignes los permisos requeridos, los cuales se muestran en la información sobre herramientas del propio botón. Hasta ahora, cuando se iniciaban o creaban trabajos en carpetas modernas, se mostraba el mensaje de error You are not authorized! (#0).