Informazioni sull'esempio di Programma di gestione degli errori
L'esempio di Programma di gestione degli errori si basa su uno scenario in cui un'azienda che si occupa di elaborazione delle transazioni desidera sviluppare una routine per la gestione degli errori. L'esempio dimostra come utilizzare alcune delle funzioni fornite in WebSphere Message Broker.
Le aziende, come ad esempio le banche, vogliono assicurarsi che le transazioni vengano elaborate una sola ed unica volta e che venga creato un record per ogni errore. Nell'esempio di Programma di gestione degli errori, si inseriscono messaggi relativi ai numeri staff in un flusso di messaggi che aggiorna un database con tali informazioni. Inserendo un messaggio con un numero staff non valido, è possibile osservare come funziona la routine di gestione degli errori.
L'esempio di Programma di gestione degli errori dà una dimostrazione delle seguenti attività:
- Come utilizzare una routine di gestione degli errori per ricavare informazioni sugli errori e memorizzare le informazioni in un database. La routine del programma di gestione degli errori utilizzata nell'esempio è un flusso secondario che si può aggiungere, invariato, a qualsiasi flusso di messaggi.
- Come configurare i flussi di messaggi per il controllo della transazionalità. In particolare, l'esempio dà una dimostrazione dell'utilizzo di transazioni globalmente coordinate per garantire l'integrità di tutti i dati. In z/OS, questa è la modalità operativa predefinita. Su piattaforme distribuite, la coordinazione globale richiede passi specifici di configurazione ed è implementata utilizzando i protocolli XA. In questo esempio, il flusso di messaggi principale aggiorna un database DB2 con informazioni sui numeri staff. Il flusso secondario di gestione degli errori aggiorna un altro database DB2 con informazioni su qualsiasi errore verificatosi in fase di elaborazione del numero staff. L'aggiornamento del database nel flusso principale si svolge sotto controllo transazionale in modo che, se si verifica un errore e il messaggio viene elaborato dal flusso secondario di gestione degli errori, si esegue il rollback dell'aggiornamento del database relativo al numero staff e non il commit. L'aggiornamento del database nel flusso secondario del programma di gestione degli errori è fuori controllo transazionale per garantire che non venga eseguito il rollback delle informazioni sugli errori, poiché è necessario eseguire il commit delle informazioni per fornire un record di errori.
I messaggi
Vengono forniti due messaggi di input per l'esecuzione dell'esempio di Programma di gestione degli errori: un messaggio che contiene un numero di serie staff valido ed un messaggio che ne contiene uno non valido.
Il messaggio valido relativo allo staff è in formato XML come mostrato di seguito:
<Staff>
<StaffNumber>1</StaffNumber>
<NameInfo>
<LastName>Smith</LastName>
<FirstName>Jack</FirstName>
</NameInfo>
</Staff>
Il messaggio non valido relativo allo staff è in formato XML come mostrato di seguito:
<Staff>
<StaffNumber>99</StaffNumber>
<NameInfo>
<LastName>Doe</LastName>
<FirstName>Jane</FirstName>
</NameInfo>
</Staff>
Il flusso di messaggi
La figura che segue mostra il flusso di messaggi principale.

La seguente figura mostra il flusso secondario di gestione degli errori.
La tabella riportata sotto elenca i tipi di nodi utilizzati nell'esempio di Programma di gestione degli errori. Il nodo Subflow non è tecnicamente un nodo e non è disponibile nella Tavolozza dei nodi; il nodo Subflow rappresenta solo l'ubicazione in cui il flusso secondario, Error_Handler.msgflow, viene chiamato all'interno del flusso di messaggi principale.
Tipo nodo |
Nome nodo |
MQInput |
STAFF_IN |
MQOutput |
STAFF_FAIL; STAFF_OUT |
Database |
Update Staff Database; Update Error Database |
Filter |
Check Valid Staff Number; Check Backout Count |
Throw |
Throw; Throw to Complete Rollback |
TryCatch |
TryCatch |
Subflow |
Error_Handler |
Per ulteriori informazioni, leggere la sezione relativa ai nodi nei flussi di messaggi dell'esempio di Programma di gestione degli errori nella documentazione di WebSphere Message Broker.
L'instradamento del messaggio sullo staff valido
Quando si inserisce il messaggio sullo staff valido nella coda di input, tale messaggio viene trasmesso attraverso i nodi nel modo descritto di seguito. Se qualche coda è stata disabilitata, il messaggio non sarà in grado di seguire questo percorso.
Nel flusso di messaggi principale:
- STAFF_IN. Il nodo riceve il messaggio di input dalla coda di input.
- Error_Handler. Questo nodo rappresenta il flusso secondario di gestione degli errori. Il messaggio ora lascia il flusso di messaggi principale e si immette nel flusso secondario.
Nel flusso secondario:
- Start Subflow. Il messaggio viene trasmesso al nodo successivo nel flusso.
- Check Backout count. Il nodo controlla se il conteggio di backout è pari a zero. Poiché questa è la prima volta che il messaggio di input sta passando per questo nodo, attualmente il conteggio è zero ed il messaggio viene trasmesso al nodo successivo. Se il conteggio è superiore a zero, il messaggio viene eliminato.
- TryCatch. Dal momento che il numero staff è valido, il messaggio viene trasmesso al nodo Back To Main Flow. Se il numero staff nel messaggio non è valido e l'elaborazione del messaggio è proseguita fino ad uno stadio in cui ciò è stato rilevato, il messaggio viene invece trasmesso al nodo Update Error Database.
- Back To Main Flow. A questo punto, il messaggio lascia il flusso secondario e torna al flusso di messaggi principale.
Nel flusso di messaggi principale:
- Check Valid Staff Number. Poiché il numero staff è valido, il messaggio viene trasmesso al nodo Update Staff Database.
- Update Staff Database. Il database STAFFDB viene aggiornato con i dettagli relativi allo staff nel messaggio.
- STAFF_OUT. Il nodo inserisce il messaggio nella coda STAFF_OUT.
L'instradamento del messaggio sullo staff non valido
Quando si inserisce il messaggio sullo staff non valido nella coda di input, tale messaggio viene trasmesso attraverso i nodi nel modo descritto di seguito. Se qualche coda è stata disabilitata, il messaggio non sarà in grado di seguire questo percorso. Per ulteriori informazioni sulle attività di ogni nodo, fare clic sui nodi nelle figure contenute nell'argomento principale.
Nel flusso di messaggi principale:
- STAFF_IN. Il nodo riceve il messaggio di input dalla coda di input.
- Error_Handler. Questo nodo rappresenta il flusso secondario di gestione degli errori. Il messaggio ora lascia il flusso di messaggi principale e si immette nel flusso secondario.
Nel flusso secondario:
- Start Subflow. Il messaggio viene trasmesso al nodo successivo nel flusso.
- Check Backout Count. Il nodo controlla se il conteggio di backout è pari a zero. Poiché questa è la prima volta che il messaggio di input sta passando per questo nodo, attualmente il conteggio è zero ed il messaggio viene trasmesso al nodo successivo. Confrontare con il passo 13, riportato sotto.
- TryCatch. Il numero staff nel messaggio non è valido, ma questo errore non è stato ancora rilevato. Come risultato, il messaggio di input viene trasmesso al nodo Back To Main Flow, piuttosto che al nodo Update Error Database.
- Back To Main Flow. A questo punto, il messaggio lascia il flusso secondario e torna al flusso di messaggi principale.
Nel flusso di messaggi principale:
- Check Valid Staff Number. Poiché il numero staff non è valido, il messaggio viene trasmesso al nodo Throw Exception, piuttosto che al nodo Update Staff Database.
- Throw Exception. Il nodo interrompe l'elaborazione del messaggio e registra il numero errore "3001" ed il testo "Numero staff non valido" nel contenuto del messaggio. Ora si esegue il 'rollback' del messaggio. Cioè, il messaggio viene ritrasmesso al punto di controllo, che in questo caso è il nodo TryCatch nel flusso secondario.
Nel flusso secondario:
- TryCatch. Il nodo riconosce che si è verificata un'eccezione nell'elaborazione del messaggio e trasmette il messaggio in questione al nodo Update Error Database.
- Update Error Database. Il database ERRORDB viene aggiornato con i dettagli relativi all'errore, come specificato nel nodo Throw exception (passo 8).
- Throw To Complete Rollback. Il nodo interrompe l'elaborazione del messaggio e registra il numero "3002" ed il testo "Da flusso di messaggi Error_Handler. Consultare ERRORDB per dettagli" nel contenuto del messaggio. Il messaggio viene ora ritrasmesso al punto di controllo, che è il nodo STAFF_IN nel flusso di messaggi principale.
Questo è lo stadio finale dell'elaborazione Catch. Scaturisce l'effetto di eseguire il rollback dell'intera transazione, inclusi gli aggiornamenti del database sotto controllo transazionale (cioè, l'aggiornamento di STAFFDB nel flusso principale) nel percorso originale Try. Tuttavia, si esegue ancora il commit dell'aggiornamento di ERRORDB, che è fuori controllo transazionale.
Nel flusso di messaggi principale:
- STAFF_IN. Poiché si è verificata un'eccezione nell'elaborazione del messaggio, il messaggio in questione viene trasmesso al nodo STAFF_FAIL, piuttosto che ritrasmesso al flusso di messaggi.
- STAFF_FAIL. Il nodo inserisce il messaggio nella coda STAFF_FAIL. In alternativa, se la coda STAFF_FAIL è disabilitata, il messaggio non si arresta a questo punto. Viene ritrasmesso al nodo STAFF_IN e quindi al flusso secondario. Il messaggio raggiunge quindi il nodo Check Backout Count. Il nodo controlla se il conteggio di backout è pari a zero. Poiché il messaggio è già transitato per questo nodo in precedenza, il conteggio di backout non è più zero ed il messaggio viene eliminato. L'eliminazione del messaggio previene il verificarsi di una situazione in cui, se la coda STAFF_FAIL è disabilitata, il messaggio continua il percorso attraverso il flusso ininterrottamente. Confrontare con il passo 4, riportato sopra.
Quando si utilizza un nodo TryCatch oppure si collegano nodi al terminale Catch di un nodo MQInput, si potrebbe presupporre che qualsiasi elaborazione verificatasi nel percorso originale Try non sarà sottoposta a commit, se i nodi sono configurati correttamente, nel caso in cui venga richiamato il percorso Catch. Tuttavia, non è questo il caso. Ad esempio, se un database viene aggiornato nel percorso Try sotto controllo transazionale e viene richiamato il percorso Catch, che si completa in modo normale, verrà ancora eseguito il commit dell'aggiornamento del database.
Il requisito in questo esempio è costituito dal leggere un messaggio, aggiornare un database e scrivere il messaggio in un'altra coda. Se si verifica un errore, si effettua il rollback dell'aggiornamento del database. L'elaborazione Catch aggiorna il database degli errori con i dettagli relativi all'errore in questione e scrive il messaggio originale nella coda degli errori. In termini di programmazione, ecco cosa accade:
BEGIN (Start 'outer' unit-of-work.)
MQGET (Get message from the input queue.)
TRY
BEGIN (Start 'inner' unit-of-work.)
Update database
MQPUT (Put message onto the output queue.)
IF ERROR
ROLLBACK inner unit-of-work GO TO CATCH
ELSE
COMMIT inner and outer unit-of-work as one unit-of-work
END IF
CATCH
Update error database
MQPUT (Put message onto the failure queue.)
COMMIT outer unit-of-work
Tuttavia, XA Transaction Manager e WebSphere MQ non supportano due livelli di unità di lavoro nella stessa applicazione. Come risultato, l'esempio di Programma di gestione degli errori utilizza le seguenti strutture:
- L'aggiornamento del database nel percorso Try è entro il controllo transazionale. Nell'esempio, si tratta dell'aggiornamento di STAFFDB.
- L'aggiornamento del database nel percorso Catch è fuori controllo transazionale. Si tratta del database ERRORDB.
- Il terminale Failure del nodo MQInput è collegato ad un nodo MQOutput, che punta ad una coda di errori.
- Lo stadio finale dell'elaborazione Catch è rappresentato dalla nuova emissione di un errore, tramite un nodo Throw.
- Il messaggio quindi è sottoposto a rollback sul percorso dell'errore fino al nodo MQInput e, da lì, alla coda di errori.
Vi sono due database in questo esempio, invece di uno solo, poiché in WebSphere MQ non si può utilizzare la stessa connessione al database per transazioni sia coordinate che non coordinate nello stesso flusso di messaggi. Nell'esempio di Programma di gestione degli errori, l'aggiornamento del database nel flusso di messaggi principale è sotto controllo transazionale in modo che, se si verifica un errore, si esegue il rollback dell'aggiornamento e non viene sottoposto a commit. L'aggiornamento del database nel flusso secondario non si trova sotto controllo transazionale, quindi si esegue sempre il commit dell'aggiornamento. Di conseguenza, l'esempio di Programma di gestione degli errori richiede due database separati.
Per ulteriori informazioni, leggere la sezione relativa al coordinamento delle transazioni nei flussi di messaggi nella documentazione di WebSphere Message Broker.
Torna alla pagina home dell'esempio