Cuando los valores de ReplyToQ y ReplyToQmgr del mensaje de petición original se guardan en un mensaje de WebSphere MQ para recuperarlos posteriormente, esto se hace guardando el MQMD completo del mensaje de petición y no sólo los detalles de ReplyToQ y ReplyToQMgr. Esto es así debido a que es necesario almacenar y recuperar tres valores, ReplyToQ, ReplyToQmgr y CorrelID del mensaje de solicitud y el nodo MQGet sólo permite almacenar o recuperar un solo valor. Conociendo el comportamiento del nodo MQGet, será necesario guardar la estructura que contiene los valores necesarios en vez de guardar los valores individuales. Cuando efectúe cambios en el ejemplo para almacenar distintos valores, deberá recordar este comportamiento del nodo MQGet.
El ejemplo de respuesta de petición coordinada se diseña de forma que puedan usarse las distintas implementaciones de los subflujos usados en los flujos Request (Petición) y Reply (Respuesta) en vez de las que se proporcionan en el ejemplo. Una implementación distinta podría ser, por ejemplo, la utilización de una base de datos para el almacenamiento de ReplyToQ (ColaRespuestas) y ReplyToQmgr (GestorColaResp) del mensaje de petición inicial. Aunque esto no se aconseja como forma de mejorar el rendimiento. Alternativamente, los subflujos utilizados para almacenar y recuperar las ReplyToQ y ReplyToQmgr y el CorrelID del mensaje de solicitud en un mensaje WebSphere MQ podrían utilizarse en otros flujos de mensajes.
El subflujo StoreOriginalMQMD_Sub se puede emplear fácilmente en otros flujos de mensajes para realizar la misma función de guardar el MQMD del mensaje de petición en un mensaje de WebSphere MQ. Para ello, incluya el subflujo en el punto adecuado del flujo de mensajes en el cual deba usarse. El subflujo se puede incluir sin modificarlo, pero esto podría causar problemas.
Aunque los parámetros claves que pueden requerir algún cambio se han indicado arriba, es aconsejable que revise todos los valores de los parámetros de los nodos que haya dentro del subflujo para asegurarse de que son compatibles con sus necesidades.
Hay varias formas de modificar el subflujo para usar un recurso de almacenamiento de datos alternativo. Una de las alternativas sería, por ejemplo, la utilización de una base de datos. En vez de grabar un mensaje de WebSphere MQ el subflujo necesitaría insertar datos en una base de datos.
Ha de tener en cuenta que al modificar el recurso de almacenamiento cambiará las características de rendimiento del subflujo. Es importante asegurarse de que las características de la implementación que elija son coherentes con los requisitos de rendimiento del flujo de mensajes. La utilización de una base de datos para contener la información hará que probablemente el flujo de mensajes esté limitado en lo que se refiere a entrada/salida del proceso, puesto que cada inserción en la base de datos requerirá una grabación en las anotaciones de gestor de la base de datos.
La utilización de un recurso alternativo de almacenamiento también puede cambiar las propiedades transaccionales del subflujo. Cuando los datos se almacenan utilizando un mensaje de WebSphere MQ éste utiliza el mismo gestor de recursos que los mensajes de WebSphere MQ que se leen en otro lugar del flujo de mensajes. Si en el flujo de mensajes se produce únicamente el proceso de mensajes de WebSphere MQ, esto implicará a un solo gestor de recursos. El uso de una base de datos o de otro gestor de recurso recuperable necesitará utilizar un protocolo de recuperación de confirmación en dos fases entre el gestor de colas de Message Broker y el gestor de bases de datos de la base de datos en la que se almacenan los datos para asegurar su integridad.
Cuando efectúe cambios, es aconsejable que revise todos los valores de los parámetros de los nodos que haya dentro del subflujo para asegurarse de que son compatibles con sus necesidades.
El subflujo RestoreOriginalMQMD_Sub puede utilizarse con facilidad en otros flujos de mensajes para realizar la misma función de recuperación del MQMD del mensaje de petición inicial de un mensaje de WebSphere MQ. Para ello, incluya el subflujo en el punto adecuado del flujo de mensajes en el cual deba usarse. El subflujo se puede incluir sin modificarlo, pero esto podría causar problemas.
Aunque los parámetros claves que pueden requerir algún cambio se han indicado arriba, es aconsejable que revise todos los valores de los parámetros de los nodos que haya dentro del subflujo para asegurarse de que son compatibles con sus necesidades.
Hay varias formas de modificar el subflujo para usar un recurso de almacenamiento de datos alternativo. Una de las alternativas sería, por ejemplo, la utilización de una base de datos. El subflujo puede leer datos de una base de datos en vez de utilizar el nodo MQGet para leer un mensaje WebSphere MQ.
Ha de tener en cuenta que al modificar el recurso de almacenamiento cambiará las características de rendimiento del subflujo. Es importante asegurarse de que las características de la implementación que elija son coherentes con los requisitos de rendimiento del flujo de mensajes. Dependiendo de la implementación, la utilización de una base de datos para contener la información puede añadir actividades generales adicionales. Si los datos se recuperan utilizando una operación de lectura y no se actualizan o suprimen, la actividad general estará al mínimo para la implementación de una base de datos Sin embargo, si los datos no se suprimen de la base de datos, ésta continuará aumentando su tamaño y su utilización se hará progresivamente más lenta a menos que se lleve a cabo alguna operación de mantenimiento. Si el proceso de recuperación implica la actualización de una fila para indicar que los datos se han recuperado o que se ha suprimido una fila, esto implicará una grabación en las anotaciones del gestor de bases de datos y el resultado será una actividad general de proceso significativamente mayor que cuando se ejecuta una operación de sólo lectura.
La utilización de un recurso alternativo de almacenamiento también puede cambiar las propiedades transaccionales del subflujo. Cuando los datos se almacenan utilizando un mensaje de WebSphere MQ éste utiliza el mismo gestor de recursos que los mensajes de WebSphere MQ que se leen en otro lugar del flujo de mensajes. Si en el flujo de mensajes se produce únicamente el proceso de mensajes de WebSphere MQ, esto implicará a un solo gestor de recursos. El uso de una base de datos o de otro gestor de recurso recuperable necesitará utilizar un protocolo de recuperación de confirmación en dos fases entre el gestor de colas de Message Broker y el gestor de bases de datos de la base de datos en la que se almacenan los datos para asegurar su integridad.
Cuando efectúe cambios, es aconsejable que revise todos los valores de los parámetros de los nodos que haya dentro del subflujo para asegurarse de que son compatibles con sus necesidades.