- Notes de publication
- Démarrage
- Assistant UiPath
- Installation et mise à niveau
- Types de robot
- Composants du Robot
- Licences
- Connexion des Robots à Orchestrator
- Processus et activités
- Journalisation
- Robot JavaScript SDK
- Scénarios spécifiques
- Sessions Windows
- Connexion à l’aide du système d’informations d’identification Thales Luna
- Connexion à l’aide du fournisseur de services de chiffrement nShield
- Rediriger les Robots vers un serveur proxy
- Exécuter des tâches à partir d'une session de bureau à distance minimisée
- Utilisation de lecteurs réseau mappés
- Arrêter un processus :
- Désactiver le bouton Arrêt
- Dossiers de paquets personnalisés et chemins d'accès réseau
- Intégration de CrowdStrike
- Résolution des problèmes
- Robot ne répond pas sur RDP
- Journaux d'exécution en double
- Erreurs du Robot fréquemment rencontrées
- Augmentation de la durée d'exécution des processus
- Vérification forcée de la signature des paquets
- Message trop volumineux pour être traité
- Erreurs lors de l’exécution en tant qu’administrateur
- Les packages NuGet ne sont pas accessibles après la migration
- Invite de contrôle d'accès utilisateur et activités d'automatisation de l'interface utilisateur
- Échec de l’exécution des projets .NET6
Guide de l'utilisateur du Robot
Arrêter un processus :
Un processus peut être arrêté par des commandes Kill ou Cancel. La commande peut être envoyée depuis Orchestrator, Assistant ou Studio.
Lorsque le robot reçoit la commande Annuler, il annule l’exécution de l’activité en cours et commence à exécuter les dernières étapes. Si cela prend plus de 3 secondes, le processus est arrêté de force.
D’autre part, lorsque le robot reçoit la commande de forcer l’arrêt d'un processus, il essaie d’abord d’annuler l’exécution et si l’exécution n’est pas terminée dans les 3 secondes, le processus est arrêté de force.
Au cours d'un flux de travail Essayer de capturer, lorsqu'un processus est arrêté, l'état de la transaction peut s'afficher comme réussie alors qu'elle n'est pas terminée.
Si l’exécution se trouve dans le bloc Try ou Catch lorsque la commande Annuler est reçue par le Robot, elle passe au bloc Finally qui vérifie les erreurs. Si aucune erreur n’est trouvée, le bloc Finally considère que l’exécution s’est terminée avec succès car il n’y a pas d’événements d’échec (ils sont vides).
Si l’exécution est dans le bloc Try ou Catch lorsque la commande Kill est reçue par le Robot, elle essaie d’abord d’annuler le processus, en passant au bloc Finally. Si la logique à l’intérieur du bloc Finally n’est pas terminée dans les 3 secondes depuis la réception de la commande Annuler, l’exécution entière est arrêtée de force et le processus global est réussi dans les journaux car aucune erreur n’a été enregistrée dans le bloc Catch depuis qu’elle a été passée.
- La configuration du statut du processus sur
Successful
ne doit être effectuée qu’à l’intérieur du bloc Try, une fois la Business Logic terminée. - La configuration du statut sur
Failed
ne doit être effectuée qu’à l’intérieur du bloc Catch, une fois logique de gestion des erreurs terminée. - Dans le bloc Finally, il ne devrait y avoir que la logique de nettoyage présente, car elle est exécutée, peu importe si l’exécution a été réussie ou non.
BusinessError
et SystemError
restent ainsi null
et l'état global du processus est considéré comme réussi. Le comportement décrit est intentionnel.
BusinessError
et SystemError
restent null
et le statut global du processus est considéré comme successful
, car aucune erreur n’a été enregistrée.