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.
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.
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.