- Notas relacionadas
- Primeros pasos
- Asistente de UiPath
- Instalación y actualización
- Tipos de robot
- Componentes de robot
- Licencia
- Conexión de los robots a Orchestrator
- Procesos y actividades
- Registro
- Robot JavaScript SDK
- Situaciones concretas
- Reinicio de componentes de UiPath Robot
- Sesiones de Windows
- Inicio de sesión usando el sistema de credenciales de Thales Luna
- Inicio de sesión utilizando el proveedor de almacenamiento de clave nShield
- Redirección de Robots a través de un servidor proxy
- Ejecución de tareas en una ventana RDP minimizada
- Uso de unidades de red asignadas
- Detención de un proceso
- Botón de deshabilitación de detención
- Carpetas de paquetes y rutas de red personalizadas
- Integración de CrowdStrike
- Robot de virtualización de apps citrix
- Solución de problemas
- Errores comunes de conexión
- Robot que no responde sobre RDP
- Registros de ejecución duplicados
- Errores de robot encontrados con frecuencia
- Aumento de la duración de la ejecución de proceso
- Exigencia de la verificación de la firma de paquetes
- Mensaje demasiado grande para procesarlo
- Errores al ejecutarse como administrador
- Los paquetes NuGet no son accesibles tras la migración
- Actividades de diálogo de control de acceso de usuario y automatización de IU
- Se requiere .NET durante la instalación
- El ensamblado no se puede cargar desde la red o compartir archivos de Azure
- Las actividades no pueden encontrar .NET Runtime
Detención de un proceso
Un proceso puede detenerse bien mediante comandos de Parada suave o de Terminación.
El comando de Parada suave marca el proceso en un estado de debería pararse. Este estado puede consultarse desde el flujo de trabajo aún en ejecución usando la actividad Debería parar. El flujo de trabajo debe manejar de forma explícita este estado y finalizar. El flujo de trabajo no se detiene automáticamente sin manejar el estado de debería parar. Consulta REFramework para ver un escenario que aprovecha la Parada suave.
El comando Parar está diseñado para automatizaciones desatendidas y está disponible solamente en Orchestrator. En Orchestrator, el comando Parada suave se llama Parada.
El comando Terminar primero envía una solicitud de Cancelar al flujo de trabajo. La solicitud de Cancelar del flujo de trabajo es diferente de debería parar.Cancelar es una señal del flujo de trabajo que se maneja de forma automática por parte del flujo de trabajo. La señal hace que las actividades se cancelen en cascada mientras permite que los bloques Finalmente del flujo de trabajo ejecuten pasos de limpieza. Si la señal de Cancelar no detiene el flujo de trabajo en tres segundos, el trabajo se finaliza deteniendo a la fuerza cualquier actividad en ejecución en cualquier punto de su ejecución.
El comando Terminar está diseñado para automatizaciones atendidas y está disponible en Orchestrator y en clientes de escritorio y API tales como Assistant, Studio, RobotJS. En clientes de escritorio, el comando Finalizar se llama Parada.
REFramework aprovecha el comando Parada suave.
BusinessError
y SystemError
permanezcan null
y el estado del proceso general se considere exitoso. La conducta descrita es intencionada.
Situación de intento de captura
Durante un flujo de trabajo de intento de captura, cuando se detiene un proceso, el estado de la transacción se puede mostrar como exitoso cuando en realidad no se ha completado.
Cancelación de un proceso
Si la ejecución está en el bloque Prueba o Captura cuando el robot recibe el comando Cancelar, salta al bloque Finalmente que comprueba cualquier error. Si no se encuentran errores, entonces el bloque Finalmente cree que la ejecución se ha completado con éxito, ya que no hay eventos de fallo (están en blanco).
Cierre de un proceso
Si la ejecución está en el bloque Prueba o Captura cuando el robot recibe el comando Cerrar, primero intenta Cancelar el proceso, saltando al bloque Finalmente. Si la lógica dentro del bloque Finalmente no finaliza en tres segundos desde que se recibe el comando Cancelar, se detiene toda la ejecución y el proceso en general es exitoso en los registros ya que no se registraron errores en el bloque Capturar ya que fue omitido.
Evitar falsos positivos
- Establecer el estado del proceso en
Successful
debe realizarse solo dentro del bloque Prueba, después de completar la lógica comercial. - Establecer el estado como
Failed
solo debe realizarse dentro del bloque Captura, después de completar la lógica de manejo de error. - En el bloque Finalmente solo debe haber presente lógica de limpieza, ya que se ejecuta independientemente de si la ejecución tuvo éxito o no.