Il nodo MQInput intraprende le seguenti azioni quando gestisce gli errori con messaggi permanenti e transazionali. Gli errori che si presentano con messaggi non transazionali sono gestiti come descritto in Gestione degli errori nel nodo di input.
Tale azione è riepilogata nella seguente tabella:
Evento di errore | Terminale Failure connesso | Terminale Failure non connesso | Terminale Catch connesso | Terminale Catch non connesso |
---|---|---|---|---|
Il nodo individua un errore interno | Il flusso connesso al terminale Failure gestisce l'errore | Messaggio inserito in una coda alternativa; il nodo ripete l'operazione se l'inserimento non ha esito positivo | Non applicabile | Non applicabile |
Il nodo trasmette il messaggio al terminale out, l'eccezione si verifica nel flusso out | Non applicabile | Non applicabile | Il flusso connesso al terminale Catch gestisce l'errore | Il nodo ripete l'operazione |
Il nodo trasmette il messaggio a un terminale Catch, l'eccezione si verifica nel flusso connesso al terminale Catch | Errore registrato, messaggio sottoposto a rollback | Errore registrato, messaggio sottoposto a rollback | Non applicabile | Non applicabile |
Il nodo trasmette il messaggio a un terminale Failure, l'eccezione si verifica nel flusso connesso al terminale Failure | Non applicabile | Non applicabile | Il nodo ripete l'operazione | Il nodo ripete l'operazione |
Il nodo esegue un nuovo tentativo di elaborazione quando il messaggio è sottoposto a rollback nella coda di input. Esso controlla se il messaggio è stato ripristinato allo stato precedente e, in tal caso, se il conteggio di ripristino allo stato precedente abbia raggiunto (uguagliato) la soglia di ripristino allo stato precedente. Il conteggio di ripristino allo stato precedente per ogni messaggio è conservato da WebSphere MQ in MQMD.
Si specifica l'attributo della soglia di ripristino allo stato precedente BOTHRESH (o si accetta un valore predefinito 0) quando si crea la coda. Se si accetta il valore predefinito di 0, il nodo lo aumenta a 1. Il nodo imposta il valore su 1 anche se non può individuare il valore corrente. Questo significa che se un messaggio non è stato mai ripristinato allo stato precedente, viene ripristinato allo stato precedente e ripetuto almeno una volta.
Se si verifica un errore dopo il terminale Failure, si effettuano ulteriori tentativi fino a quando il campo del conteggio di ripristino allo stato precedente in MQMD non raggiunga due volte la soglia di ripristino allo stato precedente impostata per la coda di input. Quando viene raggiunto questo limite il nodo prova a inserire il messaggio in un'altra coda.
Il messaggio non può essere eliminato, quindi il flusso di messaggi continua a provare l'operazione di ripristino allo stato precedente del messaggio. Esso registra la situazione di errore scrivendo gli errori nella registrazione errori locale. Una seconda indicazione di questo errore è il continuo incremento del BackoutCount del messaggio nella coda di input.
Se questa situazione si è verificata poiché non esiste né l'una né l'altra coda, è possibile definire una delle code di ripristino allo stato precedente menzionate sopra. Se la condizione che impedisce al messaggio di essere elaborato è stata eliminata, è possibile incrementare temporaneamente il valore dell'attributo BOTHRESH. In questo modo si forza il messaggio in una normale elaborazione.
WebSphere MQ supporta i gruppi di messaggi. E' possibile specificare che un messaggio appartiene a un gruppo e che quindi la sua elaborazione è completata in riferimento agli altri messaggi presenti nel gruppo (cioè, i messaggi vengono tutti sottoposti a commit o vengono tutti sottoposti al rollback). Quando si inviano messaggi raggruppati a un broker, tale condizione è supportata se il flusso di messaggi è stato configurato correttamente e non si verificano errori durante l'elaborazione dei messaggi del gruppo.
Per configurare il flusso di messaggi per gestire i messaggi raggruppati correttamente, seguire le azioni descritte nel Nodo MQInput. Tuttavia, la corretta elaborazione del gruppo di messaggi non è garantita se si verifica un errore mentre uno dei messaggi viene elaborato.
Se il nodo MQInput è stato configurato come descritto, in circostanze normali tutti i messaggi nel gruppo vengono elaborati in una singolo unità di lavoro che viene sottoposta a commit quando l'ultimo messaggio del gruppo è stato elaborato con esito positivo. Tuttavia, se si verifica un errore prima che l'ultimo messaggio del gruppo venga elaborato, l'unità di lavoro che include i messaggi fino al messaggio che ha generato l'errore, compreso tale messaggio, è soggetta alla gestione degli errori definita dalle regole qui documentate, che potrebbe risultare nel ripristino allo stato precedente dell'unità di lavoro.
Comunque, tutti i messaggi rimanenti all'interno del gruppo possono essere letti ed elaborati con esito positivo dal flusso di messaggi e quindi gestiti e sottoposti a commit in una nuova unità di lavoro. Un commit viene avviato quando viene elaborato l'ultimo messaggio. Quindi, se si verifica un errore all'interno del gruppo, ma non nel primo o nell'ultimo messaggio, è possibile che una parte del gruppo sia ripristinata allo stato precedente e un'altra parte sia sottoposta a commit.
Se i requisiti di elaborazione del messaggio richiedono che questa situazione venga gestita in un modo particolare, è necessario fornire una gestione degli errori aggiuntiva per gestire gli errori all'interno dei gruppi di messaggi. Ad esempio, si potrebbe registrare l'errore di un gruppo di messaggi all'interno di un database e includere un controllo sul database quando si richiama ogni messaggio, forzando un rollback se il gruppo attuale ha già rilevato un errore. Questo garantirebbe che tutto il gruppo di messaggi sia ripristinato allo stato precedente e non elaborato a meno che non abbiano tutti esito positivo.