Configurar nodos para flujos de mensajes coordinados

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

Antes de empezar:

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.

Para configurar el flujo de mensajes y los nodos:

  1. Vaya a la Perspectiva de 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
    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 subsiguientemente de forma satisfactoria o de forma anómala.
      Nota: En plataformas distintas de z/OS, es posible que las bases de datos relacionales individuales soporten o no soporten esta modalidad de operación.
    • 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 en este nodo bajo transacciones automáticas no se confirman, sino que permanecen dentro de una unidad de trabajo y pueden confirmarse o restituirse dependiendo de si el flujo de mensajes finaliza o no satisfactoriamente.
    Si desea 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, debe utilizar 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 lo hace así, los nodos que se confirman inmediatamente también confirmarán todas las operaciones realizadas en los nodos con transaccionalidad Automática anteriores.
    Nota: En plataformas distintas de z/OS, es posible que las bases de datos relacionales individuales soporten o no soporten 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 base de datos, se genera una excepción que el intermediario maneja de forma normal.

    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 aparecen en este flujo de mensajes:
    • MQInput
    • MQOutput
    • MQReply
    • 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 Input Modalidad de transacción del nodo MQOutput o 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 de nodo MQOutput o MQReply prevalece sobre 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 diferente a la de la tabla anterior. Consulte Nodo JMSInput y Nodo JMSOutput para más información.

    El valor por omisión en cada nodo de entrada es , que significa que los mensajes de entrada se procesan bajo punto de sincronización. Además, los mensajes que se envían al nodo de salida se entregan bajo punto de sincronización. 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 sincronización sólo si están definidos como persistentes. Los mensajes enviados al nodo MQOutput se entregan bajo punto de sincronización a menos que cambie, de forma explícita, 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 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. Vaya a la Perspectiva de Administración de intermediarios.
  7. Añada el flujo de mensajes a un archivador de intermediario.
  8. 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 el recuadro Transacción coordinada para configurar el flujo de mensajes como coordinado globalmente.

    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.

Conceptos relacionados
Visión general de flujos de mensajes
Transacciones de flujo de mensajes
Tareas relacionadas
Acceder a bases de datos desde flujos de mensajes
Configurar flujos de mensajes coordinados
Manejar errores en flujos de mensajes
Edición de propiedades configurables
Referencia relacionada
Bases de datos soportadas
Nodos incorporados
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
ac00393_