- Démarrage
- Meilleures pratiques
- Locataire
- À propos du contexte du locataire
- Recherche de ressources dans un locataire
- Gestion des Robots
- Connexion des Robots à Orchestrator
- Enregistrement des identifiants du Robot dans CyberArk
- Stockage des mots de passe de l’Unattended Robot dans Azure Key Vault (lecture seule)
- Stockage des informations d’identification de l’Unattended Robot dans HashiCorp Vault (lecture seule)
- Stockage des informations d'identification du robot Unattended dans AWS Secrets Manager (lecture seule)
- Suppression des sessions Unattended déconnectées et qui ne répondent pas
- Authentification du Robot
- Authentification du Robot avec les informations d'identification du client
- Configurer les capacités d’automatisation
- Audit
- Paramètres
- Cloud Robots
- Exécution d'automatisations Unattended à l'aide de Cloud Robots - VM
- Téléchargement de votre propre image
- Réutilisation des images de machines personnalisées (pour les pools manuels)
- Réinitialisation des informations d'identification d'une machine (pour les pools manuels)
- Surveillance
- Mises à jour de sécurité
- Demander un essai
- Questions fréquemment posées
- Configuration du VPN pour les robots du cloud
- Diffusion en direct et contrôle à distance
- Contexte des dossiers
- Automatisations
- Processus (Processes)
- Tâches (Jobs)
- Apps
- Déclencheurs (Triggers)
- Journaux (Logs)
- Surveillance
- Files d'attente (Queues)
- États des éléments de file d'attente (Queue Item Statuses)
- Exception métier et Exception d'application
- Activités Studio utilisées avec les files d'attente
- Stratégie de rétention des éléments de la file d'attente
- Téléchargement d'éléments en bloc à l'aide d'un fichier CSV
- Gestion des files d'attente dans Orchestrator
- Gestion des files d'attente dans Studio
- Demandes de révision
- Actifs
- Compartiments de stockage
- Test Suite - Orchestrator
- Service de catalogue de ressources
- Intégrations
- Résolution des problèmes
Exception métier et Exception d'application
Il est important de choisir le type correct d'exception avec lequel une transaction a échoué, car ce choix influence si Orchestrator (Orchestrator) choisit de retenter ou non la transaction de l'élément de la file d'attente, comme suit :
-
Une exception d’application décrit une erreur liée à un problème technique, telle qu’une application qui ne répond pas.
Imaginons par exemple un projet qui extrait les numéros de téléphone d’une base de données d’employés, créant des éléments de file d’attente pour chacun d’eux. Ces éléments doivent ensuite être traités et insérés dans une application financière. Si, lorsque la transaction est tentée, l’application financière se fige, le robot ne peut pas trouver le champ dans lequel insérer le numéro de téléphone, et finit par générer une erreur.
Ce genre de problèmes peut être résolu simplement en réessayant la transaction, car l’application peut se débloquer.
-
Une exception métier décrit une erreur liée au fait que certaines données dont dépend le projet d’automatisation sont incomplètes ou manquantes.
Imaginons par exemple un projet qui extrait les numéros de téléphone d’une base de données d’employés, créant des éléments de file d’attente pour chacun d’eux. Ces éléments doivent ensuite être traités et insérés dans une application financière. S'il manque un chiffre à un certain numéro de téléphone en raison d’une erreur humaine, l’élément de file d’attente qui le contient devient invalide. L’automatisation génère alors une exception, du fait que le champ Numéro de téléphone (Phone Number) de l’application financière n’accepte pas un élément de la file d’attente qui contient un numéro incomplet.
Une nouvelle tentative d'exécution de la transaction ne permet pas de résoudre le problème, et il existe d’autres mesures plus efficaces, telles que la notification de l’utilisateur humain de cette erreur.
L'activité Définir l'état de transaction (Set Transaction Status) permet de façonner la logique de votre projet de manière à synthétiser cette distinction de plusieurs manières :
- Si l'activité Set Transaction Status désactive la transaction avec une Exception d'application (Application Exception) et que l'option Nouvelle tentative automatique (Auto Retry) de la page Créer une file d'attente (Create Queue) est définie sur Oui (Yes) lors de la création de la file d'attente, l'élément de la file d'attente fait l'objet d'une nouvelle tentative.
- Par défaut, Orchestrator ne retente pas (not) les transactions qui ont échoué en raison d'exceptions métier (Business Exceptions). Ceci se produit car une incompatibilité entre la valeur de transaction et le prérequis métier implique des erreurs éventuelles dans les données initiales à partir desquelles les éléments de la file d'attente ont été créés. D'autres actions peuvent être nécessaires pour résoudre ce type de problème, et la journalisation de ce type d'exception peut s'avérer utile.
- Une activité Si (If) ou Décision de flux (Flow Decision) permet de prendre des mesures différentes si une transaction a échoué avec un certain type d'exception, tel que l'utilisation de l'activité Message du journal des événements (Log Message) pour consigner un message personnalisé, ou l'activité Zone de message (Message Box) pour afficher une fenêtre contenant des informations sur l'événement.
Vous trouverez ci-dessous un exemple d'un tel projet :
L'illustration ci-dessous indique le mappage des propriétés dans l'activité Set Transaction Status (à gauche) et leurs champs correspondants dans la fenêtre Détails de la transaction (Transaction Details) d'Orchestrator.
La section Vrai (True) de l'activité Décision de flux (Flow Decision) configure l'état de la transaction sur Échec (Failed) avec une Exception métier (Business Exception), tandis que la section Faux (False) la configure sur Échec (Failed) avec une Exception d'application (Application Exception).