Configurar flujos de mensajes coordinados globalmente

Un flujo de mensajes coordinado se ejecuta en una sola transacción, que se inicia cuando un nodo de entrada recibe un mensaje y se puede confirmar o restituir cuando se ha completado todo el proceso. También puede controlar cómo maneja los errores de base de datos el nodo que interactúa con la base de datos.

Antes de empezar:

Ha de haber completado las siguientes tareas:

  1. Configurar bases de datos para la coordinación global de transacciones.
  2. Configuración de la coordinación global de transacciones (confirmación en dos fases).
  3. Crear un flujo de mensajes.
Si desea que las acciones de un flujo de mensajes estén coordinadas globalmente (es decir, que deba completarse todo el proceso satisfactoriamente o no completarse ninguna parte del proceso), asegúrese de que la configuración da soporte a esta acción. Para obtener más información sobre la coordinación global de transacciones del flujo de mensajes, consulte El modelo transaccional.
El siguiente ejemplo muestra la utilización de transacciones coordinadas globalmente y la diferencias en el flujo de mensajes cuando las actualizaciones de base de datos están coordinadas (flujo principal) y cuando no lo están (flujo de errores). Los ejemplos sólo pueden verse cuando se utiliza el centro de información que está integrado en el Kit de herramientas de Message Brokers.

Para configurar un flujo de mensajes para coordinación global:

  1. En el Kit de herramientas de Message Brokers, vaya a la Perspectiva de Desarrollo de aplicaciones de intermediario.
  2. Abra el flujo de mensajes que desea configurar.
  3. Establezca la propiedad Transacción para los nodos siguientes si se utilizan en el flujo de mensajes:
    • Nodo Compute
    • Nodo Database
    • Nodo DataDelete
    • Nodo DataInsert
    • Nodo DataUpdate
    • Nodo Filter
    • Nodo Mapping
    • Nodo Warehouse

    Puede establecer la propiedad Transacción en los valores siguientes:

    Automática
    Las actualizaciones, supresiones y adiciones que realiza el nodo se confirman o restituyen cuando se completa el proceso del flujo de mensajes. Si el flujo de mensajes se completa satisfactoriamente, se confirman todos los cambios. Si no se completa satisfactoriamente, se restituyen todos los cambios.

    Si desea que todos los procesos realizados por el flujo de mensajes estén coordinados, debe seleccionar este valor.

    Confirmar
    La acción que se realiza depende del sistema en el que se ha desplegado el flujo de mensaje:
    • En sistemas distribuidos, se confirma cualquier trabajo que se haya realizado hasta ese momento en este origen de datos de este flujo de mensajes, incluyendo las acciones realizadas en este nodo, independientemente de que el flujo de mensajes se ejecute posteriormente de forma satisfactoria o de forma anómala.
      Nota: En sistemas distintos de z/OS, las bases de datos relacionales pueden o no soportar esta modalidad de operación.
    • z/OS platform En z/OS, se confirman las acciones realizadas sólo en este nodo, independientemente de si el flujo de mensajes ha finalizado satisfactoriamente o no. Las acciones realizadas antes de este nodo, bajo transacciones automáticas, no se confirman, sino que permanecen dentro de una unidad de trabajo y pueden ser confirmadas o restituidas, dependiendo de si el flujo de mensajes finaliza o no satisfactoriamente.
    Para mezclar nodos con transaccionalidad Automática y Confirmar en el mismo flujo de mensajes, donde los nodos funcionan en la misma base de datos externa, utilice conexiones ODBC aparte: una para los nodos que no se han de confirmar hasta que el flujo de mensajes se complete y otra para los nodos que se han de confirmar inmediatamente. Si no utiliza conexiones ODBC diferentes, los nodos que se confirman inmediatamente también confirmarán todas las operaciones realizadas en los nodos con transaccionalidad Automática anteriores.
    Nota: En sistemas distintos de z/OS, las bases de datos relacionales pueden o no soportar esta modalidad de operación.

    Si define más de una conexión ODBC, es posible que se produzcan problemas de bloqueo de base de datos. En concreto, si un nodo con transaccionalidad Automática lleva a cabo una operación, como INSERT o UPDATE, se bloquea un objeto de base de datos (por ejemplo, una tabla) y si otro nodo intenta acceder a ese objeto de base de datos utilizando una conexión ODBC distinta, se produce un bloqueo persistente.

    El segundo nodo espera que se libere el bloqueo provocado por el primer nodo, pero éste no confirmará sus operaciones y liberará el bloqueo hasta que se complete el flujo de mensajes; esto no sucederá porque el segundo nodo está esperando a que se libere el bloqueo de la base de datos del primer nodo.

    Una situación así no la puede detectar ninguna rutina automática DBMS para evitar los bloqueos persistentes, porque las dos operaciones se interfieren la una con la otra indirectamente, utilizando el intermediario.

    Hay dos maneras de evitar este tipo de problemas de bloqueo:

    • Diseñe el flujo de mensajes de forma que las operaciones no confirmadas (automáticas) no bloqueen ningún objeto de base de datos al que necesiten acceder operaciones posteriores utilizando una conexión ODBC distinta.
    • Configure el parámetro de tiempo de espera de bloqueo de base de datos de forma que un intento de obtener un bloqueo falle después de un periodo de tiempo especificado. Si una operación de base de datos falla debido al tiempo de espera de bloqueo de la base de datos, se genera una excepción que el intermediario maneja de forma típica.

    Para obtener información sobre los objetos de base de datos que ciertas operaciones bloquean, y cómo configurar el parámetro de tiempo de espera de bloqueo de base de datos, consulte la documentación del producto de base de datos.

  4. Establezca la propiedad Modalidad de transacción para los nodos siguientes, si se encuentran en este flujo de mensajes:
    • Nodo MQInput
    • Nodo MQOutput
    • Nodo MQReply
    • Nodo SCADAInput
    • Nodo JMSInput
    • Nodo JMSOutput

    La tabla siguiente proporciona un resumen de las acciones que se toman en respuesta a valores específicos de las propiedades para los nodos de entrada y salida.

    Persistencia de mensajes a Modalidad de transacción del nodo de entrada Modalidad de transacción del nodo de MQOutput o de MQReply ¿Está globalmente coordinado el flujo de mensajes?
    Automática
    No Automática
    No Automática No
    No No Automática No
    Automática Automática
    No Automática Automática No
    Cualquiera b Cualquiera b
    Cualquiera b Cualquiera b No No
    Notas:
    1. La persistencia sólo es importante para los mensajes recibidos a través de los protocolos WebSphere MQ Enterprise Transport, WebSphere MQ Mobile Transport y WebSphere MQ Telemetry Transport.
    2. El valor de la propiedad del nodo MQOutput o MQReply altera temporalmente el valor que se establece aquí.
    3. Los valores de Modalidad de transacción de los nodos JMSInput y JMSOutput están establecidos de forma distinta en la tabla anterior. Consulte los apartados Nodo JMSInput y Nodo JMSOutput.

    El valor predeterminado en cada nodo de entrada es , que significa que los mensajes de entrada se procesan bajo punto de sincronismo. Además, los mensajes que se envían al nodo de salida se entregan bajo punto de sincronismo. Puede cambiar este comportamiento si el nodo de salida es un nodo MQOutput o MQReply; los dos tienen una propiedad Modalidad de transacción.

    Si establece la Modalidad de transacción de un nodo de entrada en Automática, los mensajes de entrada se procesan bajo punto de sincronismo sólo si están definidos como persistentes. Los mensajes enviados al nodo MQOutput se entregan bajo punto de sincronismo a menos que cambie explícitamente el valor de la propiedad Modalidad de transacción en el nodo MQOutput.

  5. Establezca las propiedades Tratar los avisos como errores y Generar excepción en error de la base de datos para cada nodo que accede a una base de datos para indicar cómo desea que ese nodo maneje los avisos y errores de base de datos. Si selecciona o no estas propiedades y cómo conecta los terminales de anomalías de los nodos, también afectan la forma en que se confirman o restituyen las actualizaciones de base de datos.
  6. Añada el flujo de mensajes a un archivador de intermediario.
  7. Seleccione el separador Configurar debajo de la vista del editor de archivador de intermediario y seleccione el flujo de mensajes. Se muestran las propiedades configurables para el flujo de mensajes dentro del archivador de intermediario. Seleccione coordinatedTransaction para configurar el flujo de mensajes como coordinados globalmente.

    z/OS platform En z/OS, las transacciones siempre están coordinadas globalmente. Se hace caso omiso del valor de la propiedad Transacción coordinada para un flujo de mensajes. La coordinación siempre la proporciona RRS.

Ahora el flujo de mensajes está configurado para la coordinación global.
Ahora puede desplegar el flujo de mensajes en el intermediario. Compruebe que el entorno de intermediario (incluido el gestor de colas del intermediario) y las bases de datos estén configuradas correctamente para coordinación global antes de desplegar el flujo de mensajes.

Si el entorno de intermediario y las bases de datos no están configuradas correctamente para coordinación global, las transacciones de flujo de mensajes no estarán coordinadas globalmente.

Conceptos relacionados
Visión general de flujos de mensajes
Transacciones de flujo de mensajes
El modelo transaccional
Tareas relacionadas
Diseñar un flujo de mensajes
Crear un flujo de mensajes
Definir el contenido del flujo de mensajes
Acceder a bases de datos desde flujos de mensajes
Configurar flujos de mensajes coordinados globalmente
Manejar errores en flujos de mensajes
Adición de archivos a un archivador de intermediario
Edición de propiedades configurables
Referencia relacionada
Flujos de mensajes coordinados
Nodos incorporados
Bases de datos soportadas
Nodo JMSInput
Nodo JMSOutput
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Última actualización : 2009-02-16 13:53:29

ac00390_