Configuración de nodos de flujos de mensajes para flujos de mensajes coordinados

Si desea coordinar el proceso de flujo de mensajes con otros recursos, debe configurar propiedades tanto de los nodos del flujo de mensajes como del flujo de mensajes en sí mismo.

Antes de empezar:

Para realizar esta tarea, debe haber completado la tarea siguiente:

Un flujo de mensajes se debe ejecutar en una sola transacción, que se inicia cuando un nodo de entrada recibe un mensaje y se puede confirmar o restituir una vez que se ha completado todo el proceso. También puede controlar el manejo de los errores de base de datos por parte del nodo que interactúa con la base de datos.

Para configurar el flujo de mensajes y los nodos:

  1. Conmute a la perspectiva Desarrollo de aplicaciones de intermediario.
  2. Abra el flujo de mensajes con el que desea trabajar o cree un nuevo flujo de mensajes.
  3. Establezca la propiedad Transacción para los nodos siguientes si aparecen en este flujo de mensajes:
    • Compute
    • Database
    • DataDelete
    • DataInsert
    • DataUpdate
    • Filter
    • Mapping
    • Warehouse

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

    Automática
    Todas las actualizaciones, supresiones y adiciones que lleva a cabo el nodo se confirman o restituyen cuando finaliza el proceso del flujo de mensajes. Si el flujo de mensajes se completa satisfactoriamente, se confirman todos los cambios. Si el flujo de mensajes no se completa satisfactoriamente, se restituyen todos los cambios.

    Si desea que el flujo de mensajes coordine todo el proceso, debe seleccionar este valor.

    Confirmar
    La acción que se lleva a cabo depende del sistema en el que se ha difundido el flujo de mensajes:
    • En sistemas distribuidos, todos los trabajos que ha realizado el flujo de mensajes hasta el momento, incluidas las acciones que se han efectuado en este nodo, se confirman sin tener en cuenta el posterior éxito o error del flujo de mensajes.
    • En z/OS, las acciones que se realizan en este nodo sólo se confirman sin tener en cuenta el posterior éxito o error del flujo de mensajes. No se confirma ninguna acción llevada a cabo en este nodo antes de la transaccionalidad automática, pero permanecen en una unidad de trabajo y se pueden confirmar o restituir en función del éxito del flujo de mensajes.

    Si desea mezclar nodos con transaccionalidad Automática y Confirmar en el mismo flujo de mensajes, donde los nodos operan en la misma base de datos externa, debe utilizar conexiones ODBC separadas: una para los nodos que no se confirman hasta que se completa el flujo de mensajes y otra para los nodos que se deben confirmar inmediatamente. De lo contrario, los nodos que se confirman inmediatamente también confirman las operaciones que han llevado a cabo nodos de transaccionalidad Automática anteriores.

    Si define más de una conexión ODBC pueden producirse problemas de bloqueo de base de datos. En especial, si un nodo con transaccionalidad Automática realiza una operación como, por ejemplo, INSERT o UPDATE, que hace que se bloquee un objeto de base de datos (por ejemplo, una tabla) y el nodo siguiente intenta acceder al objeto de base de datos utilizando una conexión ODBC, se produce un bloqueo infinito (punto muerto).

    El segundo nodo espera que se libere el bloqueo que ha adquirido el primero, pero el primer nodo no confirma sus operaciones, ni libera el bloqueo hasta que se completa el flujo de mensajes, lo que no sucede nunca, puesto que el segundo nodo está a la espera de que el se libere el bloqueo del primer nodo.

    Ninguna rutina de evitación de bloqueo automático de DBMS puede detectar este tipo de situación, puesto que ambas operaciones interfieren indirectamente entre sí, utilizando el intermediario.

    Para evitar este tipo de problema de bloqueo, existen dos procedimientos:

    • Diseñar el flujo de mensajes de modo que las operaciones no confirmadas (automáticas) no bloqueen objetos de base de datos a las que necesiten acceder operaciones posteriores que utilicen una conexión ODBC diferente.
    • Configurar el parámetro de tiempo de espera de bloqueo de base de datos de modo que no se pueda intentar adquirir un bloqueo una vez transcurrido un tiempo especificado. Si una operación de base de datos da error debido a un tiempo de espera de bloqueo, se emite una excepción que el intermediario maneja mediante los procedimientos normales.

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

  4. Establezca la propiedad Modalidad de transacción para los nodos siguientes, si aparecen en este flujo de mensajes:
    • MQeInput
    • MQInput
    • MQOutput
    • MQReply
    • SCADAInput

    En la tabla siguiente se proporciona un resumen de las acciones llevadas a cabo en respuesta a valores de propiedades específicos para los nodos de entrada y salida.

    Permanencia del mensaje 1 Modalidad de transacción del nodo Input Modalidad de transacción del nodo MQOutput o MQReply Flujo de mensajes coordinado globalmente
    Automática
    No Automática
    No Automática No
    No No Automática No
    Automática Automática
    No Automática Automática No
    Ninguno 2 Ninguno 2
    Ninguno 2 Ninguno 2 No No
    Notes:
    1. La permanencia sólo es importante para los mensajes que se reciben 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 de los nodos MQOutput o MQReply altera temporalmente el valor que se establece aquí.

    El valor por omisión en cada nodo de entrada es , lo que significa que los mensajes entrantes 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. Ambos tienen una propiedad Modalidad de transacción.

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

  5. Establezca Tratar los avisos como errores y *Generar excepción en error de la base de datos para cada nodo que acceda a la base de datos para indicar cómo desea que el nodo maneje los avisos y los errores de la base de datos. El modo de seleccionar estas propiedades y de conectar los terminales de anomalías de los nodos también afecta al modo en que se confirman o restituyen las actualizaciones de base de datos.
  6. Conmute a la perspectiva Administración de intermediarios.
  7. Añada el flujo de mensajes a un archivo de datos antiguos de intermediario.
  8. Seleccione el separador Configurar, situado debajo de la vista del editor de archivos de datos antiguos de intermediarios y seleccione el flujo de mensajes. De este modo se muestran las propiedades configurables del flujo de mensajes del archivo de datos antiguos del intermediario. Seleccione el recuadro de selección Transacción coordinada para configurar el flujo de mensajes como coordinado globalmente.

    En z/OS, las transacciones siempre se coordinan globalmente. Se ignora el establecimiento de la propiedad Transacción coordinada para un flujo de mensajes. RRS siempre proporciona la coordinación.

Conceptos relacionados
Flujos de mensajes

Tareas relacionadas
Acceso a bases de datos desde flujos de mensajes
Configuración de flujos de mensajes coordinados
Manejo de errores en flujos de mensajes
Edición de propiedades configurables

Referencia relacionada
Bases de datos soportadas
Nodos incorporados