WebSphere Message Broker Version 8.0 weist einige kleinere Änderungen im Verhalten auf. Diese Änderungen können beispielsweise durch Mängel verursacht worden sein, die zwischen den Versionen behoben wurden.
Message Broker-API-Anwendungen, die Sie in der Version 8.0 entwickeln, können sich mit Ihren bestehenden Brokern der Version 7.0 verbinden, und Ihre bestehenden Message Broker-API-Anwendungen der Version 7.0 können sich mit den Brokern der Version 8.0 verbinden.
Wenn Sie jedoch eine Migration aus Version 6.1 vornehmen, müssen Sie Ihre Message Broker-API-Anwendungen aktualisieren, damit sie die Datei verwenden, die in der Version 8.0 bereitgestellt wird. Erst dann ist eine Verbindung mit dem Broker der Version 8.0 möglich.
Der Abschnitt Message Broker-API-Anwendungen migrieren enthält weitere Informationen hierzu.
Die Aufzeichnungs- und Wiedergabefunktion kann nur bei den neuen Brokern derVersion 8.0 oder bei Brokern verwendet werden, die auf Version 8.0 migriert wurden. Sie kann nicht in Verbindung mit bestehenden Brokern der Version 7.0 oder Version 6.1 verwendet werden.
Der Abschnitt Aufzeichnung und Wiedergabe enthält weitere Informationen hierzu.
Gemeinsam mit einem MQMD-Header, der das FORMAT MQSTR aufweist, werden jetzt XML-Veröffentlichungsnachrichten zu Ressourcenstatistiken und Abrechnungs- und Statistikdaten für Nachrichtenflüsse veröffentlicht. Dies bedeutet, dass sich die Veröffentlichungsnachricht gänzlich aus Zeichendaten zusammensetzt.
Falls zum Abonnieren des Veröffentlichungsthemas und zum Lesen der Nachrichten eine WebSphere MQ-JMS-Anwendung verwendet wird, werden diese Nachrichten in Form einer JMS-TextMessage und nicht in Form einer JMS-BytesMessage dargestellt.
WebSphere Message Broker Version 8.0 wird zum Zweck der Konvertierung von Datum, Uhrzeit und Codepage mit ICU V4.8 (International Components for Unicode) ausgeliefert. Dabei handelt es sich um ein Upgrade von ICU 3.8.1, das mit WebSphere Message Broker Version 7.0 ausgeliefert wurde.
Die folgenden Verhaltensänderungen betreffen Sie nur, wenn Sie eine Migration aus Version 6.1 vornehmen.
Wenn Sie eine frühere Version eines Windows-Brokers wiederherstellen, wird der Kennwortwert mit dem Broker wiederhergestellt. Wenn Sie das Kennwort mit dem Befehl mqsichangebroker geändert haben, wird in der früheren Version der aktualisierte Wert gesetzt.
Wenn Sie Datenbankbenutzer-IDs und Kennwörter für den Broker konfiguriert haben, der migriert wird, werden diese Parameter (-u, -p) zusammen mit dem Broker migriert und als Standardwerte für Datenquellen (Benutzerdatenbanken) verwendet, für die Sie keine expliziten Werte festlegen. Wenn Sie -u, -p nicht konfiguriert haben, werden die Werte für -i, -a migriert. In Version 8.0 können diese Benutzer-IDs und Kennwörter für Ihre Benutzerdatenbanken mit dem Befehl mqsisetdbparms verwaltet werden.
Die Eigenschaften für die Lang- und Kurzbeschreibungen der implementierten Nachrichtenbroker-Artefakte wurden nicht im Repository der implementierten Ausführungsgruppe gespeichert und werden daher nicht auf den Version 8.0-Broker migriert.
Wenn die folgenden Felder für Schlüsselwörter verwendet wurden, werden Sie nicht in den migrierten Artefakten angezeigt:
$MQSI Name = Wert MQSI$
Um dieses Verhalten zu korrigieren, müssen Sie die Artefakte direkt auf dem Broker der Version 8.0 implementieren.
Weitere Informationen zur Definition von Schlüsselwörtern finden Sie im Abschnitt Anleitung zum Definieren von Schüsselwörtern.
In einigen Musterprogrammen wie der Flugreservierung wird eine Datenbank verwendet. Wenn Sie mithilfe des Assistenten für die Standardkonfiguration eine Standardkonfiguration unter Windows eingerichtet und Musterprogramme auf dem Standardbroker implementiert haben, wird für die Musterprogramme, für die eine Datenbank erforderlich ist, die im Broker integrierte Derby-Datenbank verwendet. Allerdings wird in Version 8.0 keine Derby-Datenbank bereitgestellt oder unterstützt. Sie müssen die Datenbankbeispiele entsprechend den in der Dokumentation für die Musterprogramme aktualisierten Hinweisen neu konfigurieren.
Bei der Erstellung eines Brokers mit dem Befehl mqsicreatebroker wird jetzt keine Standardausführungsgruppe mehr erstellt.
Wenn Sie einen Broker mit WebSphere Message Broker Toolkit oder WebSphere Message Broker Explorer erstellen, können Sie eine Option auswählen, bei der eine Standardausführungsgruppe mit dem Namen default erstellt wird (sofern Sie keinen anderen Namen angeben).
Sie können Ausführungsgruppen auch mit dem Befehl mqsicreateexecutiongroup erstellen.
Der Start- und Stoppvorgang für Ausführungsgruppen wurde in Version 8.0 aktualisiert. Wenn Sie eine Ausführungsgruppe mit dem Befehl mqsistartmsgflow oder mqsistopmsgflow ohne Angabe des Parameters -m starten oder stoppen, wird der Ausführungsgruppenprozess gestoppt bzw. gestartet. Wird eine Ausführungsgruppe auf diese Weise oder mit dem WebSphere Message Broker Toolkit oder WebSphere Message Broker Explorer gestoppt, wird der Ausführungsstatus der Nachrichtenflüsse, die in der Ausführungsgruppe implementiert sind, aufgezeichnet. Beim nächsten Start der Ausführungsgruppe werden nur die Nachrichtenflüsse erneut gestartet, die aktiv waren, als die Ausführungsgruppe gestoppt wurde; dies gilt nicht, wenn Sie explizit darauf bestehen, dass alle Nachrichtenflüsse erneut gestartet werden sollen, oder den Befehl unter Angabe des Parameters -j ausführen.
Die Eigenschaft Aktion bei Fehler der SOAPAsyncRequest, SOAPInput und SOAPRequest ist nicht mehr konfigurierbar. Wenn Sie diese Eigenschaft konfiguriert haben, z. B. in einer BAR-Datei, wird die Einstellung ignoriert.
Der Broker der Version 8.0 sucht nach der erforderlichen SSL-Konfiguration, wenn Sie den Befehl mqsistart ausführen.
Wenn Sie auf einem Broker der Version 6.1 einen Nachrichtenfluss implementiert haben, der HTTPInput oder HTTPReply enthält, und den Broker auf Version 8.0 migrieren und erneut starten, wird möglicherweise die folgende Fehlernachricht generiert. (Die Nachrichtenzeilen sind fortlaufend, werden jedoch zur besseren Lesbarkeit umgebrochen).
BIP3135S: An exception occurred while starting the servlet engine connector. (Beim Starten des Connectors der Servletsteuerkomponente ist eine Ausnahmebedingung aufgetreten.)
Exception text is HTTP Listener LifecycleException: (Der Ausnahmebedingungstext lautet: (Ausnahmebedingung 'LifecycleException' des HTTP-Empfangsprogramms:
Protocol handler start failed (Protokollhandlerstart fehlgeschlagen): java.io.FileNotFoundException: /home/leed/.keystore
(No such file or directory) (Datei oder Verzeichnis nicht vorhanden)
at org.apache.coyote.tomcat5.CoyoteConnector.start(CoyoteConnector.java:1529)
at com.ibm.broker.httplistener.ConnectorWrapper.start(ConnectorWrapper.java:166)
at com.ibm.broker.httplistener.TomcatWrapper.startSecureHTTPSConnector
(TomcatWrapper.java:146)
at com.ibm.broker.httplistener.HTTPListenerManager.ensureServletContainer
(HTTPListenerManager.java:290)
at com.ibm.broker.httplistener.HTTPListenerManager.run(HTTPListenerManager.java:153)
at java.lang.Thread.run(Thread.java:735) :
DANBRK.httplistener: /build/S000_P/src/DataFlowEngine/NativeTrace/ImbNativeTrace.cpp: 732:
ensureServletContainer: :
Oct 13 13:47:16 partick user:err|error WebSphere Broker v8000[303572]:
(DANBRK.default)[1]BIP2275E: Fehler beim Laden von Nachrichtenfluss 'ef2a0606-2401-0000-0080-984a4915984c'. :
DANBRK.de427601-2401-0000-0080-d525e90f1528: /build/S000_P/src/DataFlowEngine/ImbDataFlowDirector.cpp:
2957: ImbDataFlowDirector::loadAllDataFlowsFromDatabase:
ExecutionGroup: de427601-2401-0000-0080-d525e90f1528
Dieser Fehler wird generiert, weil der Broker der Version 8.0 erkennt, dass Sie die HTTP-Knoten im Nachrichtenfluss für die Verwendung von HTTPS konfiguriert, aber nicht die erforderliche SSL-Konfiguration erstellt haben. Der Broker lädt den Nachrichtenfluss nicht. In früheren Versionen wird diese Prüfung nicht durchgeführt und es wird kein Fehler generiert.
Um diesen Fehler zu beheben, konfigurieren Sie Ihre HTTP-Knoten für die Verwendung von SSL und implementieren Sie den Nachrichtenfluss erneut. SSL-Konfigurationsinformationen finden Sie im Abschnitt HTTPInput- und HTTPReply-Knoten für die Verwendung von SSL (HTTPS) konfigurieren.
Das Standardverhalten für die Veröffentlichung von Überwachungsereignissen hat sich geändert. Vor Version 8.0 wurden Überwachungsereignisse unabhängig vom Synchronisationspunkt ausgegeben. Nun werden alle Ereignisse, mit Ausnahme von Transaktionsrollbacks, standardmäßig nur dann ausgegeben, wenn der Nachrichtenfluss seine Arbeitseinheit erfolgreich festschreibt. Transaktionsrollbacks werden standardmäßig in einer zweiten Arbeitseinheit ausgegeben, die von der Hauptarbeitseinheit unabhängig ist.
Aufgrund dieser Änderung sehen Sie keine Ereignisse mehr, die wegen eines fehlgeschlagenen Nachrichtenflusses zurückgesetzt werden. Sie sehen nur das Transaktionsstartereignis und das Transaktionsrollback-Ereignis (sofern diese Ereignisse definiert sind). Außerdem sehen Sie alle anderen Ereignisse, die für eine unabhängige Arbeitseinheit definiert sind. Weitere Informationen finden Sie im Abschnitt Grundlegende Informationen zur Überwachung.
Dem Element 'eventSequence' des Überwachungsereignisses wird eine Folgenummer hinzugefügt. Da sowohl die Erstellungsuhrzeit als auch die Folgenummer immer im Überwachungsereignis ausgegeben werden, wird die Registerkarte Reihenfolge aus der Überwachungsregisterkarte im WebSphere Message Broker Toolkit entfernt.
Die Gültigkeit des Feldreferenzindex null wurde korrigiert. Wenn Ihre ESQL-Module Anweisungen enthalten, die den Index null enthalten, wird der Fehler BIP3226E generiert, wenn Sie den Nachrichtenfluss implementieren.
Wenn Ihr Code beispielsweise folgende Anweisung enthält:
SET OutputRoot.XMLNSC.Top.A[0].B = 42;
Sie müssen den Code aktualisieren, sodass er folgenden Inhalt hat:
SET OutputRoot.XMLNSC.Top.A[1].B = 42;
Der Standardwert für die Eigenschaft Richtlinie für Tiefe des RegistryLookups wird von dem Wert Nur Übereinstimmungen liefern, unmittelbare Abhängigkeiten anzeigen (nur aus Gründen der Kompatibilität) in Version 6.1 in den Wert Nur Übereinstimmungen liefern (Tiefe = 0) in Version 8.0 geändert.
Wenn Sie diese Eigenschaft nicht explizit für einen RegistryLookup-Knoten festlegen, verwendet er den Standardwert Nur Übereinstimmungen liefern (Tiefe = 0), um die Tiefe der WSRR-Abfrage und den Inhalt der zurückzugebenden Entitätsdaten zu ermitteln.
Wenn Sie den Knoten im veralteten Modus von Version 8.0 verwenden möchten, müssen Sie die Eigenschaft Richtlinie für Tiefe explizit auf den Wert Nur Übereinstimmungen liefern, unmittelbare Abhängigkeiten anzeigen (nur aus Gründen der Kompatibilität) setzen und die BAR-Datei erneut erstellen.
Weitere Informationen zum RegistryLookup-Knoten und seinen Eigenschaften finden Sie im Abschnitt RegistryLookup-Knoten.
Das WebSphere Message Broker Toolkit weist folgende Änderungen auf:
In WebSphere Message Broker Version 7.0.0.2 wurde die Größe des Standardtrace für den Verwaltungsagenten von 4 MB in 100 MB geändert. Wenn Sie eine Migration von WebSphere Message Broker Version 7.0.0.1 oder einer früheren Version durchführen, müssen Sie diese Standardgröße berücksichtigen.