MuleSoft - Gestion des exceptions Mule

Dans le cas de chaque projet, le fait à propos des exceptions est qu'elles sont inévitables. C'est pourquoi il est important d'attraper, de classer et de gérer les exceptions afin que le système / l'application ne soit pas laissé dans un état incohérent. Il existe une stratégie d'exception par défaut qui est implicitement appliquée à toutes les applications Mule. Annuler automatiquement toute transaction en attente est la stratégie d'exception par défaut.

Exceptions à Mule

Avant de plonger profondément dans la gestion exceptionnelle, nous devons comprendre quels types d'exceptions peuvent se produire ainsi que trois questions de base qu'un développeur doit se poser lors de la conception de gestionnaires d'exceptions.

Quel transport est important?

Cette question a une grande pertinence avant de concevoir des gestionnaires d'exceptions car tous les transports ne prennent pas en charge la transnationalité.

File ou HTTPne prend pas en charge les transactions. C'est pourquoi, si une exception survient dans ces cas, nous devons la gérer manuellement.

Databasessoutenir les transactions. Lors de la conception de gestionnaires d'exceptions dans ce cas, nous devons garder à l'esprit que les transactions de base de données peuvent automatiquement être annulées (si nécessaire).

En cas de REST APIs, nous devons garder à l'esprit qu'ils doivent renvoyer les bons codes d'état HTTP. Par exemple, 404 pour une ressource introuvable.

Quel modèle d'échange de messages utiliser?

Lors de la conception des gestionnaires d'exceptions, nous devons prendre soin du modèle d'échange de messages. Il peut y avoir un modèle de message synchrone (demande-réponse) ou asynchrone (oubli d'incendie).

Synchronous message pattern est basé sur le format demande-réponse, ce qui signifie que ce modèle attendra une réponse et sera bloqué jusqu'à ce qu'une réponse soit renvoyée ou que le délai expire.

Asynchronous message pattern est basé sur le format Fire-forget, ce qui signifie que ce modèle suppose que les demandes seront finalement traitées.

De quel type d'exception s'agit-il?

La règle très simple est que vous gérerez l'exception en fonction de son type. Il est très important de savoir si l'exception est causée par un problème système / technique ou un problème commercial?

Une exception est survenue par system/technical issue (comme une panne de réseau) doit être automatiquement gérée par un mécanisme de nouvelle tentative.

En revanche, une exception s'est produite by a business issue (comme les données non valides) ne doit pas être résolu en appliquant un mécanisme de nouvelle tentative car il n'est pas utile de réessayer sans corriger la cause sous-jacente.

Pourquoi catégoriser les exceptions?

Comme nous savons que toutes les exceptions ne sont pas les mêmes, il est très important de catégoriser les exceptions. Au niveau élevé, les exceptions peuvent être classées dans les deux types suivants -

Exceptions commerciales

Les principales raisons de l'apparition d'exceptions commerciales sont des données incorrectes ou un flux de processus incorrect. Ces types d'exceptions sont généralement de nature non récupérable et il n'est donc pas bon de configurer unrollback. Même en appliquantretrymécanisme n'aurait aucun sens car il n'est pas utile de réessayer sans corriger la cause sous-jacente. Afin de gérer ces exceptions, le traitement doit s'arrêter immédiatement et l'exception renvoyée en réponse à une file d'attente de lettres mortes. Une notification doit également être envoyée aux opérations.

Exceptions non commerciales

Les principales raisons de l'apparition d'exceptions non commerciales sont un problème système ou un problème technique. Ces types d'exceptions peuvent être récupérés par nature et il est donc bon de configurer unretry mécanisme afin de résoudre ces exceptions.

Stratégies de gestion des exceptions

Mule a les cinq stratégies de gestion des exceptions suivantes -

Stratégie d'exception par défaut

Mule applique implicitement cette stratégie aux flux Mule. Il peut gérer toutes les exceptions de notre flux, mais il peut également être remplacé en ajoutant une stratégie d'exception catch, Choice ou Rollback. Cette stratégie d'exception annulera toutes les transactions en attente et enregistrera également les exceptions. Une caractéristique importante de cette stratégie d'exception est qu'elle enregistrera également l'exception s'il n'y a pas de transaction.

En tant que stratégie par défaut, Mule l'implémente lorsqu'une erreur se produit dans le flux. Nous ne pouvons pas configurer dans AnyPoint studio.

Stratégie d'exception d'annulation

Supposons que s'il n'y a pas de solution possible pour corriger l'erreur, que faire? Une solution consiste à utiliser la stratégie d'exception d'annulation qui annulera la transaction avec l'envoi d'un message au connecteur entrant du flux parent pour retraiter le message. Cette stratégie est également très utile lorsque nous voulons retraiter un message.

Example

Cette stratégie peut être appliquée aux transactions bancaires où les fonds sont déposés dans un compte chèque / épargne. Nous pouvons configurer ici une stratégie d'exception d'annulation car au cas où une erreur se produirait lors de la transaction, cette stratégie ramène le message au début dans le flux pour tenter à nouveau le traitement.

Stratégie d'exception de capture

Cette stratégie intercepte toutes les exceptions qui sont levées dans son flux parent. Il remplace la stratégie d'exception par défaut de Mule en traitant toutes les exceptions levées par le flux parent. Nous pouvons également utiliser une stratégie d'exception de capture pour éviter de propager des exceptions aux connecteurs entrants et aux flux parents.

Cette stratégie garantit également qu'une transaction traitée par le flux n'est pas annulée lorsqu'une exception se produit.

Example

Cette stratégie peut être appliquée au système de réservation de vol dans lequel nous avons un flux de traitement des messages d'une file d'attente. Un enricher de message ajoute une propriété sur le message pour l'attribution de siège, puis envoie le message à une autre file d'attente.

Maintenant, si une erreur se produit dans ce flux, le message lèvera une exception. Ici, notre stratégie d'exception de capture peut ajouter un en-tête avec un message approprié et peut pousser ce message hors du flux vers la file d'attente suivante.

Stratégie d'exception de choix

Si vous souhaitez gérer l'exception en fonction du contenu du message, le choix de la stratégie d'exception serait le meilleur choix. Le fonctionnement de cette stratégie d'exception sera le suivant -

Premièrement, il intercepte toutes les exceptions levées dans le flux parent.
Ensuite, il vérifie le contenu du message et le type d'exception.
Et enfin, il achemine le message vers la stratégie d'exception appropriée.

Il y aurait plus d'une stratégie d'exception comme Catch ou Rollback, définie dans la stratégie d'exception de choix. Si aucune stratégie n'est définie dans le cadre de cette stratégie d'exception, elle achemine le message vers la stratégie d'exception par défaut. Il n'effectue jamais d'activités de validation, de restauration ou de consommation.

Stratégie d'exception de référence

Cela fait référence à une stratégie d'exception commune définie dans un fichier de configuration distinct. Dans le cas où un message lève une exception, cette stratégie d'exception fera référence aux paramètres de gestion des erreurs définis dans une stratégie d'exception globale de capture, de restauration ou de choix. Comme la stratégie d'exception de choix, elle n'effectue jamais d'activités de validation, de restauration ou de consommation.