Migrationshinweise für Nachrichtengruppen

Diese Hinweise sollen Ihnen bei der Migration von Nachrichtengruppen nach WebSphere Message Broker Version 6.0 helfen.

Dieses Thema enthält folgende Abschnitte:

Wenn Sie das Message Brokers Toolkit Version 5.1, ersetzen Sie alle Verweise auf "Version 5.0" durch "Version 5.1".

Migration von Version 2.1

Um Nachrichtengruppen von Version 2.1 auf Version 6.0 zu migrieren, verwenden Sie den Befehl mqsimigratemsgsets, um Exportdateien für Nachrichtengruppen (MRP-Dateien) der Version 2.1 in Nachrichtengruppenprojekte der Version 6.0 zu konvertieren. Lesen Sie vor Ausführung des Befehls den Abschnitt Nachrichtengruppen von Version 2.1 migrieren. Er enthält detaillierte Informationen zur Ausführung dieses Vorgangs.

Die folgenden Abschnitte enthalten Anleitungen für Änderungen des Verhaltens von Parsern sowie allgemeine Migrationsinformationen:

Migration von Version 5.0

Um Nachrichtengruppen von Version 5.0 auf Version 6.0 zu migrieren, müssen keine Migrationsbefehle ausgeführt werden. Das Message Brokers Toolkit Version 6.0 kann den Inhalt eines Nachrichtengruppenprojekts der Version 5.0 lesen und automatisch in das Format der Version 6.0 konvertieren, wenn es zum ersten Mal geändert und gespeichert wird.

Die folgenden Abschnitte enthalten Anleitungen für Änderungen des Verhaltens von Parsern sowie allgemeine Migrationsinformationen:

Änderungen im Verhalten des MRM-Parsers

    Die folgenden Änderungen werden in Version 6.0 implementiert und sind relevant, wenn eine Migrationvon Version 5.0 und von Version 2.1 durchgeführt wird:
    • Physisches XML-Format. Version 6.0 berücksichtigt Attribute des Typs "xsi:type" im XML-Dokument und ändert deren Verhalten entsprechend. Attribute des Typs "xsi:type" werden nicht mehr als selbstdefinierende Attribute behandelt. Deshalb werden sie in der Nachrichtenbaumstruktur mit dem Namen 'type' statt '@type' angezeigt. Wenn Ihre Nachrichtenflusslogik Attribute des Typs "xsi:type" in der Nachrichtenbaumstruktur berücksichtigt, müssen Sie Ihren Nachrichtenfluss dem neuen Verhalten entsprechend ändern. Um die Logik der Versionen vor Version 6.0 in Ihren Nachrichtenflüssen beizubehalten, setzen Sie die Umgebungsvariable MQSI_IGNORE_XSI_TYPE auf einen beliebigen Wert, und das Verhalten vor Version 6.0 wird übernommen.
    • Physisches XML-Format. DOCTYPE-Informationen in einem XML-Dokument werden bei der syntaktischen Analyse nicht in der logischen Nachrichtenbaumstruktur angezeigt. Sie werden jedoch vom Eingabedokument zum Ausgabedokument beibehalten, da das MRM eine interne Kopie der DOCTYPE-Infos speichert. In Versionen vor Version 6.0 sind diese Daten eine exakte Kopie des Bitstroms. In Version 6.0 gehen während des Kopiervorgangs Formatierungsleerzeichen verloren. Das folgende Beispiel zeigt eine Elementdeklaration in einem Eingabe-DOCTYPE:
      <!ELEMENT e0 (e1|e2)+ >
      In der Ausgabenachricht hat sich die Elementdeklaration geändert:
      <!ELEMENT e0 (e1|e2)+>
      Das neue Verhalten entspricht der Art und Weise, wie das physische XML-Format Leerzeichen in allen anderen XML-Konstrukten verarbeitet.
    • Physisches TDS-Format. Wenn für eine Gruppe die logische Eigenschaft Zusammensetzung auf Auswahl und die TDS-Eigenschaft Trennung von Datenelementen auf Feste Länge gesetzt werden, geht der Parser immer davon aus, dass die Länge der Auswahldaten der des längsten untergeordneten Elements in der Gruppe entspricht, und liest und schreibt immer diese Anzahl Zeichen. Stellen Sie sicher, dass Sie Ihre Nachrichten diese Voraussetzung erfüllen. Andernfalls werden die Daten, die der Auswahl folgen, vom Parser als Teil der Auswahl behandelt. In Versionen vor Version 6.0 wird diese Regel vom Parser nicht umgesetzt.
    • Physisches TDS-Format. Wenn die TDS-Elementeigenschaft Nullwertcodierung auf NullPadFill gesetzt ist, wird darauf nur reagiert, wenn die entsprechende Eigenschaft Länge bei der syntaktischen Analyse oder beim Schreiben aktiv verwendet wird. In Versionen vor Version 6.0 wird auf NullPadFill stets reagiert, unabhängig davon, ob die Eigenschaft Länge aktiv verwendet wird oder nicht.
    • Physisches TDS-Format. TDS-Eigenschaft Trennung von Datenelementen ist auf Trennzeichen für alle Elemente bzw. Elemente variabler Länge mit Begrenzer gesetzt. Ein komplexes Element wird in der aktuellen Version stets als Element variabler Länge behandelt, unabhängig von der ihm zugewiesenen Einstellung für Trennung von Datenelementen. Deshalb wird im Nachrichtenbitstrom ein Begrenzer zwischen dem komplexen Element und allen darauf folgenden Elementen erwartet. Darüberhinaus wird ein Begrenzer für Wiederholelemente zwischen allen Instanzen eines komplexen Elements erwartet, auch wenn es sich um ein komplexes Element mit fester Länge handelt. In Versionen vor Version 6.0 wird diese Regel vom Parser nicht umgesetzt, und der Writer gibt für Elemente variabler Länge mit Begrenzer keine Begrenzer aus, wenn die Länge des komplexen Elements unbekannt war.
    • Physisches TDS-Format. TDS-Eigenschaft Trennung von Datenelementen ist auf Datenmuster verwenden gesetzt. Wenn der reguläre Ausdruck, der für ein Datenmuster angegeben wird, eine Übereinstimmung mit einer Null-Länge zurückgibt, wird er als ein Element mit einem Wert mit Null-Länge behandelt. In Versionen vor Version 6.0 werden Übereinstimmungen mit Null-Länge übergangen.
    • Physisches TDS-Format. TDS-Eigenschaft Trennung von Datenelementen ist auf Mit Kennung/Begrenzer gesetzt. Ein externer Begrenzer nach dem letzten untergeordneten Element der Gruppe im Bitstrom wird nicht mehr akzeptiert und verursacht eine Ausnahmebedingung bei der Syntaxanalyse. Wenn dies ein Problem darstellt, können Sie den externen Begrenzer beispielsweise über die TDS-Eigenschaft Gruppenbegrenzer modellieren. In Versionen vor Version 6.0 wird diese Regel vom Parser nicht umgesetzt.
    • Physisches TDS-Format. TDS-Eigenschaft Trennung von Datenelementen ist auf Mit Kennung/Begrenzer gesetzt. In Version 6.0 versucht der Parser bei der Syntaxanalyse einer Gruppe Mit Kennung/Begrenzer eine angemessene Deutung von Gruppen, in denen die Member im Nachrichtenbitstrom nicht in der richtigen Reihenfolge erscheinen, auch wenn die Eigenschaft Zusammensetzung auf Folge bzw. Elemente in angegebener Reihenfolge gesetzt ist. Wenn in der Gruppe jedoch eine eingebettete Nachricht oder ein komplexes Element bzw. eine Gruppe enthalten ist, die bzw. das im Bitstrom nicht identifiziert werden kann, müssen alle Elemente der Gruppe im Bitstrom in der Reihenfolge erscheinen, die im Modell definiert ist. Wenn sie nicht in der definierten Reihenfolge erscheinen, wird die Gruppe nicht korrekt syntaktisch analysiert, und es kommt zu unvorhersehbaren Ergebnissen. Ein Symptom für diesen Zustand ist das Auftreten von selbstdefinierenden Elementen in der Nachrichtenbaumstruktur, die dadurch verursacht wurde, dass der Abgleich eines Elements mit dem Modell fehlgeschlagen ist.

      Ein spezielles Beispiel für diesen Zustand ist, wenn Ihre Nachricht eine eingebettete Nachricht enthält und Sie entweder das Nachrichtenschlüssel- oder das Nachrichten-ID-Verfahren zur Identifikation der eingebetteten Nachricht verwenden. Wenn ein Abgleich des Elements, von dem der Nachrichtenschlüssel oder die Nachrichten-ID stammt, mit dem Modell fehlschlägt, weiß der Parser nicht, ob er den Wert als Nachrichtenschlüssel oder Nachrichten-ID interpretieren soll.

      In Versionen vor Version 6.0 versucht der Parser eine angemessene Deutung nicht sortierter Gruppen Mit Kennung/Begrenzer, was zu Leistungseinbußen führt. Wenn dieses Verhalten in Version 6.0 ein Problem darstellt, können Sie den nicht sortierten Inhalt der Gruppe als eingebettete untergeordnete Gruppe modellieren, wobei die Eigenschaft Zusammensetzung auf Elemente in beliebiger Reihenfolge gesetzt werden sollte.

      Ein komplexes Element bzw. eine Gruppe kann im Bitstrom über einen Gruppenanzeiger, eine Kennung oder ein Datenmuster identifiziert werden. Eine Identifikation ist auch über den Gruppenanzeiger, die Kennung oder das Datenmuster der untergeordneten Elemente möglich.

      Trotz des Namens gibt es Umstände, in denen die Elemente einer Gruppe Mit Kennung/Begrenzer keine Kennung bereitstellen müssen, insbesondere wenn das Element eine eingebettete Nachricht oder ein komplexes Element bzw. eine Gruppe ist.

    • Physisches TDS-Format. Die TDS-Eigenschaft Trennzeichen für Datenelemente ist auf Mit Kennung/codierter Länge gesetzt. Beim Schreibvorgang wird die codierte Länge als Anzahl der Zeichen in den Daten ausgegeben, um eine Übereinstimmung mit der Interpretation bei der syntaktischen Analyse zu erreichen. In Versionen vor Version 6.0 wird die codierte Länge als Anzahl der Bytes in den Daten ausgegeben, was zu Abweichungen von der Interpretation bei der syntaktischen Analyse führt, wenn andere Daten als SBCS-Daten verarbeitet werden.
    • Physisches TDS-Format. Wenn beim Schreiben von Daten die Anzahl der Wiederholungen eines Elements oder einer Gruppe im Modell festgelegt ist, das tatsächliche Auftreten in der logischen Nachrichtenbaumstruktur jedoch diese Anzahl der Wiederholungen übersteigt und als Eigenschaft Trennzeichen für Datenelemente keines der Trennzeichen mit Kennung angegeben wurde, werden die zusätzlichen Vorkommen verworfen und erscheinen nicht in der Ausgabenachricht. In Versionen vor Version 6.0 sind diese zusätzlichen Vorkommen in der Ausgabenachricht enthalten. Wenn die zusätzlichen Vorkommen in der Ausgabenachricht enthalten sein sollen, legen Sie maxOccurs=-1 fest, um damit anzuzeigen, dass die Häufigkeit unbestimmt ist.
    • Alle physischen Formate. Beim Schreiben von Datum/Zeit-Feldern (dateTime) mit der Formateigenschaft I richtet sich das Ausgabeformat nach dem logischen Typ des Feldes (siehe Erläuterung unter Datum/Zeit als Zeichenfolgedaten). In Versionen vor Version 6.0 ist das Ausgabeformat fälschlicherweise das vollständige Format jjjj-MM-dd'T'HH:mm:ssZZZ.
    • Die Validierung von Eingabe- und Ausgabenachrichten wurde verbessert, um ungültige Nachrichten besser erkennen zu können. In Version 6.0 kann eine Nachricht deshalb als ungültig gekennzeichnet werden, wenn sie in früheren Versionen fälschlicherweise nicht gekennzeichnet wurde.

    Allgemeine Migrationsinformationen

    Die folgenden Informationen sind relevant, wenn eine Migrationvon Version 5.0 und von Version 2.1 durchgeführt wird:
    • Die CWF-Eigenschaft Wiederholungszähler wird durch die logische Eigenschaft Maximale Anzahl überlagert. Damit wird das physische CWF-Format an das physische TDS-Format und XML-Format angeglichen, die Maximale Anzahl zum Festlegen der Anzahl der Wiederholungen bereits verwenden. Für jedes Element bzw. jede Gruppe, für das bzw. die ein Wert für die CWF-Eigenschaft Wiederholungszähler gesetzt ist, wird eine Warnung in der Problemansicht des Nachrichteneditors angezeigt. Klicken Sie mit der rechten Maustaste auf die Warnung und klicken Sie auf Schnellkorrektur, um das Problem zu beheben.

      Wenn kein Wert für die CWF-Eigenschaft Wiederholungszähler in Version 5.0 definiert ist und Mindestanzahl ungleich Maximale Anzahl ist, wird von einer Wiederholung ausgegangen. In Version 6.0 entspricht die Anzahl der Wiederholungen dem Wert für Maximale Anzahl. Für diese Situation kann keine Warnung generiert werden. Ein solches Nachrichtenmodell wird nicht von den COBOL- oder C-Importprogrammen erstellt und kann deshalb nur dann vorkommen, wenn Sie ein CWF-Nachrichtenmodell unter Verwendung des Nachrichteneditors der Version 5.0 erstellt haben.

    • In Versionen des physischen TDS-Formats vor Version 6.0 erfolgte die Identifizierung von eingebetteten Nachrichten über den Nachrichtenschlüssel. Das Nachrichtenschlüssel-Verfahren wird nicht weiter unterstützt und durch die Nachrichten-ID abgelöst. Für jede Nachricht, die den TDS-Wert Nachrichtenschlüssel hat, und für jedes Element bzw. Attribut, deren bzw. dessen TDS-Eigenschaft Elementwert interpretieren auf Nachrichtenschlüssel gesetzt ist, wird eine Warnung in der Problemansicht des Nachrichteneditors angezeigt. Klicken Sie mit der rechten Maustaste auf die Warnung und klicken Sie auf Schnellkorrektur, um das Problem zu beheben.

      Der TDS-Nachrichtenschlüssel sollte weiterhin verwendet werden, wenn die Nachrichtengruppe in einem Broker der Version 5.0 bzw. Version 2.1 implementiert wird, da diese Broker das Nachrichten-ID-Verfahren für die Identifikation von eingebetteten Nachrichten nicht unterstützen.

    • Die Eigenschaft Datenmuster des physischen TDS-Formats wird jetzt vom Message Brokers Toolkit ausgewertet, um sicherzustellen, dass es sich um einen gültigen regulären Ausdruck für das XML-Schema handelt. In der Problemansicht des Nachrichteneditors werden Fehler angezeigt. Sie müssen diese Fehler unter Verwendung des Editors manuell korrigieren. Insbesondere treten Fehler bei der Spezifikation des XML-Schemas bezüglich der Verwendung von Escapezeichen für Metazeichen auf, die Gültigkeitsfehler verursachen können. Um die Fehler zu korrigieren, müssen Sie möglicherweise den umgekehrten Schrägstrich (\) als Escapezeichen für das Silbentrennungszeichen (-) oder die geschweiften Klammern ({) und (}) verwenden; z. B. \{ oder \-. Wenn derartige Fehler bei Verwendung einer von IBM bereitgestellten Nachrichtengruppe auftreten, wenden Sie sich an IBM, um eine korrigierte Version der Nachrichtengruppe zu erhalten.
    • Der Standardwert oder feste Wert eines Elements bzw. Attributs und Aufzählungswerte eines einfachen Typs werden jetzt hinsichtlich der Facetten für die Länge, maximale Länge und minimale Länge des einfachen Typs (falls vorhanden) überprüft. Wenn ein Wert von den Facetten abweicht, wird eine Fehlermeldung in der Problemansicht des Nachrichteneditors angezeigt. Klicken Sie mit der rechten Maustaste auf den Fehler, und klicken Sie auf Schnellkorrektur, falls eine Schnellkorrektur vorhanden ist. Andernfalls müssen Sie das Problem unter Verwendung des Editors manuell korrigieren. Dieser Fehler tritt meistens dann auf, wenn Sie ein COBOL-Copy-Book in Version 5.0 Fixpack 2 oder eine frühere Version des Message Brokers Toolkits importiert haben.
    • Die CWF- und TDS-Eigenschaften Nullwertcodierung und Parameterwert der Nullwertcodierung wurden aus lokalen Attributen, globalen Attributen und Attributverweisen entfernt. Im XML-Schema können nur Elemente die Eigenschaft Nullwerte möglich haben. Daher kann ein Nullwert nicht für ein als Attribut modelliertes Datenfeld verwendet werden. Wenn Sie für Attribute in Version 5.0 die CWF- bzw. TDS-Werte Nullwertcodierung angegeben haben, wurden diese ignoriert.
    • Die TDS-Eigenschaft Begrenzer für Wiederholelemente wurde aus lokalen Attributen und Attributverweisen entfernt. Im XML-Schema können Attribute nicht wiederholt vorkommen. Wenn Sie für Attribute in Version 5.0 die TDS-Werte Begrenzer für Wiederholelemente angegeben haben, wurden diese ignoriert.
    • Für ein Element oder Attribut mit dem einfachen Typ "xsd:gMonth" ist jetzt "--MM" der Standardwert für die CWF-, XML- und TDS-Eigenschaft Datum/Zeit-Format. In Version 5.0 lautet der Standardwert "--MM--". Dieser Wert wurde korrigiert, um die Kompatibilität mit XML-Schema-Errata sicherzustellen.
    • Wenn Sie eine Migration durchführen, müssen Sie Ihre Nachrichtengruppe nicht erneut implementieren, da Nachrichtenverzeichnisse in der Brokerdatenbank mit dem Befehl mqsimigratecomponents auf das Format von Version 6.0 aktualisiert werden. Wenn Sie jedoch eine Nachrichtengruppe nicht erneut implementieren und es bei der ersten Verwendung eines Nachrichtenflusses, der die Nachrichtengruppe verwendet, zu einer Ausnahmebedingung im Parser kommt (z. B. 'Vektorfehler festgestellt' oder 'Zugriffsverletzung'), müssen Sie die Nachrichtengruppe erneut implementieren. Diese Situation kann eintreten, wenn das Nachrichtenverzeichnis ungültige Daten enthält, die vorher nicht festgestellt wurden. In Version 6.0 wird ein Nachrichtenverzeichnis bei seiner ersten Verwendung geprüft; in Version 2.1 undVersion 5.0 geschieht dies nicht.
    Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Feedback

    Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
    Letzte Aktualisierung : 2009-02-17 15:29:20

    ah20250_