- 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
- 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
- Solución de problemas
- 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
- Los Proyectos de .NET6 dan error de ejecución
Detención de un proceso
Un proceso puede detenerse mediante los comandos Cerrar o Cancelar. El comando puede enviarse desde Orchestrator, UiPath Assistant o Studio.
Cuando el robot recibe el comando Cancelar, cancela la ejecución de la actividad actual y comienza a ejecutar los pasos finales. Si esto tarda más de 3 segundos, el proceso se cierra.
Por otra parte, cuando el robot recibe el comando Cerrar un proceso, primero intenta Cancelar la ejecución, y si la ejecución no finaliza en 3 segundos, el proceso se cierra.
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.
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).
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 de dentro del bloque Finalmente no se finaliza en 3 segundos desde la recepción del comando Cancelar, se cierra toda la ejecución y el proceso general es exitoso en los registros, ya que no se registraron errores en el bloque Captura porque se ha saltado.
- 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.
BusinessError
y SystemError
permanezcan null
y el estado del proceso general se considere exitoso. La conducta descrita es intencionada.
BusinessError
y se SystemError
mantienen null
y el estado del proceso general se considera successful
, ya que no se registraron errores.