IBM Integration Bus, Version 9.0.0.8 Operating Systems: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

See information about the latest product version

Serialization of input between separate brokers on z/OS

This example demonstrates that only one input node at a time takes messages from a shared queue when the same serialization token is used by message flows running on separate brokers.

Two brokers (MQ01BRK and MQ02BRK) are configured in this example. The respective queue managers are called MQ01 and MQ02. The queue managers participate in the same queue sharing group. Each queue manager has a shared queue INQueue.QSG that has been defined with a disposition of QSG, and a local queue called INQueue. The queue managers can be running in the same Logical Partition (LPAR) or separate LPARs. The Coupling Facility shown in the diagram is a zSeries component that allows z/OS® WebSphere® MQ queue managers in the same system image, or different system images, to share queues.

An identical message flow MyFlowA is deployed to an integration server called MYGroupA on each broker. Note that the message flows do not have to be identical; the significant point is that an identical serialization token is used in both flows.

The simple message flow in this example consists of an MQInput node connected to an MQOutput node. The MQInput node in both message flows gets messages from the shared queue INQueue.QSG; the node attribute Serialization Token is configured as MyToken123ABC in both MQInput nodes.

The message flow property additional Instances takes the default value of zero in both message flows, which ensures that input is serialized within the flow.

Illustration showing multiple brokers participating in a queue-sharing group
A typical sequence of events for this example follows:
  1. The first broker MQ01BRK starts and runs message flow MyFlowA in integration server MyGroupA. The input node MyInputNode connects to queue manager MQ01 using a serialization token MyToken123ABC. The input node successfully opens shared queue INQUeue.QSG and gets input messages.
  2. The second broker MQ02BRK starts and begins to run its copy of message flow MyFlowA in integration server MyGroupA. The Input node MyInputNode attempts to connect to queue manager MQ02 , also using a serialization token MyToken123ABC.
    The following SDSF console message is logged:
     BIP2656I MQ02BRK MyGroupA 17 UNABLE TO OPEN QUEUE  
     'INQueue.QSG' ON WEBSPHERE BUSINESS INTEGRATION QUEUE 
     MANAGER 'MQ02': COMPLETION CODE 2; REASON CODE 2271. 
     :ImbCommonInputNode(759) BECAUSE SERIALIZATION TOKEN  
     MyToken123ABC is already in use. NO USER ACTION REQUIRED.   

    Note that this message is output every 30 minutes.

    Message flow MyFlowA in integration server MyGroupA running on broker MQ02BRK is unable to process input because the serialization token it has passed is already in use within the queue sharing group. This is indicated by the reason code 2271 (MQRC_CONN_TAG_IN_USE) in message bip2623.

  3. Broker MQ01BRK stops. Message flow MyFlowA in integration server MyGroupA in broker MQ02BRK2 is now able to get messages from the shared queue INQueue.QSG.
    A sequence of SDSF console messages is logged, of which the following two are relevant:
      BIP2091I MQ02BRK MyGroupA 17 THE BROKER HAS 
     RECONNECTED TO WEBSPHERE BUSINESS INTEGRATION 
     SUCCESSFULLY : ImbCommonInputNode(785)               
      BIP9142I MQ01BRK 0 THE COMPONENT HAS STOPPED. : 
     ImbControlService(594)              

The preceding sequence of events also occurs should broker MQ01BRK fail, rather than stop through a request from the operator, or if a new broker configuration is deployed to MQ01BRK that deletes or modifies message flow MyFlowA.

This arrangement can also be used where the requirement is to migrate message processing between brokers running in different z/OS system images that are attached to the same Coupling Facility.


ae27010_.htm | Last updated Friday, 21 July 2017