Rilevamento delle eccezioni in un nodo TryCatch

E' possibile progettare un flusso di messaggi per rilevare eccezioni prima che siano restituite al nodo di input. All'interno di un singolo flusso, è possibile includere uno o più nodi TryCatch per fornire un singolo punto di errore per una sequenza di nodi. Con questa tecnica, è possibile fornire un'elaborazione e un ripristino dell'errore molto specifici.

Un nodo TryCatch non elabora in alcun modo un messaggio, esso rappresenta solo un punto di decisione in un flusso di messaggi. Quando il nodo TryCatch riceve un messaggio, esso lo trasmette al terminale try. Il broker passa il controllo alla sequenza di nodi connessi a tale terminale (il flusso try).

Se è generata un'eccezione nel flusso try, il broker restituisce il controllo al nodo TryCatch. Il nodo scrive il contenuto corrente di ExceptionList nella Registrazione errori locale, poi scrive le informazioni per l'eccezione corrente in ExceptionList, sovrascrivendo le informazioni lì memorizzate.

Il nodo ora trasmette il messaggio alla sequenza di nodi connessi al terminale catch (il flusso catch). Il contenuto della struttura ad albero del messaggio che viene trasmesso è identico al contenuto che era stato trasmesso al terminale try, che è il contenuto della struttura ad albero quando il nodo TryCatch lo ha ricevuto all'inizio. Esso aggiunge a questa struttura ad albero le nuove informazioni relative alle eccezioni che ha scritto in ExceptionList. Tutte le modifiche o le aggiunte che i nodi nel flusso try effettuano nella struttura ad albero del messaggio non sono presenti nella struttura ad albero trasmessa al flusso catch.

Tuttavia, se il flusso try ha completato l'elaborazione che implica gli aggiornamenti ai database esterni, questi non vanno perduti. Gli aggiornamenti si conservano mentre il messaggio è elaborato dal flusso catch e la decisione se gli aggiornamenti debbano essere sottoposti a commit o rollback viene presa al momento della configurazione del flusso di messaggi e dei singoli nodi che interagiscono con i database. Se gli aggiornamenti sono sottoposti a commit a causa della configurazione impostata, è necessario includere nel flusso catch una logica che esegua il rollback delle modifiche che sono state effettuate.

Per esaminare le opzioni per la configurazione, consultare Configurazione dei nodi per i flussi di messaggi coordinati.

Il broker restituisce il controllo al punto di rilevamento successivo nel flusso di messaggi (che potrebbe essere un altro nodo TryCatch, ma è sempre, in ultimo, il nodo di input) se:

Il seguente esempio mostra come sia possibile configurare il flusso per rilevare eccezioni nel nodo di input. Il terminale catch del nodo MQInput è connesso ad un nodo Trace per registrare l'errore.


Questo flusso di messaggi ha un nodo MQInput, un nodo Compute e un nodo MQOutput. Il terminale catch del nodo MQInput è connesso a un nodo Trace.

Nel seguente esempio, il flusso di messaggi ha due flussi di elaborazione separati connessi ai terminali true e false del nodo Filter. Qui un nodo TryCatch è incluso su ciascuno dei due instradamenti che può prendere il messaggio. Il terminale catch di entrambi i terminali di TryCatch è connesso a un flusso secondario di elaborazione degli errori comuni.


Questo flusso di messaggi ha un nodo MQInput seguito da un nodo Filter che è stato codificato per eseguire il test di un valore nel messaggio. Un nodo TryCatch è connesso al terminale true del nodo Filter e il relativo terminale try è connesso a un nodo Compute seguito da un terminale MQOutput. Il relativo terminale catch è connesso a un flusso secondario denominato error1 che fornisce una routine di elaborazione degli errori comuni. Un secondo terminale TryCatch è connesso al terminale false del nodo Filter. I relativi terminale try e catch sono connessi a sequenze di nodi identiche al primo terminale TryCatch.

Se il nodo di input nel flusso di messaggi non ha un terminale catch (ad esempio, Real-timeInput) e si desidera elaborare gli errori nel flusso, è necessario includere un nodo TryCatch. Il seguente esempio mostra come connettere un flusso per fornire questa elaborazione degli errori. In questo esempio, si potrebbe configurare l'ESQL nel nodo Compute su flusso catch in modo che esamini l'eccezione che è stata rilevata e imposti dinamicamente il nome della coda di output.


Questo flusso di messaggi ha un nodo Real-timeInput seguito da un nodo TryCatch. Il terminale try del nodo TryCatch è connesso al normale flusso di output (Compute seguito da Publication), il terminale catch è connesso al flusso catch (Trace seguito da Compute seguito da MQOutput).
Concetti correlati
Panoramica dei flussi di messaggi
Panoramica della distribuzione
Attività correlate
Utilizzo dei flussi secondari
Creazione di un flusso di messaggi
Definizione del contenuto del flusso di messaggi
Modifica delle proprietà configurabili
Configurazione dei nodi per i flussi di messaggi coordinati
Gestione delle eccezioni nei flussi di aggregazione
Riferimenti correlati
Nodi integrati
WebSphere MQ Enterprise Transport
WebSphere MQ Mobile Transport
WebSphere MQ Multicast Transport
WebSphere MQ Real-time Transport
WebSphere MQ Telemetry Transport
WebSphere MQ Web Services Transport
Informazioni particolari | Marchi | Download | Libreria | Supporto | Commenti
Copyright IBM Corporation 1999, 2006 Ultimo aggiornamento: ago 17, 2006
ac18880_