MuleSoft - Gestion des erreurs Mule

La nouvelle gestion des erreurs de Mule est l'un des changements les plus importants et les plus importants effectués dans Mule 4. La nouvelle gestion des erreurs peut sembler complexe, mais elle est meilleure et plus efficace. Dans ce chapitre, nous allons discuter des composants d'erreur Mule, des types d'erreur, des catégories d'erreur Mule et des composants de gestion des erreurs Mule.

Composants de l'erreur de mule

L'erreur Mule est le résultat de l'échec d'exception Mule a les composants suivants -

La description

C'est un élément important de l'erreur Mule qui donnera une description du problème. Son expression est la suivante -

#[error.description]

Type

Le composant Type de l'erreur Mule est utilisé pour caractériser le problème. Il permet également le routage dans un gestionnaire d'erreurs. Son expression est la suivante -

#[error.errorType]

Cause

Le composant Cause de l'erreur Mule donne le java sous-jacent à l'origine de l'échec. Son expression est la suivante -

#[error.cause]

Message

Le composant Message de l'erreur Mule affiche un message facultatif concernant l'erreur. Son expression est la suivante -

#[error.errorMessage]

Erreurs enfants

Le composant Erreurs enfants de l'erreur Mule donne une collection facultative d'erreurs internes. Ces erreurs internes sont principalement utilisées par des éléments comme Scatter-Gather pour fournir des erreurs de route agrégées. Son expression est la suivante -

#[error.childErrors]

Exemple

En cas d'échec de la requête HTTP avec un code d'état 401, les erreurs Mule sont les suivantes -

Description: HTTP GET on resource ‘http://localhost:8181/TestApp’ 
failed: unauthorized (401)
Type: HTTP:UNAUTHORIZED
Cause: a ResponseValidatorTypedException instance
Error Message: { "message" : "Could not authorize the user." }

Sr.NO	Type d'erreur et description
1	TRANSFORMATION Ce type d'erreur indique qu'une erreur s'est produite lors de la transformation d'une valeur. La transformation est la transformation interne de Mule Runtime et non les transformations DataWeave.
2	EXPRESSION Ce type de type d'erreur indique qu'une erreur s'est produite lors de l'évaluation d'une expression.
3	VALIDATION Ce type de type d'erreur indique qu'une erreur de validation s'est produite.
4	DUPLICATE_MESSAGE Une sorte d'erreur de validation qui se produit lorsqu'un message est traité deux fois.
5	REDELIVERY_EXHAUSTED Ce type de type d'erreur se produit lorsque le nombre maximal de tentatives de retraitement d'un message d'une source a été épuisé.
6	CONNECTIVITY Ce type d'erreur indique un problème lors de l'établissement d'une connexion.
sept	ROUTING Ce type d'erreur indique qu'une erreur s'est produite lors du routage d'un message.
8	SECURITY Ce type d'erreur indique qu'une erreur de sécurité s'est produite. Par exemple, des informations d'identification non valides reçues.
9	STREAM_MAXIMUM_SIZE_EXCEEDED Ce type d'erreur se produit lorsque la taille maximale autorisée pour un flux est épuisée.
dix	TIMEOUT Il indique le délai d'expiration du traitement d'un message.
11	UNKNOWN Ce type d'erreur indique qu'une erreur inattendue s'est produite.
12	SOURCE Il représente l'occurrence d'une erreur dans la source du flux.
13	SOURCE_RESPONSE Il représente l'occurrence d'une erreur dans la source du flux lors du traitement d'une réponse réussie.

Dans l'exemple ci-dessus, vous pouvez voir le composant de message d'erreur mule.

Types d'erreur

Comprenons les types d'erreur à l'aide de ses caractéristiques -

La première caractéristique des types d'erreur de mule est qu'il se compose des deux, a namespace and an identifier. Cela nous permet de distinguer les types en fonction de leur domaine. Dans l'exemple ci-dessus, le type d'erreur estHTTP: UNAUTHORIZED.
La deuxième caractéristique importante est que le type d'erreur peut avoir un type parent. Par exemple, le type d'erreurHTTP: UNAUTHORIZED a MULE:CLIENT_SECURITY en tant que parent qui à son tour a également un parent nommé MULE:SECURITY. Cette caractéristique établit le type d'erreur comme spécification d'un article plus global.

Types de types d'erreur

Voici les catégories sous lesquelles toutes les erreurs tombent -

TOUT

Les erreurs de cette catégorie sont les erreurs qui peuvent se produire dans un flux. Ils ne sont pas si graves et peuvent être manipulés facilement.

CRITIQUE

Les erreurs de cette catégorie sont les erreurs graves qui ne peuvent pas être traitées. Voici la liste des types d'erreur dans cette catégorie -

Sr.NO	Type d'erreur et description
1	OVERLOAD Ce type d'erreur indique qu'une erreur s'est produite en raison d'un problème de surcharge. Dans ce cas, l'exécution sera rejetée.
2	FATAL_JVM_ERROR Ce type de type d'erreur indique l'occurrence d'une erreur fatale. Par exemple, débordement de pile.

Type d'erreur CUSTOM

Les types d'erreur CUSTOM sont les erreurs que nous définissons. Ils peuvent être définis lors du mappage ou lors de la levée des erreurs. Nous devons donner un espace de noms personnalisé spécifique à ces types d'erreur pour les distinguer des autres types d'erreur existants dans l'application Mule. Par exemple, dans l'application Mule utilisant HTTP, nous ne pouvons pas utiliser HTTP comme type d'erreur personnalisé.

Catégories d'erreur de mule

Au sens large, les erreurs dans Mule peuvent être divisées en deux catégories à savoir, Messaging Errors and System Errors.

Erreur de messagerie

Cette catégorie d'erreur Mule est liée au flux Mule. Chaque fois qu'un problème survient dans un flux Mule, Mule renvoie une erreur de messagerie. Nous pouvons mettre en placeOn Error composant à l'intérieur du composant de gestionnaire d'erreurs pour gérer ces erreurs Mule.

Erreur système

Une erreur système indique une exception au niveau du système. S'il n'y a pas d'événement Mule, l'erreur système est gérée par un gestionnaire d'erreurs système. Le type d'exceptions suivant géré par un gestionnaire d'erreurs système -

Exception qui se produit lors du démarrage d'une application.
Exception qui se produit lorsqu'une connexion à un système externe échoue.

En cas d'erreur système, Mule envoie une notification d'erreur aux auditeurs enregistrés. Il enregistre également l'erreur. D'autre part, Mule exécute une stratégie de reconnexion si l'erreur a été causée par un échec de connexion.

Gestion des erreurs Mule

Mule a les deux gestionnaires d'erreurs suivants pour gérer les erreurs -

Gestionnaires d'erreurs en cas d'erreur

Le premier gestionnaire d'erreurs Mule est le composant On-Error, qui définit les types d'erreurs qu'ils peuvent gérer. Comme indiqué précédemment, nous pouvons configurer les composants On-Error dans le composant Error Handler de type étendue. Chaque flux Mule contient un seul gestionnaire d'erreurs, mais ce gestionnaire d'erreurs peut contenir autant d'étendues On-Error que nécessaire. Les étapes de gestion de l'erreur Mule dans le flux, à l'aide du composant On-Error, sont les suivantes:

Tout d'abord, chaque fois qu'un flux Mule génère une erreur, l'exécution du flux normal s'arrête.
Ensuite, le processus sera transféré au Error Handler Component qui ont déjà On Error component pour faire correspondre les types d'erreur et les expressions.
Enfin, le composant Error Handler achemine l'erreur vers le premier On Error scope qui correspond à l'erreur.

Voici les deux types de composants On-Error pris en charge par Mule -

Propagation en cas d'erreur

Le composant On-Error Propagate s'exécute mais propage l'erreur au niveau suivant et interrompt l'exécution du propriétaire. La transaction sera annulée si elle est gérée parOn Error Propagate composant.

En cas d'erreur Continuer

Comme le composant Propagation en cas d'erreur, le composant Continuer en cas d'erreur exécute également la transaction. La seule condition est que si le propriétaire a terminé l'exécution avec succès, ce composant utilisera le résultat de l'exécution comme le résultat de son propriétaire. La transaction sera validée si elle est gérée par le composant Continuer en cas d'erreur.

Essayez le composant Scope

Try Scope est l'une des nombreuses nouvelles fonctionnalités disponibles dans Mule 4. Il fonctionne de manière similaire au bloc try de JAVA dans lequel nous avions l'habitude de renfermer le code ayant la possibilité d'être une exception, afin qu'il puisse être géré sans casser tout le code.

Nous pouvons encapsuler un ou plusieurs processeurs d'événements Mule dans Try Scope et ensuite, try scope capturera et gérera toute exception levée par ces processeurs d'événements. Le fonctionnement principal de la portée try tourne autour de sa propre stratégie de gestion des erreurs qui prend en charge la gestion des erreurs sur son composant interne au lieu de tout le flux. C'est pourquoi nous n'avons pas besoin d'extraire le flux dans un flux séparé.

Example

Voici un exemple d'utilisation de try scope -

Configuration de l'étendue try pour la gestion des transactions

Comme nous le savons, une transaction est une série d'actions qui ne doivent jamais être exécutées partiellement. Toutes les opérations dans le cadre d'une transaction sont exécutées dans le même thread et si une erreur se produit, elle doit conduire à une annulation ou une validation. Nous pouvons configurer l'étendue try, de la manière suivante, afin qu'elle traite les opérations enfants comme une transaction.

INDIFFERENT [Default]- Si nous choisissons cette configuration sur le bloc try, alors les actions enfants ne seront pas traitées comme une transaction. Dans ce cas, l'erreur ne provoque ni annulation ni validation.
ALWAYS_BEGIN - Il indique qu'une nouvelle transaction sera lancée chaque fois que l'oscilloscope est exécuté.
BEGIN_OR_JOIN- Il indique que si le traitement en cours du flux a déjà démarré une transaction, rejoignez-la. Sinon, commencez-en un nouveau.

↰ Previous page Next page ↱