- 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
- Redémarrage des composants du Robot
- Résolution des problèmes
- À propos de la 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
Arrêter un processus :
Un processus peut être arrêté via les commandes Arrêt progressif ou Forcer l'arrêt.
La commande Arrêt progressif marque le processus dans un état Devrait s'arrêter. Cet état peut être interrogé à partir du workflow encore en cours d'exécution à l'aide de l'activité Devrait s'arrêter. Le workflow doit passer explicitement par cet état puis se terminer. Le workflow ne s'arrête pas automatiquement sans être passé par l'état Devrait s'arrêter. Voir REFramework pour un scénario qui se sert de l'Arrêt progressif.
La commande Arrêter est conçue pour les automatisations Unattended et est uniquement disponible dans Orchestrator. Dans Orchestrator, la commande Arrêt progressif se nomme Arrêter.
La commande Forcer l’arrêt commence par envoyer une requête Annuler au workflow. La requête Annuler du workflow est différente de l'activité Devrait s’arrêter.Annuler est un signal de workflow automatiquement géré par le workflow. Le signal entraîne l’annulation en cascade des activités tout en permettant aux blocs Enfin du workflow d’exécuter des étapes de nettoyage. Si le signal Annuler n'arrête pas le workflow dans les trois secondes, la tâche sera terminée en forçant l'arrêt de toutes les activités en cours, quel que soit leur stade d'exécution.
La commande Forcer l’arrêt a été conçue pour les automatisations Attended et est disponible dans Orchestrator ainsi que dans les clients de bureau et les API telles que Assistant, Studio et RobotJS. Dans les clients de bureau, la commande Forcer l’arrêt se nomme Arrêter.
REFramework exploite la commande Arrêt progressif.
BusinessError
et SystemError
restent ainsi null
et l'état global du processus est considéré comme réussi. Le comportement décrit est intentionnel.
Scénario try-catch
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.
Annulation d’un processus
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).
Forcer l’arrêt d'un processus
Si l'exécution se trouve dans le bloc Try (Essayer) ou Catch (Catch) lorsque la commande Kill (Kill) est reçue par le Robot, il essaie d'abord d'annuler le processus, en passant au bloc Finalement (Finally). Si la logique à l'intérieur du bloc Finalement n'est pas terminée dans les trois secondes suivant la réception de la commande Annuler , toute l'exécution est arrêtée et le processus global est enregistré avec succès dans les journaux car aucune erreur n'a été enregistrée dans le bloc Capturer depuis qu'il a été ignoré.
Éviter les faux positifs
- 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.