Gli errori interni possono essere causati da programmi che memorizzano dati non validi nel database o da un difetto nella logica di un flusso.
La strategia più semplice per gestire gli errori ESQL è quella di non fare niente e utilizzare il funzionamento predefinito del broker. Tale funzionamento consiste nell'interrompere l'elaborazione del messaggio che ha dato esito negativo e procedere con il messaggio successivo. I nodi di input e di output forniscono opzioni per controllare esattamente cosa accade quando si interrompe l'elaborazione.
Ciascuna di queste strategie ha i suoi vantaggi. Il modello transazionale conserva la coerenza dei dati, mentre il modello non-transazionale massimizza la continuità dell'elaborazione del messaggio. Ricordare che nel modello transazionale il messaggio di input in errore viene reinserito nella coda di input e il broker tenterà di elaborarlo di nuovo. Il risultato più probabile di questa operazione è che il messaggio continui ad avere esito negativo fino a quando non si raggiunge il limite di nuovi tentativi e a quel punto sarà inserito in una coda di messaggi non recapitati. Il motivo per cui non è stato possibile elaborare il messaggio viene registrato nel registro eventi del sistema (Windows) o syslog (UNIX). Quindi il messaggio non riuscito tiene in sospeso per un certo periodo di tempo l'elaborazione dei messaggi validi successivi e poi il broker lascia che rimanga non elaborato.
La maggior parte dei database funziona in modalità transazionale, in modo che tutte le modifiche effettuate sulle tabelle di database siano sottoposte a commit, se l'elaborazione del messaggio ha esito positivo e a rollback se ha esito negativo, mantenendo quindi l'integrità dei dati. Fa eccezione il caso in cui il broker stesso o un database, abbia esito negativo. (Ad esempio, l'alimentazione delle macchine su cui sono in esecuzione potrebbe venire interrotta.) In questi casi, è possibile che le modifiche in alcuni database siano sottoposte a commit e le modifiche in altri database no; o che le modifiche del database siano sottoposte a commit ma i messaggi di input e di output non lo siano. Se si verifica questa situazione, il flusso dovrebbe essere coordinato e i database interessati configurati per questa modalità di funzionamento.
Utilizzare i terminali failure per rilevare gli errori non gestiti. Collegare al terminale failure un flusso logico semplice. Tale flusso logico potrebbe consistere in un database o nodo Compute che scrive un record della registrazione in un database (possibilmente includendo il flusso di bit del messaggio) o scrive un record nella registrazione eventi. Esso potrebbe anche contenere un nodo di output che scrive il messaggio in una coda speciale.
La struttura ad albero delle eccezioni completa viene trasmessa a qualunque nodo connesso a un terminale failure. (La struttura ad albero delle eccezioni è descritta in Struttura ad albero ExceptionList.)
Per una spiegazione dettagliata delle opzioni che è possibile utilizzare per elaborare gli errori in un flusso di messaggi, consultare Gestione degli errori nei flussi di messaggi. I seguenti argomenti forniscono esempi di cosa è possibile fare:
E' difficile gestire i messaggi di input sintatticamente non validi (e i messaggi di input che sembrano non validi a causa di erronee informazioni sul formato del messaggio), poiché il broker non ha idea di cosa contenga il messaggio. Probabilmente il modo migliore per gestirli è quello di configurare il nodo di input per analizzare completamente e convalidare il messaggio.
Si noti, tuttavia, che questo si applica solo ai messaggi predefiniti, cioè MRM o IDOC.
Per gestire un messaggio non riuscito, connettere un flusso logico semplice al terminale failure.
Il solo svantaggio di questa strategia è che, se il flusso normale non richiede accesso a tutti i campi del messaggio, la forzatura dell'analisi completa del messaggio ha effetti sulle prestazioni.
Se è necessaria una gestione errori migliore rispetto a quella predefinita, il primo passo è quello di utilizzare un programma di gestione errori (consultare la sezione Istruzione DECLARE HANDLER) per intercettare l'eccezione. Il programma di gestione può stabilire la natura del problema dallo stato SQL restituito dal database.
Tuttavia, fare attenzione con questo tipo di strategia. Poiché il programma di gestione assimila l'eccezione, tutte le modifiche ad altri database o le scritture nelle code sottoposte a commit.
Gli errori
che si verificano nei nodi di output MQ riportano la natura dell'errore nello stato SQL e forniscono ulteriori informazioni nella variabile
Errore nativo SQL. Quindi, se è necessaria una gestione errori migliore rispetto a quella predefinita, il primo passo è quello di utilizzare un programma di gestione errori
(consultare la sezione Istruzione DECLARE HANDLER) per intercettare l'eccezione. Questo programma include di solito un'unica istruzione PROPAGATE.
In assenza di un vincolo relativo al tipo, un tentativo di accedere a un campo di messaggio non esistente ha come risultato il valore null. I valori null si trasmettono nelle espressioni, rendendo il risultato null. Quindi, se un'espressione, per quanto complessa, non restituisce un valore null, se ne deduce che tutti i valori necessari per calcolarne il risultato non erano null.
Le espressioni relative al cast possono avere una clausola predefinita. Se esiste una clausola predefinita, i cast hanno esito negativo senza che nulla accada; invece di generare un'eccezione, restituiscono semplicemente il valore predefinito. Il valore predefinito potrebbe essere un numero innocuo (ad esempio, zero per un numero intero) o un valore che chiaramente non è valido nel contesto (ad esempio, -1 per un numero cliente). Il valore null potrebbe essere particolarmente adatto, poiché è un valore che si differenzia da tutti gli altri e che si trasmetterà nelle espressioni senza alcuna possibilità che la condizione di errore venga nascosta.
Le eccezioni che si verificano in altri nodi (cioè, dopo l'elaborazione di un'istruzione PROPAGATE) potrebbero essere rilevate dai programmi di gestione nel modo usuale. La gestione intelligente di tali errori, tuttavia, pone il problema particolare che, poiché nell'errore originale era coinvolto un altro nodo, un altro nodo e non necessariamente quello all'origine dell'eccezione, sarà molto probabilmente coinvolto nella sua gestione.
Come supporto in queste situazioni il database e i nodi Compute dispongono di quattro nuovi terminali chiamati out1, out2, out3 e out4. Inoltre, la sintassi dell'Istruzione PROPAGATE è stata estesa per includere l'espressione di destinazione, l'origine del messaggio e le clausole di controllo per fornire maggiore controllo su questi terminali supplementari.