Il broker fornisce una gestione degli errori di base per tutti i flussi di messaggi. Se l'elaborazione di base non è sufficiente e si desidera intraprendere un'azione specifica in risposta a certe condizioni e situazioni di errore, è possibile fare in modo che i flussi di messaggi forniscano la propria gestione degli errori. Ad esempio, si potrebbe progettare un flusso che preveda certi errori che si desidera vengano elaborati in un modo particolare o un flusso che aggiorni un database e debba eseguire il rollback di questi aggiornamenti se un'altra elaborazione non termina con esito positivo.
Per fare questo, le opzioni che è possibile utilizzare sono, in alcuni casi, piuttosto complesse. Le opzioni fornite per i nodi MQInput e TimeoutNotification sono complete perché questi nodi gestiscono le transazioni e i messaggi permanenti. MQInput è influenzato anche dalle opzioni di configurazione per WebSphere MQ.
Poiché è possibile decidere di gestire errori diversi in modi diversi, non esistono delle procedure fisse da descrivere. Questa sezione fornisce informazioni sui principi relativi alla gestione degli errori e le opzioni disponibili ed è necessario decidere quale combinazione di scelte sia più adatta in ogni situazione in base ai dettagli forniti in questa sezione.
E' possibile scegliere una o più delle seguenti opzioni nei propri flussi di messaggi:
Se si includono nodi definiti dall'utente nel proprio flusso di messaggi, è necessario fare riferimento alle informazioni fornite con il nodo per comprendere come si potrebbero gestire gli errori con questi nodi. Le descrizioni presenti in questa sezione riguardano solo i nodi integrati.
Quando si progetta un approccio per la gestione degli errori, considerare i seguenti fattori:
Quando viene individuata un'eccezione all'interno di un nodo, il messaggio e le informazioni relative all'eccezione sono trasmessi al terminale failure del nodo. Se il nodo non dispone di un terminale failure o non è connesso, il broker genera un'eccezione e restituisce il controllo al nodo precedente più vicino in grado di elaborarla. Questo potrebbe essere un nodo TryCatch, un nodo AggregateReply, o il nodo di input.
Se un nodo MQinput individua un errore interno, il suo funzionamento varia leggermente; se il terminale failure non è connesso, esso cerca di inserire il messaggio sulla coda di ripristino allo stato precedente della coda di input o (se questa non è definita) nella coda di messaggi non recapitati del gestore code del broker,
Ad un terminale catch viene trasmesso un messaggio solo se prima è stato trasmesso oltre il nodo (ad esempio, ai nodi connessi al terminale out).
I principi generali per la gestione degli errori sono:
Il flusso fail è richiamato anche se si genera un'eccezione dopo il nodo MQInput (nei flussi out o catch), il messaggio è transazionale ed il reinserimento del messaggio nella coda di input fa sì che il conteggio di ripristino allo stato precedente raggiunga la relativa soglia allo stato precedente.
I nodi HTTPInput e SCADAInput non trasmettono il messaggio al terminale failure se viene generata un'eccezione dopo il nodo e non è stato connesso il terminale catch.
Per ulteriori informazioni, consultare i seguenti argomenti:
Se i flussi di messaggi includono aggiornamenti del database, il modo in cui si configurano i nodi che interagiscono con quei database può influire anche sul modo in cui vengono gestiti i nodi:
Per ulteriori informazioni sugli aggiornamenti database coordinati, consultare Configurazione dei nodi per i flussi di messaggi coordinati.
I flussi di messaggi per l'aggregazione implicano delle considerazioni aggiuntive che non sono affrontate in questa sezione; tali considerazioni sono descritte in Gestione delle eccezioni nei flussi di aggregazione.
L'Esempio Programma di gestione degli errori dimostra come utilizzare una routine di gestione degli errori per catturare informazioni sugli errori e per memorizzare tali informazioni in un database. La routine di gestione degli errori è un flusso secondario che è possibile aggiungere, invariato, a qualsiasi flusso di messaggi. L'esempio dimostra anche come configurare i flussi di messaggi per controllare il tipo di transazione; in particolare, l'utilizzo di transazioni coordinate globalmente per assicurare l'integrità generale dei dati.