- Primeros pasos
- Mejores prácticas
- Tenant
- Acciones
- Contexto de carpetas
- Automatizaciones
- Procesos
- Trabajos
- Desencadenadores
- Registros
- Supervisión
- Colas
- Activos
- Depósitos de almacenamiento
- Test Suite - Orchestrator
- Catálogos de acciones
- Perfil
- Administrador de sistema
- Servidor de identidad
- Autenticación
- Otras configuraciones
- Integraciones
- Robots clásicos
- Solución de problemas
Guía del usuario de Orchestrator
Trabajos
Un trabajo representa la ejecución de un proceso en UiPath Robot. Puedes iniciar la ejecución de un trabajo en modo atendido o desatendido. No puedes iniciar un trabajo desde Orchestrator en robots atendidos, y no se pueden ejecutarse con la pantalla bloqueada.
|
Modo atendido |
modo no atendido |
|---|---|
|
Página Automatización > Trabajos Página Automatización > Desencadenadores Página Automatización > Procesos |
En Orchestrator hay tres ubicaciones que te permiten configurar un trabajo: las páginas Trabajos, Desencadenadores y Procesos. El centro de control de trabajos está representado por la página Trabajos, donde puedes supervisar los trabajos ya iniciados los trabajos iniciados, ver sus detalles y los registros y detener/reanudar/reiniciar un trabajo.
Por defecto, cualquier proceso podrá ser editado mientras tenga trabajos asociados en ejecución o pendientes.
Los trabajos en ejecución asociados a un proceso modificado utilizan la versión inicial del proceso. La versión actualizada se usa para los trabajos recién creados o en el siguiente desencadenador del mismo trabajo.
Los trabajos pendientes asociados a un proceso modificado utilizan la versión actualizada.
Hay tres fuentes de trabajo posibles, dependiendo del mecanismo de inicio:
- Manual: el trabajo se ha iniciado y configurado desde las páginas Trabajos/Desencadenadores/Procesos, utilizando el botón Iniciar.
- Agente: el trabajo se ha iniciado en modo atendido desde la bandeja del Robot UiPath, UiPath Assitant o mediante la línea de comandos.
- [Trigger_Name]: el trabajo se ha iniciado mediante un desencadenador, utilizado para la ejecución de trabajos preparados.
|
Descripción | |
|---|---|
|
Asignar dinámicamente |
Un proceso en primer plano se ejecuta varias veces con el usuario y la máquina que estén disponibles primero. Si el usuario está seleccionado, solo se realiza la asignación de máquina de forma dinámica. Los procesos en segundo plano se ejecutan en cualquier usuario, independientemente de si este está ocupado o no, siempre y cuando tengas tiempos de ejecución suficientes. Puedes ejecutar un proceso hasta 10 000 veces. |
|
Robots específicos |
El proceso es ejecutado por determinados Robots, seleccionados en la lista de robots. |
En la máquina del host, es necesario aprovisionar de un usuario de Windows a cada usuario que pertenezca a las carpetas a las que se asigna la plantilla de máquina correspondiente.
Supongamos que conectas un servidor a Orchestrator mediante la clave generada por la plantilla de la máquina, FinanceT. Esa plantilla se asigna a las carpetas FinanceExecution y FinanceHR, donde también se asignan 6 usuarios, que deben aprovisionarse como usuarios de Windows en el servidor.
Si configuras un trabajo para ejecutar el mismo proceso varias veces, se crea un entrada de trabajo para cada ejecución. Los trabajos se ordenan en función de su prioridad y tiempo de creación, siendo los más prioritarios y antiguos los primeros en la cola. Tan pronto un robot está disponible, este ejecuta el siguiente trabajo en la cola. Hasta entonces, los trabajos permanecen en estado pendiente.
Configuración
- 1 carpeta
- 1 plantilla de la máquina con dos tiempos de ejecución
- 2 usuarios: john.smith y petri.ota
- 2 procesos que requieren interacciones de usuario: P1, que añade elementos de cola a una cola; P2, que procesa los elementos de la cola
- La plantilla de máquina y los usuarios deben estar asociados a la carpeta que los contiene los procesos.
Resultado deseado
- P1 se ejecuta con una alta prioridad por cualquiera.
- P2 se ejecuta con una baja prioridad por petri.ota.
Configuración de trabajo requerido
- Inicia un trabajo utilizando P1, no lo asignes a ningún usuario concreto, establece la prioridad en Alta.
Inicia un trabajo para P2, asignándolo petri.ota, establece la prioridad en Baja.
Puedes controlar qué trabajo tiene prioridad sobre otros trabajos a través del campo Prioridad del trabajo, ya sea al desplegar el proceso o al configurar un trabajo/desencadenador para ese proceso. Un trabajo puede tener una de las siguientes prioridades: Baja (↓), Normal (→), Alta (↑).
La prioridad se hereda desde la configuración inicial. Puedes dejarla como está o cambiarla.
-
Página deautomatizaciones > Trabajos: hereda la prioridad establecida en el nivel de proceso.
-
Página de automatizaciones > Desencadenadores: hereda la prioridad establecida en el nivel de desencadenador.Si el propio desencadenador hereda la prioridad en el nivel del proceso, entonces se utiliza esa.
-
Página deautomatizaciones > Procesos: utiliza la prioridad establecida para ese proceso.
Si configuras un trabajo para ejecutar el mismo proceso varias veces, se crea un entrada de trabajo para cada ejecución. Los trabajos se ordenan en función de su prioridad y tiempo de creación, siendo los más prioritarios y antiguos los primeros en la cola. Tan pronto un robot está disponible, este ejecuta el siguiente trabajo en la cola. Hasta entonces, los trabajos permanecen en estado pendiente.
La prioridad se establece por defecto en Heredada, es decir, heredará el valor establecido en el nivel del proceso.Al elegir un proceso se actualizará automáticamente el icono de flecha para ilustrar el valor establecido en el nivel de proceso.Cualquier trabajo iniciado por el desencadenador tiene la prioridad establecida en el nivel del desencadenador. Si se mantiene la prioridad Heredada predeterminada, los trabajos se inician con la prioridad en el nivel del proceso.
Hay dos tipos de procesos, según los requisitos de interfaz de usuario:
Proceso en segundo plano : no requiere una interfaz de usuario ni la intervención de un usuario para ejecutarse. Por esta razón, puedes ejecutar varios trabajos en el modo no asistido con el mismo usuario simultáneamente. Cada ejecución requiere una licencia No atendida/NonProduction.Los procesos en segundo plano se ejecutan en la Sesión 0 cuando se inician en el modo no asistido.
Requiere Interfaz de usuario: requiere una interfaz de usuario, ya que la ejecución necesita que se genere la IU, o el proceso contiene actividades interactivas, como Hacer clic. Solo puedes ejecutar un proceso en un usuario a la vez.
Un mismo usuario puede ejecutar varios procesos en segundo plano y un único proceso que requiera IU al mismo tiempo.
Si se inicia un trabajo en varios UiPath Robots de alta densidad desde la misma máquina de Windows Server, proceso seleccionado es ejecutado por cada robot especificado, al mismo tiempo. Se crea una instancia para cada una de esas ejecuciones, que será mostrada en la página Trabajos.
Si estás utilizando Robots de Alta Densidad y no habilitaste RDP en esa máquina, cada vez que inicies un trabajo, se mostrará el siguiente error: "La sesión de inicio de sesión especificada no existe. Puede que ya se haya terminado". Para ver cómo configurar tu máquina para los robots de alta densidad, consulta la página Cómo configurar Windows Server para robots de alta densidad.
Los procesos que requieren fragmentación lógica o intervención humana (validaciones, aprobaciones, gestión de excepciones), como el procesamiento de facturas y las revisiones de rendimiento, se gestionan con un conjunto de instrumentos en la suite UiPath: una plantilla de proyecto de acciones dedicada en Studio llamada Proceso de Orchestration y las capacidades de asignación de recursos en Orchestrator.
A grandes rasgos, se configura el flujo de trabajo con un par de actividades. El flujo de trabajo puede parametrizarse con las características específicas de la ejecución, de forma que un trabajo suspendido solo puede reanudarse si se cumplen determinados requisitos. Solo cuando se cumplen dichos requisitos se asignan los recursos para la reanudación del trabajo, garantizando así que no haya malgasto en términos de consumo.
Esto queda reflejado en Orchestrator al quedar el trabajo suspendido, esperando a que se cumplan los requisitos, y luego haciendo que se reanude el trabajo y se ejecute como de costumbre.Dependiendo del par utilizado, los requisitos de finalización cambian y la respuesta de Orchestrator se ajusta en consecuencia.
|
Actividades |
Caso de uso |
|---|---|
|
Introduce la condición de un trabajo, como cargar elementos en colas. Una vez se haya suspendido el trabajo principal, se ejecutará el trabajo auxiliar. Una vez finalizado este proceso, se reanudará el trabajo principal. Dependiendo de cómo configuraste tu flujo de trabajo, el trabajo reanudado puede utilizar los datos obtenidos de la ejecución de los procesos auxiliares.
|
|
Actividades |
Caso de uso |
|---|---|
|
Introduce una condición de las colas, como procesar los elementos en colas. Una vez que se haya suspendido el trabajo principal, los elementos en cola deberán procesarse mediante el trabajo auxiliar. Una vez finalizado este proceso, se reanudará el trabajo principal. Dependiendo de cómo se configuró el flujo de trabajo, el trabajo reanudado puede utilizar los datos de salida obtenidos de la ejecución de los elementos en cola procesados. |
Acciones de formulario
|
Actividades |
Caso de uso |
|---|---|
|
Introduce las condiciones de intervención del usuario, que aparecen en Orchestrator como acciones. Una vez suspendido el trabajo, se generará una acción en Orchestrator (tal y como se configuró en Studio). Solo tras la finalización de la acción, se reanudará el trabajo. El usuario asignado es quien debe finalizar las acciones del formulario. La asignación del usuario puede gestionarse directamente en Orchestrator o a través de la actividad Asignar tareas. |
Acciones externas
|
Actividades |
Caso de uso |
|---|---|
|
Introduce las condiciones de intervención del usuario, que aparecen en Orchestrator como acciones. Una vez suspendido el trabajo, se generará una acción en Orchestrator (tal y como se configuró en Studio). Solo tras la finalización de la tarea, se reanudará el trabajo. Cualquier usuario puede completar las acciones externas con permisos de Edición sobre las acciones, además de acceder a la carpeta asociada. |
Acciones de validación de documentos
|
Actividades |
Caso de uso |
|---|---|
|
Introduce las condiciones de intervención del usuario, que aparecen en Orchestrator como acciones. Una vez suspendido el trabajo, se generará una acción en Orchestrator (tal y como se configuró en Studio). Solo tras la finalización de la tarea, se reanudará el trabajo. El usuario asignado es quien debe completar las acciones de Validación de documentos. La asignación del usuario puede gestionarse directamente en Orchestrator o a través de la actividad Asignar tareas. Para que el Robot se cargue, descargue y elimine datos de un depósito de almacenamiento, debe disponer de los permisos correspondientes. Esto se puede hacer actualizando el rol de Robot con lo siguiente:
|
Para cargar los datos del documento:
Para eliminar los datos del documento después de la descarga:
|
Actividades |
Caso de uso |
|---|---|
|
Introduce un intervalo de tiempo como retraso, durante el cual se suspenderá el flujo de trabajo. Una vez que haya pasado el retardo, se reanudará el trabajo. |
No se limita la fragmentación del trabajo a su ejecución por el mismo Robot. Puede ser ejecutada por cualquier Robot disponible cuando el trabajo se reanuda y esté listo para la ejecución. Esto también depende del destino de ejecución configurado al definir el trabajo.
Ejemplo
He definido mi trabajo para que lo ejecuten unos Robots específicos, por ejemplo X, Y y Z. Cuando inicio el trabajo, solo el Robot Z está disponible, así que mi trabajo será ejecutado por este hasta que sea suspendido a la espera de validación del usuario. Tras la validación, cuando se reanuda el trabajo, solo el Robot X está disponible, así que este será el que ejecute el trabajo.
- Desde el punto de vista del seguimiento, un trabajo de este tipo se cuenta como uno solo, independientemente de que esté fragmentado o sea ejecutado por diferentes Robots.
- Los trabajos suspendidos no pueden asignarse a Robots, solo los reanudados pueden reasignarse.
Para comprobar los desencadenadores necesarios para la reanudación de un trabajo suspendido, consulta la ficha Desencadenadores en la ventana Detalles del trabajo.
Para los trabajos desatendidos fallidos, si tu proceso tenía activada la opción Habilitar grabación, puedes descargar los soportes de ejecución correspondientes para comprobar los últimos momentos de la ejecución antes del fallo.
La opción Descargar grabación solo se muestra en la ventana Trabajos si tienes permisos de visualización en los medios de ejecución.
