Migrationshinweise für Nachrichtengruppen

In diesem Abschnitt finden Sie Informationen zur Migration von Nachrichtengruppen auf WebSphere Message Broker Version 6.0. Er enthält folgende Abschnitte:

Wenn Sie das Version 5.1 Message Brokers Toolkit, 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.

Migration von Version 5.0

Um Nachrichtengruppen von Version 5.0 auf Version 6.0 zu migrieren, müssen keine Migrationsbefehle ausgeführt werden. Der Inhalt eines Nachrichtengruppenprojekts der Version 5.0 kann vom Message Brokers Toolkit Version 6.0 gelesen werden und wird automatisch in das Format Version 6.0 konvertiert, wenn es zum ersten Mal modifiziert und gespeichert wird.

Allgemeine Migrationsinformationen

Die folgenden Informationen gelten für die Migration von Version 2.1 oder Version 5.0.
  • 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.
    Anmerkung: 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 ausgegeben werden. Ein solches Nachrichtenmodell wird nicht vom COBOL- bzw. C-Importprogramm erstellt, so dass es nur dann vorkommen kann, 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 Meta-Zeichen auf, die Gültigkeitsfehlers verursachen können. Um die Fehler zu korrigieren, müssen Sie möglicherweise den umgekehrten Schrägstrich ("\") als Escapezeichen für das Silbentrennungszeichen ("-") bzw. die geschweifte Klammer ( "{" und "}") verwenden; z. B. "\{" bzw. "\-". 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 auf die Länge, die maximale Länge und die minimale Länge des einfachen Typs (falls vorhanden) hin geprü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 gelöscht. Im XML-Schema können lediglich 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-/Zeitformat. In Version 5.0 lautet der Standardwert "--MM--". Diese Korrektur wurde vorgenommen, 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 Version 6.0 aktualisiert werden. Wenn Sie jedoch eine Nachrichtengruppe nicht erneut implementieren, und es zu einer Ausnahmebedingung im Parser kommt (z. B. "Vektorfehler festgestellt" oder "Zugriffsverletzung"), wenn der Nachrichtenfluss, der die Nachrichtengruppe verwendet, zum ersten Mal ausgeführt wird, müssen Sie die Nachrichtengruppe erneut implementieren. Zu diesem Fehler kann es kommen, 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 und Version 5.0 wird diese Überprüfung nicht durchgeführt.

Änderungen im Verhalten des MRM-Parsers

Die folgenden Informationen gelten für die Migration von Version 2.1 oder Version 5.0:
  • Physisches XML-Format. Version 6.0 berücksichtigt jetzt Attribute des Typs "xsi:type" im XML-Dokument und ändert das Verhalten entsprechend ab. Attribute des Typs "xsi:type" werden nicht mehr als selbstdefinierende Attribute behandelt. Deshalb werden sie in der Nachrichtenbaumstruktur mit dem Namen "type" anstatt "@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. Vor Version 6.0 handelte es sich hierbei um eine exakte Kopie des Bitstroms. In Version 6.0 gehen während des Kopiervorgangs Formatierungsleerzeichen verloren. Beispiel: Die nachfolgende Elementdeklaration aus einem Eingabe-DOCTYPE:
    <!ELEMENT e0 (e1|e2)+ >
    wird in der Ausgabe wie folgt angezeigt:
    <!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 ist, geht der Parser stets davon aus, dass die Länge der Auswahldaten der des längsten untergeordneten Elements in der Gruppe entspricht. Der Parser wird stets diese Anzahl Zeichen lesen und schreiben. Stellen Sie sicher, dass Sie dies in Ihren Nachrichten berücksichtigen. Andernfalls werden die Daten, die der Auswahl folgen, vom Parser als Teil der Auswahl behandelt. In Versionen vor Version 6.0 wurde 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 wurde auf NullPadFill stets reagiert, egal ob die Eigenschaft Länge aktiv verwendet wurde 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. Dies bedeutet, dass im Nachrichtenbitstrom ein Begrenzer zwischen dem komplexen Element und allen darauf folgenden Elementen erwartet wird. Darüber hinaus wird ein Begrenzer für Wiederholemente 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 wurde diese Regel vom Parser nicht umgesetzt, und der Writer hat für Elemente variabler Länge mit Begrenzer keine Begrenzer ausgegeben, 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 diese als Element mit einem Wert mit Null-Länge behandelt. In Versionen vor Version 6.0 wurden Ü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. In Versionen vor Version 6.0 wurde diese Regel vom Parser nicht umgesetzt. Wenn dies ein Problem darstellt, können Sie den externen Begrenzer beispielsweise unter Verwendung der TDS-Eigenschaft Gruppenbegrenzer modellieren.
  • 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 hierfür ist die Darstellung von selbstdefinierenden Elementen in der Nachrichtenbaumstruktur, die dadurch verursacht wurde, dass der Abgleich eines Elements mit dem Modell fehlgeschlagen ist.

    Ein spezielles Beispiel hierfür 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 versuchte der Parser eine angemessene Deutung nicht sortierter Gruppen Mit Kennung/Begrenzer, was zu Leistungseinbußen führte. Wenn dies 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 Situationen, 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 erzielen. In Versionen vor Version 6.0 wurde die codierte Länge als Anzahl der Bytes in den Daten ausgegeben, was zu Abweichungen von der Interpretation bei der syntaktischen Analyse führte, wenn andere Daten als SBCS-Daten verarbeitet wurden.
  • Physisches TDS-Format. Wenn beim Schreiben 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 Ausgabe. In Versionen vor Version 6.0 werden diese zusätzlichen Vorkommen in der Ausgabe angezeigt. Wenn die zusätzlichen Vorkommen in der Ausgabe angezeigt werden sollen, legen Sie maxOccurs=-1 fest, um damit anzuzeigen, dass die Häufigkeit unbestimmt ist.
  • Alle physischen Formate. Beim Schreiben von Datums-/Zeitfeldern (dateTime) mit der Formateigenschaft I richtet sich das Ausgabeformat nach dem logischen Typ des Feldes (siehe Erläuterung unter Datum/Uhrzeit als Zeichenfolgedaten). In Versionen vor Version 6.0 war 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 daher keine Nachricht als ungültig gekennzeichnet werden, wenn sie fälschlicherweise in früheren Versionen nicht gekennzeichnet wurde.
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2006 Letzte Aktualisierung: 23. Aug. 2006
ah20250_