Quando i valori ReplyToQ e ReplyToQmgr del messaggio di richiesta originale vengono salvati in un messaggio WebSphere MQ per il successivo richiamo, ciò avviene salvando l'intero MQMD del messaggio di richiesta, piuttosto che limitarsi ai dettagli di ReplyToQ e ReplyToQMgr. Questo perché è necessario memorizzare e richiamare tre valori, ReplyToQ, ReplyToQmgr e CorrelID del messaggio di richiesta ed il nodo MQGet consente la memorizzazione ed il richiamo di un singolo valore. A causa di questo funzionamento del nodo MQGet, si deve salvare la struttura contenente i valori necessari invece dei singoli valori. Quando si apportano modifiche all'esempio per memorizzare valori differenti è necessario tenere presente questo funzionamento del nodo MQGet.
L'esempio Richiesta/Risposta coordinate è progettato in modo tale che è possibile utilizzare differenti implementazioni dei flussi secondari usati nei flussi Richiesta e Risposta invece di quelle fornite nell'esempio. Una implementazione differente potrebbe comportare l'utilizzo di un database per la memorizzazione di ReplyToQ e ReplyToQmgr del messaggio di richiesta iniziale ad esempio. Sebbene non venga consigliato come modo per migliorare le prestazioni. In alternativa, i flussi secondari utilizzati per memorizzare e richiamare ReplyToQ, ReplyToQmgr e CorrelID del messaggio di richiesta in un messaggio WebSphere MQ potrebbero essere utilizzati in altri flussi di messaggi.
Il flusso secondario StoreOriginalMQMD_Sub può essere facilmente utilizzato in altri flussi di messaggi per eseguire la stessa funzione di salvataggio dell'MQMD del messaggio di richiesta in un messaggio WebSphere MQ. Per effettuare questa operazione includere il flusso secondario nel punto appropriato all'interno del flusso di messaggi in cui deve essere utilizzato. E' possibile includere il flusso secondario senza modifiche ma potrebbe dare luogo a potenziali problemi:
Sebbene i parametri chiave da modificare siano stati identificati nella precedente spiegazione, si consiglia di rivedere le impostazioni di tutti i parametri nei nodi all'interno del flusso secondario per accertarsi che siano compatibili con i requisiti.
Esistono molti modi in cui è possibile modificare il flusso secondario perché utilizzi una funzione di memorizzazione alternativa per i dati. Una alternativa potrebbe essere rappresentata dall'uso di un database ad esempio. Invece di scrivere un messaggio WebSphere MQ, il flusso secondario dovrebbe inserire i dati in un database.
Si dovrebbe tenere presente che, modificando la funzione di memorizzazione, si modificheranno le caratteristiche delle prestazioni del flusso secondario. E' importante accertarsi che le caratteristiche dell'implementazione scelta siano conformi ai requisiti di prestazioni del flusso di messaggi. L'utilizzo di un database per conservare le informazioni renderebbe molto più probabile che il flusso di messaggi sia collegato all'I/O nel corso dell'elaborazione, poiché ogni inserimento nel database richiederebbe una scrittura nella registrazione del gestore database.
L'utilizzo di una funzione di memorizzazione alternativa può anche modificare le proprietà transazionali del flusso secondario. Quando i dati vengono memorizzati utilizzando un messaggio WebSphere MQ, questo usa lo stesso gestore risorse dei messaggi WebSphere MQ letti in un altro punto del flusso di messaggi. Se si svolge solo l'elaborazione di messaggi WebSphere MQ nel flusso di messaggi, è coinvolto un singolo gestore risorse. L'utilizzo di un database o di un altro gestore risorse recuperabile renderebbe necessario l'uso di un protocollo di recupero commit a due fasi tra il gestore code del Message Broker ed il gestore database del database in cui sono memorizzati i dati onde assicurarne l'integrità.
Quando si apportano modifiche, si consiglia di rivedere le impostazioni di tutti i parametri nei nodi all'interno del flusso secondario per accertarsi che siano compatibili con i requisiti.
Il flusso secondario RestoreOriginalMQMD_Sub può essere facilmente utilizzato in altri flussi di messaggi per eseguire la stessa funzione di richiamo dell'MQMD del messaggio di richiesta iniziale da un messaggio WebSphere MQ. Per effettuare questa operazione includere il flusso secondario nel punto appropriato all'interno del flusso di messaggi in cui deve essere utilizzato. E' possibile includere il flusso secondario senza modifiche ma potrebbe dare luogo a potenziali problemi:
Sebbene i parametri chiave da modificare siano stati identificati nella precedente spiegazione, si consiglia di rivedere le impostazioni di tutti i parametri nei nodi all'interno del flusso secondario per accertarsi che siano compatibili con i requisiti.
Esistono molti modi in cui si potrebbe modificare il flusso secondario perché utilizzi una funzione di memorizzazione alternativa per i dati. Una alternativa potrebbe essere rappresentata dall'uso di un database ad esempio. Invece di utilizzare il nodo MQGet per leggere un messaggio WebSphere MQ il flusso secondario potrebbe leggere i dati da un database.
Si dovrebbe tenere presente che, modificando la funzione di memorizzazione, si modificheranno le caratteristiche delle prestazioni del flusso secondario. E' importante accertarsi che le caratteristiche dell'implementazione scelta siano conformi ai requisiti di prestazioni del flusso di messaggi. L'utilizzo di un database per conservare le informazioni potrebbe aggiungere sovraccarichi differenti a seconda dell'implementazione. Se i dati vengono richiamati tramite lettura e non vengono aggiornati o cancellati, il sovraccarico è di livello minimo per una implementazione database. Tuttavia se i dati non vengono cancellati dal database, questo continuerà ad aumentare di dimensione e subirà un progressivo rallentamento nell'utilizzo a meno che non venga effettuata un pò di pulizia. Se il processo di richiamo comporta l'aggiornamento di una riga per indicare che i dati sono stati richiamati o la cancellazione di una riga, questo implicherà una scrittura nella registrazione del gestore database, con il risultato di un sovraccarico di elaborazione significativamente maggiore rispetto alla sola lettura.
L'utilizzo di una funzione di memorizzazione alternativa può anche modificare le proprietà transazionali del flusso secondario. Quando i dati vengono memorizzati utilizzando un messaggio WebSphere MQ, questo usa lo stesso gestore risorse dei messaggi WebSphere MQ letti in un altro punto del flusso di messaggi. Se si svolge solo l'elaborazione di messaggi WebSphere MQ nel flusso di messaggi, è coinvolto un singolo gestore risorse. L'utilizzo di un database o di un altro gestore risorse recuperabile renderebbe necessario l'uso di un protocollo di recupero commit a due fasi tra il gestore code del Message Broker ed il gestore database del database in cui sono memorizzati i dati onde assicurarne l'integrità.
Quando si apportano modifiche, si consiglia di rivedere le impostazioni di tutti i parametri nei nodi all'interno del flusso secondario per accertarsi che siano compatibili con i requisiti.