MuleSoft - Gestione delle eccezioni Mule

In ogni progetto, il fatto sulle eccezioni è che sono destinate a verificarsi. Questo è il motivo per cui è importante rilevare, classificare e gestire le eccezioni in modo che il sistema / applicazione non venga lasciato in uno stato incoerente. Esiste una strategia di eccezione predefinita che viene applicata implicitamente a tutte le applicazioni Mule. Il rollback automatico di qualsiasi transazione in sospeso è la strategia di eccezione predefinita.

Eccezioni in Mule

Prima di immergerci in profondità nella gestione delle eccezioni, dovremmo capire che tipo di eccezioni possono verificarsi insieme a tre domande fondamentali che uno sviluppatore deve avere durante la progettazione dei gestori di eccezioni.

Quale trasporto è importante?

Questa domanda ha ampia rilevanza prima di progettare gestori di eccezioni perché tutti i trasporti non supportano la transnazionalità.

File o HTTPnon supporta le transazioni. Ecco perché, se in questi casi si verifica un'eccezione, dobbiamo gestirla manualmente.

Databasessostenere le transazioni. Durante la progettazione di gestori di eccezioni in questo caso, dobbiamo tenere presente che le transazioni del database possono automaticamente eseguire il rollback (se necessario).

In caso di REST APIs, dobbiamo tenere presente che dovrebbero restituire i codici di stato HTTP corretti. Ad esempio, 404 per una risorsa non trovata.

Quale modello di scambio di messaggi utilizzare?

Durante la progettazione dei gestori di eccezioni, dobbiamo prestare attenzione al modello di scambio dei messaggi. Può esserci un pattern di messaggio sincrono (richiesta-risposta) o asincrono (fuoco-dimenticare).

Synchronous message pattern si basa sul formato richiesta-risposta, il che significa che questo modello si aspetterà una risposta e verrà bloccato fino a quando non verrà restituita una risposta o si verificherà un timeout.

Asynchronous message pattern è basato sul formato Fire-Forget, il che significa che questo modello presuppone che le richieste verranno elaborate.

Di che tipo di eccezione si tratta?

Una regola molto semplice è che gestirai l'eccezione in base al suo tipo. È molto importante sapere se l'eccezione è causata da un problema tecnico / di sistema o da un problema aziendale?

Si è verificata un'eccezione da system/technical issue (come l'interruzione della rete) dovrebbe essere gestito automaticamente da un meccanismo di ripetizione.

D'altra parte, si è verificata un'eccezione by a business issue (come i dati non validi) non dovrebbero essere risolti applicando il meccanismo di ripetizione perché non è utile riprovare senza correggere la causa sottostante.

Perché classificare le eccezioni?

Poiché sappiamo che tutte le eccezioni non sono uguali, è molto importante classificare le eccezioni. Ad alto livello, le eccezioni possono essere classificate nei seguenti due tipi:

Eccezioni aziendali

I motivi principali per il verificarsi di eccezioni aziendali sono dati errati o flusso di processo errato. Questi tipi di eccezioni sono in genere di natura non modificabile e quindi non è consigliabile configurare un filerollback. Anche applicandoretryIl meccanismo non avrebbe alcun senso perché non è utile riprovare senza risolvere la causa sottostante. Per gestire tali eccezioni, l'elaborazione dovrebbe interrompersi immediatamente e l'eccezione deve essere restituita come risposta a una coda di messaggi non recapitabili. Una notifica dovrebbe anche inviare alle operazioni.

Eccezioni non commerciali

I motivi principali per il verificarsi di eccezioni non aziendali sono problemi di sistema o problemi tecnici. Questi tipi di eccezioni sono ripristinabili in natura e quindi è bene configurare un fileretry meccanismo per risolvere queste eccezioni.

Strategie di gestione delle eccezioni

Mule ha le seguenti cinque strategie di gestione delle eccezioni:

Strategia di eccezione predefinita

Mule applica implicitamente questa strategia ai flussi di Mule. Può gestire tutte le eccezioni nel nostro flusso, ma può anche essere sovrascritto aggiungendo una strategia di eccezione catch, Choice o Rollback. Questa strategia di eccezione ripristinerà tutte le transazioni in sospeso e registrerà anche le eccezioni. Una caratteristica importante di questa strategia di eccezione è che registrerà anche l'eccezione se non ci sono transazioni.

Essendo la strategia predefinita, Mule la implementa quando si verifica un errore nel flusso. Non possiamo configurare in AnyPoint studio.

Strategia di eccezione di rollback

Supponiamo che se non esiste una soluzione possibile per correggere l'errore, cosa fare? Una soluzione consiste nell'usare la strategia di eccezione di rollback che eseguirà il rollback della transazione insieme all'invio di un messaggio al connettore in entrata del flusso principale per rielaborare il messaggio. Questa strategia è anche molto utile quando vogliamo rielaborare un messaggio.

Example

Questa strategia può essere applicata alle transazioni bancarie in cui i fondi vengono depositati in un conto corrente / di risparmio. Possiamo configurare una strategia di eccezione di rollback qui perché nel caso in cui si verifichi un errore durante la transazione, questa strategia riporta il messaggio all'inizio nel flusso per ritentare l'elaborazione.

Strategia di cattura delle eccezioni

Questa strategia cattura tutte le eccezioni che vengono generate nel suo flusso padre. Ignora la strategia di eccezione predefinita di Mule elaborando tutte le eccezioni generate dal flusso padre. È possibile utilizzare una strategia di cattura delle eccezioni per evitare la propagazione delle eccezioni anche ai connettori in entrata e ai flussi principali.

Questa strategia garantisce inoltre che una transazione elaborata dal flusso non venga annullata quando si verifica un'eccezione.

Example

Questa strategia può essere applicata al sistema di prenotazione dei voli in cui abbiamo un flusso per l'elaborazione dei messaggi da una coda. Un arricchitore di messaggi aggiunge una proprietà al messaggio per l'assegnazione del posto e quindi invia il messaggio a un'altra coda.

Se si verifica un errore in questo flusso, il messaggio genererà un'eccezione. Qui, la nostra strategia di cattura delle eccezioni può aggiungere un'intestazione con un messaggio appropriato e può spingere quel messaggio fuori dal flusso alla coda successiva.

Scelta della strategia di eccezione

Nel caso in cui desideri gestire l'eccezione in base al contenuto del messaggio, la strategia di eccezione di scelta sarebbe la scelta migliore. Il funzionamento di questa strategia di eccezione sarà il seguente:

• Innanzitutto, cattura tutte le eccezioni generate all'interno del flusso padre.
• Successivamente, verifica il contenuto del messaggio e il tipo di eccezione.
• Infine, instrada il messaggio alla strategia di eccezione appropriata.

Ci sarebbe più di una strategia di eccezione come Catch o Rollback, definita all'interno della strategia di eccezione di scelta. Nel caso in cui non sia stata definita alcuna strategia in questa strategia di eccezione, il messaggio verrà instradato alla strategia di eccezione predefinita. Non esegue mai alcuna attività di commit, rollback o consumo.

Strategia di eccezione di riferimento

Si riferisce a una strategia di eccezione comune definita in un file di configurazione separato. Nel caso in cui un messaggio generi un'eccezione, questa strategia di eccezione farà riferimento ai parametri di gestione degli errori definiti in una strategia globale di cattura, rollback o eccezione di scelta. Come la strategia di eccezione della scelta, non esegue mai alcuna attività di commit, rollback o consumo.