Serialización de la entrada entre servidores de integración independientes que se ejecutan en el mismo nodo de integración en z/OS

Este ejemplo demuestra que sólo se permite que un nodo MQInput a la vez tome mensajes de una cola compartida cuando la misma señal de serialización la utilizan los flujos de mensajes que se ejecutan en servidores de integración independientes en el mismo nodo de integración.

Un flujo de mensajes idénticoMyFlowAse despliega en dos servidores de integración llamadosMYIntServerAyMYIntServerBen nodo de integraciónintegrationNodeName.

En este caso, el gestor de colas no participa en un grupo de compartición de cola. La cola de entradaINQueuese define comolocalcon disposiciónQMGR.

Los flujos de mensajes no han de idénticos; lo importante es que se utiliza una señal de serialización idéntica en ambos flujos.

El flujo de mensajes simple de este ejemplo consta de un nodo MQInput conectado a un nodo MQOutput. El nodo MQInput de ambos flujos de mensajes obtiene mensajes de la cola compartidaINQueue.QSG; el atributo de nodoSerialization Tokense configura comoMyToken123ABCen ambos nodos de MQInput .

La propiedad de flujo de mensajesadditional Instancestoma el valor predeterminado de cero en ambos flujos de mensajes, lo que asegura que la entrada se serializa dentro del flujo.

Ilustración que muestra varios servidores de integración en el mismo nodo de integración
A continuación se muestra una secuencia típica de sucesos para este ejemplo:
  1. Nodo de integraciónintegrationNodeNameempieza y el primer flujo de mensajes para empezar esMyFlowAen servidor de integraciónMyIntServerA. El nodo MQInputMyInputNodese conecta al gestor de colasMQ01utilizando la señal de serializaciónMyToken123ABC. El nodo MQInput abre correctamente la cola compartidaINQueuey obtiene mensajes de entrada.
  2. El segundo servidor de integraciónMyIntServerBInicio y flujo de mensajesMyFlowAen servidor de integraciónMyIntServerBcomienza. El nodo MQInputMyInputNodeahora intenta conectarse al gestor de colasMQ01utilizar señal de serializaciónMyToken123ABC. Se registra el siguiente mensaje de consola de SDSF :
     BIP2656I integrationNodeName MyIntServerB 11 UNABLE TO OPEN QUEUE
     'INQueue' ON IBM INTEGRATION BUS QUEUE 
     MANAGER 'MQ01':  BECAUSE SERIALIZATION TOKEN  
     MyToken123ABC is already in use. NO USER ACTION REQUIRED
    

    Flujo de mensajesMyFlowAen servidor de integraciónMyIntServerBno puede procesar la entrada porque la señal de serialización que ha pasado ya está en uso en el gestor de colas (por el nodo MQInput en el flujo de mensajesMyFlowAen servidor de integraciónMyIntServerA). Esto se indica mediante el código de razón2271 (MQRC_CONN_TAG_IN_USE)en el mensaje bip2623.

  3. El primer servidor de integración se suprime o cancela.

    Si el operador cancela el primer servidor de integración, finaliza con una terminación anómala o se suprime durante un redespliegue de la configuración del nodo de integración, el nodo de entrada del segundo servidor de integración ahora puede obtener mensajes de entrada de la colaINQueue.

    Se registra una secuencia de mensajes de consola SDSF, de los cuales es importante el siguiente:
      BIP2091I integrationNodeName MyIntServerB 11 THE INTEGRATION NODE HAS 
     RECONNECTED TO IBM INTEGRATION BUS 
     SUCCESSFULLY : ImbCommonInputNode(785)               
    

Flujo de mensajes MyFlowAen servidor de integraciónMyIntServerBahora puede recuperar el proceso de los mensajes de la cola compartidaINQueue.QSG.

Tenga en cuenta que, aunque se puede lograr la serialización de la entrada de un modo similar configurando la cola de entrada para entrada exclusiva, esto no asegura la integridad de los mensajes durante una situación de recuperación. Esto sólo se puede lograr mediante el uso de la señal de serialización tal como se describe en este ejemplo.