Nachrichtengruppen von Version 2.1 migrieren

Verwenden Sie zur Migration von Version 2.1 nach Version 6.0 den Befehl mqsimigratemsgsets. Beim Migrieren von Version 5.0 nach Version 6.0 muss dieser Befehl nicht verwendet werden.

Bedingungen zur Verwendung des Befehls mqsimigratemsgsets

Ändern Sie die Nachrichtengruppendatei zwischen dem Exportieren aus Version 2.1 und dem Importieren in WebSphere Message Broker Version 6.0 nicht, da dies Fehler verursachen würde, die durch folgende Warnungen und Fehlernachrichten im Bericht angezeigt werden: BIP0141, BIP0142 bis BIP0157 und BIP0163.

Bei jeder neuen Nachrichtendefinitionsdatei (Erweiterung .mxsd) handelt es sich um ein mit Anmerkungen versehenes XML-Schemamodell. Jedes Artefakt in der Nachrichtengruppe wird reproduziert und behält seine bestehenden Eigenschaften in dem neuen Modell bei, mit folgenden Ausnahmen:
  • Der Name in Modell von WebSphere Message Broker Version 6.0 ist die ID aus dem Modell von Version 2.1. Falls das Objekt ein Element mit einer ID als Präfix ist, wird das Präfix entfernt, denn es diente in Version 2.1 dazu, anzuzeigen, dass es sich bei diesem Element eigentlich um ein lokales Element handelte.
  • Kennung, Kurzbeschreibung, Ausführliche Beschreibung und Protokoll werden zu einer einzigen Eigenschaft (Dokumentation) für WebSphere Message Broker Version 6.0 zusammengefasst.
  • Aus jedem Verbundtyp wird in WebSphere Message Broker Version 6.0 ein 'xsd:complexType' mit einer zugeordneten 'xsd:group'.
    Der auf diese Weise erstellte xsd:complexType kann lokal oder global sein. Standardmäßig ist er lokal, wird aber in global geändert, wenn eine der folgenden Bedingungen zutrifft:
    • Der Verbundtyp wird nicht referenziert.
    • Der Verbundtyp hat einen MRM-Basistyp der Version 2.1.
    • Der Verbundtyp wird von mehreren Elementen referenziert.
    • Eine Nachricht basiert auf dem Verbundtyp.
    • Der Parameter -g ist angegeben.
    Die auf diese Weise erstellte xsd:group kann lokal oder global sein. Standardmäßig ist sie lokal, wird aber in global geändert, wenn eine der folgenden Bedingungen zutrifft:
    • Der Verbundtyp ist direkt in einen anderen Verbundtyp eingebettet.
    • Der Verbundtyp hat einen MRM-Basistyp der Version 2.1.
    • Der Verbundtyp hat die Version 2.1-Typzusammensetzung Einfache Elemente in beliebiger Reihenfolge und den Version 2.1-Typinhalt Geschlossen.
    Beachten Sie, dass die Typzusammensetzung Einfache Elemente in beliebiger Reihenfolge in WebSphere Message Broker Version 6.0 aus dem Modell entfernt wird.
    • Lautet der Typinhalt Geschlossen, wird er durch die Typzusammensetzung Alle ersetzt, wobei die Warnung BIP0191 ausgegeben wird.
    • Andernfalls wird sie durch die Typzusammensetzung Elemente in beliebiger Reihenfolge ersetzt, wobei die Warnung BIP0192 ausgegeben wird.
    • Die Typzusammensetzung Leer wird durch eine leere Typzusammensetzung Reihenfolge ersetzt, wobei die Warnung BIP0193 ausgegeben wird.

  • In eingebetteten Nachrichten mit Mindestanzahl oder Maximale Anzahl ungleich 1 wird die Anzahl in 1 korrigiert, wobei die Warnung BIP0162 ausgegeben wird.
  • Aus jedem Element wird ein xsd:element. Das auf diese Weise erstellte xsd:element kann lokal oder global sein, abhängig von den folgenden Bedingungen, die in der angegebenen Reihenfolge angewendet werden:
    1. Wenn das Element nicht referenziert wird, ist es global.
    2. Wenn das Element eine ID als Präfix hat und Mitglied genau eines Verbundtyps ist, ist es lokal.
    3. Wenn das Element eine ID als Präfix hat und der Parameter -pl angegeben ist, ist es lokal.
    4. Wenn das Element ein Verbundtyp mit einem MRM-Basistyp der Version 2.1 ist, ist es lokal.
    5. Wenn das Element Mitglied mehrerer Verbundtypen ist, ist es global.
    6. Wenn der Parameter -g angegeben ist, ist es global.
    7. In allen anderen Fällen ist das Element lokal.
    Der Typ des auf diese Weise erstellten xsd:element kann folgender sein:
  • Alle Wertvorgaben, die zum Element gehören, werden wie folgt verarbeitet:
    • Eine Standardvorgabe setzt das Attribut 'default' (Standardwert) des xsd:element.
    • Eine Vorgabe 'Null Permitted' (Null zulässig) setzt das Attribut 'nillable' (Nullwerte möglich) des xsd:element.
    • Eine Vorgabe 'Date Template' (Datumsvorlage) ändert den xsd:simpleType des xsd:element. (Siehe Zuordnung zwischen einfachen MRM-Typen und einfachen Schema-Typen.)
    • Alle anderen beschränken den xsd:simpleType des xsd:element durch die Anwendung von xsd:facet-Typen.

    Alle nicht referenzierten Wertvorgaben werden gelöscht, wobei die Warnung BIP0158, BIP0159 oder BIP0160 ausgegeben wird.

    Alle Wertvorgaben, die dazu führen, dass ein unzulässiger xsd:facet-Typ erstellt wird, werden nicht migriert, es wird jedoch die Warnung BIP0165 ausgegeben.
    Anmerkung: Nur für Elemente des Typs STRING gilt, dass stattdessen zu Dokumentationszwecken die Wertvorgaben Eingeschlossener Minimalwert und Eingeschlossener Maximalwert als verdeckte Anmerkungen importiert werden, da kein entsprechender xsd:facet-Typ existiert.
  • Elementqualifizierungsmerkmale werden gelöscht, wobei einmalig die Warnung BIP0167 ausgegeben wird.
  • Aus jeder Nachricht wird eine Nachricht und ein zugeordnetes globales xsd:element.
  • In Nachrichten, die Elementqualifikationsmerkmale verwenden, werden die Qualifikationsmerkmale gelöscht, wobei die Warnung BIP0166 ausgegeben wird.
  • Einige Eigenschaften des physischen Formats, die in Version 2.1 redundant waren, wurden aus dem neuen Modell entfernt. Wenn eine dieser Eigenschaften mit einem anderen Wert als dem Standardwert gefunden wird, wird die Warnung BIP0164 (oder eine spezifischere Warnung) ausgegeben.
  • Die Eigenschaft Jahrhundertfenster für die TDS-Nachrichtengruppenstufe wurde in Version 2.1 immer auf den Standardwert '53' gesetzt. Dies ist für den Nachrichtenstandard 'SWIFT' nicht korrekt. Deshalb wird der Standardwert nur für 'SWIFT' in '80' geändert. Dies spiegelt sich in einem importierten Modell wider.

Was mit dem Befehl mqsimigratemsgsets erstellt wird

Für jede erkannte .mrp-Datei wird ein neues Nachrichtengruppenprojekt mit einem Namen erstellt, der vom Namen und von der Stufe der Nachrichtengruppe in Version 2.1 abgeleitet wird. Das Dienstprogramm fügt dabei dem Namen der Nachrichtengruppe für alle Ebenenwerte, die nicht 1 sind, ein Suffix hinzu. Durch diesen Prozess wird die 1:1-Zuordnung wiederhergestellt, und der Broker ist in der Lage, nur eine Nachrichtengruppe mit dem angegebenen Namen zu lokalisieren.

Beispiel: Eine Nachrichtengruppe der Version 2.1 mit dem Namen 'SWIFT' und Stufe '1' hat nach der Migration in Version 6.0 den Nachrichtengruppennamen 'SWIFT', während eine Nachrichtengruppe der Version 2.1 mit dem Namen 'SWIFT' und Stufe '2' nach der Migration in Version 6.0 den Namen 'SWIFT_2' hat.

Im neuen Projekt wird eine Nachrichtengruppenordner und eine zugehörige messageSet.mset-Datei erstellt. Folgende Aussagen gelten für den Inhalt der Nachrichtengruppe:
  • Der Nachrichtengruppenordner hat denselben Namen wie das neue Projekt.
  • Die Nachrichtengruppe hat dieselbe ID wie die ursprüngliche Version 2.1-Nachrichtengruppe.
  • Die Nachrichtengruppe wird mit der Festlegung erstellt, dass Namespaces nicht unterstützt werden.
  • Alle Ebenen des physischen Formats werden in der neuen Nachrichtengruppe erneut erstellt.
  • Alle COBOL-bezogenen Bindungsebenen werden gelöscht, wobei die Warnung BIP0174 ausgegeben wird.
  • Alle C-bezogenen Bindungsebenen werden gelöscht, wobei die Warnung BIP0173 ausgegeben wird.
  • Alle abgeschlossenen Statusangaben werden gelöscht, wobei die Warnung BIP0170 ausgegeben wird.
  • Alle Basisinformationen werden gelöscht, wobei die Warnung BIP0172 ausgegeben wird.
  • Alle eingefrorenen Zeitmarken werden gelöscht, wobei die Warnung BIP0169 ausgegeben wird. Diese Warnung wird immer ausgegeben, weil die Nachrichtengruppe bei der Exportoperation von Version 2.1 eingefroren wird.
Jede in der mrp-Datei gefundene Nachrichtenkategorie hat zur Folge, dass eine neue category-Datei erstellt wird. Hinweis:
  • Jede Transaktion wird durch die entsprechende Nachrichtenkategorie ersetzt, die alle Nachrichten in allen Transaktionen enthält.
  • Jede Transaktionskategorie wird durch die entsprechende Nachrichtenkategorie ersetzt, die alle Nachrichten in allen Transaktionen, auf die von der Transaktionskategorie verwiesen wird, enthält.

Eine einzelne mxsd-Nachrichtendefinitionsdatei mit demselben Namen wie die Nachrichtengruppe wird in der Nachrichtengruppe und im Standardnamespace (notarget) erstellt, außer wenn der Parameter -part angegeben ist.

Wenn -part angegeben ist, können mehrere mxsd-Dateien erstellt werden, falls Folgendes zutrifft:
  • Die Anzahl der Nachrichten, Elemente und Verbundtypen in der Datei beträgt mehr als 1000, und
  • die mrp-Datei kann in vollständig getrennte Untermengen aufgeteilt werden.

In Version 2.1 sind alle Elemente und Verbundtypen global. In Version 6.0 können die Typen xsd:elements und xsd:complex types global oder lokal sein. Beim Migrieren einer Version 2.1-Nachrichtengruppe stellen Sie möglicherweise fest, dass viele Elemente und Verbundtypen, die in Version 2.1 global waren, in Version 6.0 gemäß den oben genannten Regeln in lokale Typen xsd:elements und xsd:complex types konvertiert wurden.

Es gibt zwei Gründe, dieses Verhalten außer Kraft zu setzen:
  • Sie bevorzugen die aus Version 2.1 bekannte Organisation der Nachrichtengruppen, bei der alle Objekte global sind. Wenn Sie den Parameter -g angeben, wird diese Organisation so weit wie möglich beibehalten.
  • Sie können den Verbundtyp Typinhalt mit dem Wert Offen/definiert verwenden.

Das heißt, dass der gültige Inhalt eines Verbundtyps ein beliebiges Objekt in der Nachrichtengruppe sein kann, sofern die Regeln für die Eigenschaft Typzusammensetzung dies zulassen. In diesem Fall wurde der Verbundtyp in der Regel nicht mit einem expliziten Inhalt modelliert.

Dies kann dazu führen, dass der Befehl mqsimigratemsgsets fälschlicherweise aus bestimmten Elementen nicht globale, sondern lokale Elemente macht. Wenn Sie Offen/definiert verwenden und nach der Migration zur Laufzeit der Gültigkeitsfehler BIP5372E auftritt (was vorher nicht der Fall war), führen Sie den Befehl mqsimigratemsgsets erneut mit dem Parameter -g aus.

IDs mit Präfix

In Version 2.1 zeigte eine ID mit einem Präfix an, dass es sich bei einem Element um ein lokales Element handelte. Es ist jedoch möglich, dass ein Element mit einer ID mit Präfix tatsächlich in mehreren Verbundtypen verwendet wird und dadurch zu einem globalen Element wird. Wenn dies der Fall ist, wird ein globales xsd:element gemäß den oben genannten Regeln erstellt. Außerdem wird die Warnung BIP0195 ausgegeben, weil es sich um eine missbräuchliche Verwendung von IDs mit Präfix handelt, die dazu führen kann, dass doppelte globale xsd:elements-Elemente erstellt werden. Beispiel: Es gibt die Elemente A^X und B^X, die aber beide mehrfach verwendet werden, mit dem Ergebnis, dass zwei xsd:element-Elemente mit dem Namen X erstellt werden.

Falls doppelte Elemente erstellt werden, können Sie den Befehl mqsimigratemsgsets erneut ausführen, diesmal mit dem Parameter -pl. Dieser sorgt dafür, dass alle referenzierten Elemente mit IDs mit Präfix als lokale xsd:element-Elemente erstellt werden.

Eingebetteter einfacher Typ

Eingebettete einfache Typen in Verbundtypen erfordern eine spezielle Behandlung, weil das Schemamodell mit diesem Konstrukt nicht umgehen kann. Da eingebettete einfache Typen nicht weiter unterstützt werden, sollten Sie sie durch das Attribut 'Gemischt' des enthaltenden Typs xsd:complex ersetzen.

Eingebettete einfache Typen wurden in erster Linie zu dem Zweck eingeführt, ein komplexes XML-Element zu modellieren, das Datenwerte enthielt, die zwischen untergeordneten Elementen eingestreut wurden. Jeder dieser Datenwerte wurde explizit durch einen eingebetteten einfachen Typ modelliert, der als Platzhalter für den Wert fungierte und auch den einfachen Typ lieferte.

Im XML-Schema gibt es dazu kein Äquivalent. Am besten geeignet ist das Attribut 'Gemischt' des Typs xsd:complexType. Dieses Attribut legt jedoch nur fest, dass Text vor oder zwischen untergeordneten Elementen stehen kann. Es sagt nichts über die Position oder den Datentyp des Textes aus.

Um diese Semantik beizubehalten, wird eine Schemaerweiterung eingeführt, die als 'Embedded Simple Type' (Eingebetteter einfacher Typ) bezeichnet wird. Dabei handelt es sich um ein nicht benanntes lokales xsd:element des entsprechenden einfachen Typs. Der Typ selbst stellt eine Einschränkung des tatsächlich zu Grunde liegenden Typs xsd:simpleType dar, aber mit einem speziellen Namen (beginnend mit ComIbmMrm_Anon).

Verbundtyp mit einem MRM-Basistyp

Diese Situation führt dazu, dass die Warnung BIP0161 ausgegeben wird, und erfordert eine spezielle Behandlung, weil das Schemamodell mit diesem 'Verbund'-Konstrukt nicht umgehen kann. Da Verbundelemente nicht weiter unterstützt werden, wird dringend empfohlen, stattdessen normale Elemente zu verwenden, die auf den globalen xsd:complexType (siehe Beschreibung unter 1 unten) verweisen und das Attribut 'mixed' nutzen.

Solche Verbundtypen wurden in erster Linie zu dem Zweck eingeführt, ein komplexes XML-Element zu modellieren, das sowohl einen Datenwert als auch untergeordnete Elemente enthielt. Das heißt, ein Element dieses komplexen Typs enthält nicht nur komplexen Inhalt wie ein normales komplexes Element, sondern auch einen Wert wie ein einfaches Element (die MRM-Basistypinformation).

Im XML-Schema gibt es dazu kein Äquivalent. Am besten geeignet ist das Attribut 'mixed' des xsd:complexType. Dieses Attribut legt jedoch nur fest, dass Text vor und zwischen (oder nur zwischen) untergeordneten Elementen stehen kann. Es sagt nichts über die Position oder den Datentyp des Textes aus.

Da es im XML-Schema kein funktional entsprechendes Äquivalent gibt, wurde Folgendes getan:
  1. Ein globaler Typ xsd:complexType und ein globaler Typ xsd:group werden auf die übliche Weise erstellt. Für xsd:complexType wird zusätzlich das Attribut 'mixed' festgelegt, dessen Inhalt lediglich ein Verweis auf den globalen Typ xsd:group ist. Auf diese Weise wird zwar der komplexe Inhalt modelliert, aber die MRM-Basistypinformation geht verloren.
  2. Es wird eine spezifische Schemaerweiterung eingeführt, das Verbundelement. Dabei handelt es sich um eine Verschmelzung eines komplexen Elements mit einem einfachen Element. Schemakonform ausgedrückt heißt das, es wird als ein Element mit einem anonymen komplexen Typ implementiert, das folgenden Inhalt hat:
    • Ein lokales xsd:element des geeigneten einfachen Typs (um die MRM-Basistypinformation zu modellieren). Der einfache Typ stellt eine Einschränkung des tatsächlich zu Grunde liegenden xsd:simpleType dar, aber mit einem speziellen Namen (beginnend mit ComIbmMrm_BaseValue).
    • Ein Gruppenverweis auf den globalen Typ xsd:group, der oben unter 1 erstellt wurde.

Ein Verbundelement wird für jedes Element erstellt, das auf den Verbundtyp verweist. Dies ist jedoch nur dann möglich, wenn das Element selbst Mitglied eines anderen Verbundtyps war.

Die Kombination dieser beiden Dinge bedeutet, dass die aussagefähige Verwendung solcher Verbundtypen innerhalb einer Nachricht erhalten bleibt, da die MRM-Basistypinformation nur verloren geht, wenn sie in einer Nachricht niemals aktiv verwendet wurde.

Die Sonderdatentypen, die in den oben beschriebenen Situationen erstellt werden und mit ComIbmMrm beginnen, sind in einem XML-Schema namens .wmq21.mxsd definiert, das in jeder Nachrichtendefinitionsdatei enthalten ist, die mit dem Befehl mqsimigratemsgsets erstellt wird.

Zuordnung zwischen einfachen MRM-Typen und einfachen Schema-Typen

Zuordnung zwischen einfachen Typen:
MRM-Typ Schema-Typ
BINARY xsd:hexBinary
BOOLEAN xsd:boolean
DECIMAL xsd:decimal
DATETIME xsd:dateTime (siehe folgende Tabelle)
FLOAT xsd:float
INTEGER xsd:int
STRING xsd:string
Beim DATETIME-Typ kann die Zuordnung für einfache Typen durch das Vorhandensein einer Datumsvorlage als Wertvorgabe wie folgt geändert werden:
MRM DATETIME-Datumsvorlage Schema-Typ
CCYY-MM-DDThh:mm:ss.s xsd:dateTime
CCYY-MM-DD xsd:date
CCYY-MM xsd:gYearMonth
CCYY xsd:gYear
--MM-DD xsd:gMonthDay
--MM xsd:gMonth
---DD xsd:gDay
Thh:mm:ss.s xsd:time

Wenn die Datumsvorlage in dieser Liste nicht enthalten ist, wird DATETIME entweder einem Typ xsd:time oder einem Typ xsd:dateTime zugeordnet, wobei die Warnung BIP0175 ausgegeben wird, abhängig davon, ob die Datumsvorlage nur eine Uhrzeitkomponente hatte oder nicht. Beachten Sie jedoch, dass diese Zuordnung Fehler verursachen kann, die nach dem Import in der Taskliste erscheinen.

Wenn dem Element auch Vorgaben zu Version 2.1 für Standardwert, Eingeschlossener Mindestwert, Eingeschlossener Maximalwert oder Aufzählung zugeordnet wurden, entsprechen diese Werte nicht dem lexikalischen Speicherbereich für xsd:time bzw. xsd:dateTime. Daher schlägt die Validierung fehl. Dies muss im Editor manuell korrigiert werden.

Derselbe Fehler in der Taskliste wird auch für jeden DATETIME-Typ der Version 2.1 angezeigt, der eine Wertvorgabe für Standardwert, Eingeschlossener Mindestwert, Eingeschlossener Maximalwert oder Aufzählung lieferte, bei dem der Wert nicht vollständig spezifiziert war. Beispielsweise war die Datumsvorlage 'CCYY-MM', Aufzählung '2003' in Version 2.1 zulässig, da es zur Laufzeit als '2003-01' interpretiert wurde. Im neuen Modell muss der Wert jedoch mit dem lexikalischen Leerzeichen des einfachen Typs übereinstimmen, d. h., er muss die Angabe '-01' enthalten.

Zugehörige Verweise
Befehl 'mqsimigratemsgsets'
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Rückmeldung
Copyright IBM Corporation 1999, 2006 Letzte Aktualisierung: 23. Aug. 2006
ad15750_