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).