E' importante salvaguardare i messaggi che passano attraverso il dominio broker. Questo è vero sia per i messaggi generati dalle applicazioni sia per quelli utilizzati internamente per la comunicazione tra i componenti. I messaggi utilizzati internamente tra i componenti utilizzano sempre il protocollo WebSphere MQ. I messaggi dell'applicazione utilizzano tutti i protocolli di trasporto supportati.
Per quanto riguarda i messaggi dell'applicazione e quelli interni che viaggiano su WebSphere MQ, due tecniche proteggono dalla eventuale perdita:
Se un messaggio è permanente, WebSphere MQ assicura che non vada perduto quando si verifica un errore, copiandolo su disco.
Un'applicazione potrebbe richiedere che un messaggio venga elaborato in una UOW (unit-of-work/unità di lavoro) sincronizzata
Per ulteriori informazioni su come utilizzare queste opzioni, fare riferimento al manuale WebSphere MQ System Administration Guide.
I componenti di WebSphere Message Broker utilizzano i messaggi WebSphere MQ per comunicare eventi e dati tra i sistemi secondari e le elaborazioni del broker da una parte e Gestione configurazione e il Server nomi utente dall'altra. I componenti assicurano che le funzioni di WebSphere MQ vengano sfruttate come protezione dalla perdita dei messaggi. Non è necessario eseguire alcuna ulteriore operazione per configurare WebSphere MQ o WebSphere Message Broker per la protezione dalla perdita di messaggi interni.
Se la consegna dei messaggi dell'applicazione è di fondamentale importanza, è necessario progettare programmi applicativi e i flussi di messaggi che essi utilizzano per assicurare che i messaggi non vadano perduti. Le tecniche utilizzate dipendono dal protocollo utilizzato dalle applicazioni.
I prodotti di messaggistica WebSphere MQ forniscono la permanenza del messaggio, che definisce la longevità del messaggio nel sistema e garantisce l'integrità del messaggio. I messaggi non permanenti vanno perduti nel caso si verifichi un errore del sistema o del gestore code. I messaggi permanenti sono sempre ripristinati in caso di errore.
Quando un nodo di input legge un messaggio dalla coda di input, l'azione predefinita è quella di utilizzare la permanenza definita in MQMD (intestazione dei messaggi WebSphere MQ), impostata dall'applicazione che crea il messaggio o dalla permanenza predefinita della coda di input. Il messaggio conserva questa permanenza per tutto il flusso di messaggi, a meno che non venga modificato in un nodo di elaborazione del messaggio successivo.
E' possibile sovrascrivere il valore di permanenza di ogni messaggio quando il flusso di messaggi termina in un nodo di output. Questo nodo ha una proprietà che consente di specificare la permanenza del messaggio di ogni messaggio quando questo viene inserito nella coda di output, come valore richiesto o come valore predefinito. Se si specifica il valore predefinito, il messaggio assume il valore di permanenza definito per le code in cui sono scritti i messaggi.
Se il messaggio passa attraverso un nodo Publication, la permanenza dei messaggi inviati ai sottoscrittori viene stabilita dalle opzioni di registrazione dei sottoscrittori. Se un sottoscrittore ha richiesto la consegna di messaggi permanenti ed è autorizzato a farlo da un ACL esplicito o implicito (ereditato), il messaggio viene consegnato in modo permanente indipendentemente dalla relativa proprietà di permanenza esistente. Inoltre, se l'utente ha richiesto la consegna di messaggi non permanenti, il messaggio viene consegnato come non permanente indipendentemente dalla relativa proprietà di permanenza esistente.
Se un flusso di messaggi crea un nuovo messaggio (ad esempio, in un nodo Compute), la permanenza nell'MQMD del nuovo messaggio è copiata dalla permanenza nell'MQMD del messaggio in entrata.
L'azione predefinita di un flusso di messaggi è quella di elaborare i messaggi in entrata sotto il controllo punto di sincronizzazione in una transazione controllata dal broker. Questo significa che un messaggio che per qualche motivo non riesce ad essere elaborato, viene ripristinato allo stato precedente dal broker. Poiché il messaggio è stato ricevuto sotto il controllo punto di sincronizzazione, il messaggio che ha dato esito negativo viene reinserito nella coda di input ed è possibile elaborarlo di nuovo. Se l'elaborazione ha esito negativo, vengono eseguite le procedure di gestione degli errori per questo flusso di messaggi (definite in base alla modalità di configurazione del flusso di messaggi o dal broker).
Per tutti i dettagli sull'elaborazione del nodo di input, consultare Gestione degli errori nel nodo di input.
Se un messaggio permanente SCADA viene pubblicato, potrebbe essere declassato al livello più alto che il client può accettare. In alcune circostanze questo potrebbe significare che il messaggio diviene non permanente.