WebSphere Message Broker Version 8.0.0.5 Betriebssysteme: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Sehen Sie sich die Informationen zur aktuellen Produktversion im IBM Integration Bus Version 9.0 an.

Serielle Eingabeverarbeitung zwischen separaten Brokern unter z/OS

Dieses Beispiel veranschaulicht, dass immer nur jeweils ein Empfangsknoten Nachrichten aus einer gemeinsam genutzten Warteschlange nimmt, wenn Nachrichtenflüsse, die auf separaten Brokern ausgeführt werden, dasselbe Serialisierungs-Token verwenden.

In diesem Beispiel wurden zwei Broker (MQ01BRK und MQ02BRK) konfiguriert. Die jeweiligen Warteschlangenmanager haben die Bezeichnung MQ01 und MQ02. Die Warteschlangenmanager sind Mitglied derselben Gruppe mit gemeinsam genutzter Warteschlange. Jeder Warteschlangenmanager verfügt über eine gemeinsam genutzte Warteschlange INQueue.QSG, die mit der Disposition QSG definiert wurde, sowie über eine lokale Warteschlange namens INQueue. Die Warteschlangenmanager können in derselben logischen Partition (LPAR) oder in separaten logischen Partitionen ausgeführt werden. Bei der in den nachfolgenden Abbilungen gezeigten Coupling Facility handelt es sich um eine zSeries-Komponente, die unter z/OS Warteschlangenmanagern von WebSphere MQ im selben oder in verschiedenen Systemimages die gemeinsame Nutzung von Warteschlangen gestattet.

Ein identischer Nachrichtenfluss namens MyFlowA wird auf jedem Broker in eine Ausführungsgruppe namens MYGroupA implementiert. Die Nachrichtenflüsse müssen nicht identisch sein; wichtig ist, dass in beiden Flüssen ein identisches Serialisierungs-Token verwendet wird.

Der einfache Nachrichtenfluss in diesem Beispiel besteht aus einem MQInput-Knoten, der mit einem MQOutput-Knoten verbunden ist. Der MQInput-Knoten in beiden Nachrichtenflüssen erhält Nachrichten aus der gemeinsamen Warteschlange INQueue.QSG; das Knotenattribut Serialisierungs-Token wird in beiden MQInput-Knoten als MyToken123ABC konfiguriert.

Die Nachrichtenflusseigenschaft Zusätzliche Instanzen hat in beiden Nachrichtenflüssen den Standardwert null, wodurch sichergestellt wird, dass die Eingabe im Nachrichtenfluss serialisiert wird.

Abbildung mehrerer Broker, die Mitglied einer Gruppe mit gemeinsamer Warteschlange sind
Nachfolgend sehen Sie eine typische Folge von Ereignissen für dieses Beispiel:
  1. Der erste Broker MQ01BRK startet und führt den Nachrichtenfluss MyFlowA in der Ausführungsgruppe MyGroupA aus. Der Empfangsknoten MyInputNode stellt unter Verwendung des Serialisierungs-Tokens MyToken123ABC eine Verbindung zum Warteschlangenmanager MQ01 her. Der Empfangsknoten öffnet erfolgreich die gemeinsam genutzte Warteschlange INQUeue.QSG und erhält seine Eingabenachrichten.
  2. Der zweite Broker MQ02BRK startet und beginnt mit der Ausführung seiner Kopie des Nachrichtenflusses MyFlowA in der in Ausführungsgruppe MyGroupA. Der Empfangsknoten MyInputNode versucht ebenfalls mittels des Serialisierungs-Tokens MyToken123ABC, eine Verbindung zum Warteschlangenmanager MQ02 herzustellen.
    Folgende SDSF-Konsolnachricht wird protokolliert:
     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.   

    Diese Nachricht wird alle 30 Minuten ausgegeben.

    Der Nachrichtenfluss MyFlowA, der auf dem Broker MQ02BRK in der Ausführungsgruppe MyGroupA ausgeführt wird, kann die Eingabe nicht verarbeiten, da das Serialisierungs-Token, das er weitergegeben hat, bereits von der Gruppe mit einer gemeinsam genutzten Warteschlange belegt wird. Dies wird durch den Ursachencode 2271 (MQRC_CONN_TAG_IN_USE) in der Nachricht bip2623 angezeigt.

  3. Der Broker MQ01BRK stoppt. Der Nachrichtenfluss MyFlowA, der im Broker MQ02BRK2 in der Ausführungsgruppe MyGroupA ausgeführt wird, kann nun Nachrichten aus der gemeinsam genutzten Warteschlange INQueue.QSG empfangen.
    Es werden mehrere SDSF-Konsolnachrichten protokolliert, von denen zwei von Bedeutung sind:
      BIP2091I MQ02BRK MyGroupA 17 THE BROKER HAS 
     RECONNECTED TO WEBSPHERE BUSINESS INTEGRATION 
     SUCCESSFULLY : ImbCommonInputNode(785)               
      BIP9142I MQ01BRK 0 THE COMPONENT HAS STOPPED. : 
     ImbControlService(594)              

Die vorangegangene Folge von Ereignissen tritt auch dann auf, wenn der Broker MQ01BRK fehlschlägt (anstatt bei einer Anforderung des Operators zu stoppen), oder dann, wenn eine neue Broker-Konfiguration, die den Nachrichtenfluss MyFlowA löscht oder ändert, in MQ01BRK implementiert wird.

Diese Zusammenstellung kann auch eingesetzt werden, wenn die Nachrichtenverarbeitung zwischen Brokern migriert werden soll, die auf verschiedenen z/OS-Systemimages ausgeführt werden, welche derselben Coupling Facility zugeordnet sind.

Bemerkungen | Marken | Downloads | Bibliothek | Support | Feedback

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Letzte Aktualisierung:
        
        Letzte Aktualisierung: 2015-02-28 16:21:14


KonzeptthemaKonzeptthema | Version 8.0.0.5 | ae27010_