MuleSoft - Gestione degli errori di Mule

La nuova gestione degli errori di Mule è uno dei più grandi e importanti cambiamenti apportati in Mule 4. La nuova gestione degli errori può sembrare complessa, ma è migliore e più efficiente. In questo capitolo, discuteremo dei componenti dell'errore di Mule, dei tipi di errore, delle categorie dell'errore di Mule e dei componenti per la gestione degli errori di Mule.

Componenti di Mule Error

L'errore Mule è il risultato dell'errore dell'eccezione Mule ha i seguenti componenti:

Descrizione

È una componente importante dell'errore di Mule che fornirà una descrizione del problema. La sua espressione è la seguente:

#[error.description]

genere

Il componente Tipo di errore Mule viene utilizzato per caratterizzare il problema. Consente inoltre il routing all'interno di un gestore degli errori. La sua espressione è la seguente:

#[error.errorType]

Causa

Il componente Cause dell'errore Mule fornisce il lancio java sottostante che causa l'errore. La sua espressione è la seguente:

#[error.cause]

Messaggio

Il componente Messaggio di Mule error mostra un messaggio opzionale relativo all'errore. La sua espressione è la seguente:

#[error.errorMessage]

Errori figlio

Il componente Errori figlio di Mule error fornisce una raccolta opzionale di errori interni. Questi errori interni vengono utilizzati principalmente da elementi come Scatter-Gather per fornire errori di route aggregati. La sua espressione è la seguente:

#[error.childErrors]

Esempio

In caso di fallimento della richiesta HTTP con un codice di stato 401, gli errori di Mule sono i seguenti:

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	Tipo di errore e descrizione
1	TRANSFORMATION Questo tipo di errore indica che si è verificato un errore durante la trasformazione di un valore. La trasformazione è la trasformazione interna di Mule Runtime e non le trasformazioni DataWeave.
2	EXPRESSION Questo tipo di tipo di errore indica che si è verificato un errore durante la valutazione di un'espressione.
3	VALIDATION Questo tipo di tipo di errore indica che si è verificato un errore di convalida.
4	DUPLICATE_MESSAGE Un tipo di errore di convalida che si verifica quando un messaggio viene elaborato due volte.
5	REDELIVERY_EXHAUSTED Questo tipo di tipo di errore si verifica quando il numero massimo di tentativi per rielaborare un messaggio da un'origine è stato esaurito.
6	CONNECTIVITY Questo tipo di errore indica un problema durante la creazione di una connessione.
7	ROUTING Questo tipo di errore indica che si è verificato un errore durante l'instradamento di un messaggio.
8	SECURITY Questo tipo di errore indica che si è verificato un errore di sicurezza. Ad esempio, credenziali non valide ricevute.
9	STREAM_MAXIMUM_SIZE_EXCEEDED Questo tipo di errore si verifica quando la dimensione massima consentita per un flusso è esaurita.
10	TIMEOUT Indica il timeout durante l'elaborazione di un messaggio.
11	UNKNOWN Questo tipo di errore indica che si è verificato un errore imprevisto.
12	SOURCE Rappresenta il verificarsi di un errore nella sorgente del flusso.
13	SOURCE_RESPONSE Rappresenta il verificarsi di un errore nella sorgente del flusso durante l'elaborazione di una risposta riuscita.

Nell'esempio sopra, puoi vedere il componente messaggio di errore mulo.

Tipi di errore

Cerchiamo di capire i tipi di errore con l'aiuto delle sue caratteristiche:

La prima caratteristica di Mule Error Types è che consiste in entrambi, a namespace and an identifier. Questo ci permette di distinguere i tipi in base al loro dominio. Nell'esempio precedente, il tipo di errore èHTTP: UNAUTHORIZED.
La seconda e importante caratteristica è che il tipo di errore può avere un tipo padre. Ad esempio, il tipo di erroreHTTP: UNAUTHORIZED ha MULE:CLIENT_SECURITY come genitore che a sua volta ha anche un genitore di nome MULE:SECURITY. Questa caratteristica stabilisce il tipo di errore come specifica di un elemento più globale.

Tipi di tipi di errore

Di seguito sono riportate le categorie in cui rientrano tutti gli errori:

QUALUNQUE

Gli errori in questa categoria sono gli errori che possono verificarsi in un flusso. Non sono così gravi e possono essere gestiti facilmente.

CRITICO

Gli errori in questa categoria sono gli errori gravi che non possono essere gestiti. Di seguito è riportato l'elenco dei tipi di errore in questa categoria:

Sr.NO	Tipo di errore e descrizione
1	OVERLOAD Questo tipo di errore indica che si è verificato un errore dovuto a un problema di sovraccarico. In questo caso l'esecuzione verrà rifiutata.
2	FATAL_JVM_ERROR Questo tipo di tipo di errore indica il verificarsi di un errore irreversibile. Ad esempio, stack overflow.

Tipo di errore PERSONALIZZATO

I Tipi di errore PERSONALIZZATI sono gli errori che vengono definiti da noi. Possono essere definiti durante la mappatura o quando si segnalano gli errori. Dobbiamo assegnare uno spazio dei nomi personalizzato specifico a questi tipi di errore per distinguerli dagli altri tipi di errore esistenti all'interno dell'applicazione Mule. Ad esempio, nell'applicazione Mule che utilizza HTTP, non possiamo utilizzare HTTP come tipo di errore personalizzato.

Categorie di errore del mulo

In senso lato, gli errori in Mule possono essere suddivisi in due categorie e cioè, Messaging Errors and System Errors.

Errore di messaggistica

Questa categoria di errore del mulo è correlata al flusso del mulo. Ogni volta che si verifica un problema all'interno di un flusso Mule, Mule genera un errore di messaggistica. Possiamo organizzareOn Error componente all'interno del componente gestore degli errori per gestire questi errori di Mule.

Errore di sistema

L'errore di sistema indica un'eccezione che si è verificata a livello di sistema. Se non è presente alcun evento Mule, l'errore di sistema viene gestito da un gestore degli errori di sistema. Il seguente tipo di eccezioni gestite da un gestore degli errori di sistema:

Eccezione che si verifica durante l'avvio di un'applicazione.
Eccezione che si verifica quando una connessione a un sistema esterno non riesce.

In caso di errore di sistema, Mule invia una notifica di errore ai listener registrati. Registra anche l'errore. D'altra parte, Mule esegue una strategia di riconnessione se l'errore è stato causato da un errore di connessione.

Gestione degli errori del mulo

Mule ha i seguenti due gestori di errori per la gestione degli errori:

Gestori degli errori in caso di errore

Il primo gestore di errori di Mule è il componente On-Error, che definisce i tipi di errori che possono gestire. Come discusso in precedenza, possiamo configurare i componenti On-Error all'interno del componente Error Handler di tipo scope. Ogni flusso Mule contiene un solo gestore degli errori, ma questo gestore degli errori può contenere tutti gli ambiti On-Error di cui abbiamo bisogno. I passaggi per la gestione dell'errore Mule all'interno del flusso, con l'aiuto del componente On-Error, sono i seguenti:

Innanzitutto, ogni volta che un flusso Mule genera un errore, la normale esecuzione del flusso si interrompe.
Successivamente, il processo verrà trasferito al file Error Handler Component che già hanno On Error component per abbinare i tipi di errore e le espressioni.
Infine, il componente Error Handler instrada l'errore al primo On Error scope che corrisponde all'errore.

Di seguito sono riportati i due tipi di componenti On-Error supportati da Mule:

Propaga in caso di errore

Il componente On-Error Propagate viene eseguito ma propaga l'errore al livello successivo e interrompe l'esecuzione del proprietario. La transazione verrà annullata se viene gestita daOn Error Propagate componente.

Continua in caso di errore

Come il componente Propaga in caso di errore, anche il componente Continua in caso di errore esegue la transazione. L'unica condizione è che, se il proprietario ha completato correttamente l'esecuzione, questo componente utilizzerà il risultato dell'esecuzione come risultato del suo proprietario. La transazione verrà salvata se gestita dal componente Continua in caso di errore.

Prova il componente Scope

Try Scope è una delle tante nuove funzionalità disponibili in Mule 4. Funziona in modo simile al blocco try di JAVA in cui si racchiudeva il codice con la possibilità di essere un'eccezione, in modo che possa essere gestito senza rompere l'intero codice.

Possiamo avvolgere uno o più processori di eventi Mule in Try Scope e, successivamente, try scope rileverà e gestirà qualsiasi eccezione generata da questi processori di eventi. Il funzionamento principale dell'ambito di try ruota attorno alla propria strategia di gestione degli errori che supporta la gestione degli errori sul suo componente interno anziché sull'intero flusso. Ecco perché non abbiamo bisogno di estrarre il flusso in un flusso separato.

Example

Di seguito è riportato un esempio di utilizzo dell'ambito try:

Configurazione dell'ambito di prova per la gestione delle transazioni

Come sappiamo, una transazione è una serie di azioni che non dovrebbero mai essere eseguite parzialmente. Tutte le operazioni nell'ambito di una transazione vengono eseguite nello stesso thread e se si verifica un errore, dovrebbe portare a un rollback o un commit. Possiamo configurare l'ambito try, nel modo seguente, in modo che tratti le operazioni figlio come una transazione.

INDIFFERENT [Default]- Se scegliamo questa configurazione nel blocco try, le azioni figlio non verranno trattate come una transazione. In questo caso, l'errore non causa né il rollback né il commit.
ALWAYS_BEGIN - Indica che verrà avviata una nuova transazione ogni volta che viene eseguito l'ambito.
BEGIN_OR_JOIN- Indica che se l'attuale elaborazione del flusso ha già avviato una transazione, unisciti a essa. Altrimenti, avviane uno nuovo.

↰ Previous page Next page ↱