Einen Nachrichtenfluss migrieren

Vorbereitungen:

Lesen Sie zunächst den Abschnitt über die Unterschiede zwischen Produkten der Version 2.1 und Version 6.0.

Nachrichtenflüsse, die Sie in Version 2.1 Ihres Produkts erstellt haben (WebSphere MQ Event Broker, WebSphere MQ Integrator Broker oder WebSphere MQ Integrator), können migriert und in WebSphere Message Broker Version 6.0 verwendet werden.

Wenn Sie eine Migration von WebSphere MQ Event Broker Version 2.1 aus durchführen, treffen die Informationen in diesem Abschnitt, die sich auf benutzerdefinierte Plug-ins und ESQL beziehen, nicht zu. Diese Funktionen sind in WebSphere MQ Event Broker Version 2.1 nicht verfügbar.

Wenn Sie eine Migration von WebSphere MQ Integrator Broker Version 2.1 aus durchgeführt haben, haben Sie möglicherweise Nachrichtenflüsse für die Verarbeitung von XML-Nachrichten geschrieben, die XML-Namespaces verwenden. In Version 2.1 werden solche XML-Nachrichten anders als in WebSphere Message Broker Version 6.0 analysiert. Obwohl solche Nachrichtenflüsse auch in Version 6.0 korrekt ausgeführt werden, sollten Sie sie für die Verarbeitung von Namespaces aktualisieren.

Sie können die Nachrichtenflüsse, die Sie migrieren, ändern, um die neuen Knoten und Funktionen in Version 6.0 zu nutzen. Beispiel: Sie möchten einen benutzerdefinierten Knoten ersetzen, der Web-Serviceanforderungen beim integrierten HTTPEmpfangsknoten erhält.

Es kann mehr als ein Nachrichtenfluss auf einmal migriert werden, wenn sie im gleichen Nachrichtenflussprojekt definiert werden sollen. Sie müssen untergeordnete Flüsse und benutzerdefinierte Knoten mit den Nachrichtenflüssen migrieren, in denen sie enthalten sind, um konsistente Verweise sicherzustellen.

Wenn mehrere Nachrichtenflüsse mit demselben Namen definiert wurden oder ein Nachrichtenfluss in mehrere Exportdateien exportiert wurde, überschreibt die Migrationstask ohne Vorwarnung jeden vorhandenen Nachrichtenfluss mit dem nächsten Fluss des gleichen Namens. Seien Sie deshalb vorsichtig, um solche Konflikte zu vermeiden. Stellen Sie sicher, dass die aktuellste Version eines mehrmals definierten Nachrichtenflusses als letzte Version migriert wird.

Wenn mehrere Versionen desselben Nachrichtenflusses vorliegen, den Sie als untergeordneten Fluss in anderen Flüssen desselben Migrationsverzeichnisses verwenden, sind die Folgen des Importvorgangs unvorhersehbar.

So migrieren Sie einen Nachrichtenfluss:

  1. Bevor Sie Version 2.1 deinstallieren, exportieren Sie den Nachrichtenfluss (oder die Nachrichtenflüsse) mithilfe der Version 2.1-Tools aus der Steuerzentrale (Einzelheiten dazu finden Sie in der Dokumentation von Version 2.1).

    Der Migrationsprozess ist am effektivsten, wenn alle referenzierten untergeordneten Flüsse in der gleichen Exportdatei enthalten sind. Exportieren Sie deshalb alle zu migrierenden Nachrichtenflüsse, die Sie in ein einzelnes Nachrichtenflussprojekt migrieren möchten, in eine einzelne Exportdatei.

  2. Übertragen Sie die Exportdatei(en) an das neue System, auf dem Sie die Workbench ausführen.
    • Prüfen Sie, ob das Verzeichnis, in dem Sie diese Dateien speichern, keine weiteren Dateien enthält.
    • Speichern Sie die Dateien, die Sie in einem einzelnen Nachrichtenflussprojekt importieren möchten, in einem separaten Verzeichnis, und migrieren Sie jedes Verzeichnis einzeln.
    • Stellen Sie sicher, dass Sie keine Dateien in Unterverzeichnisse des Projektverzeichnisses speichern, da diese Dateien vom Migrationsbefehl ignoriert werden.
  3. Wenn eine Workbench-Sitzung aktiv ist, muss diese geschlossen werden. Der Migrationsbefehl kann nicht ausgeführt werden, wenn die Workbench läuft.
  4. Rufen Sie bei einer Eingabeaufforderung den Befehl mqsimigratemsgflows auf, und geben Sie den neuen Projektnamen und das Verzeichnis an, in dem Sie die Exportdateien gespeichert haben. Nach Abschluss des Befehls:
    • Die Nachrichtenflüsse aus den Exportdateien des angegebenen Verzeichnisses wurden in das angegebene Nachrichtenflussprojekt importiert. Falls das Projekt bereits vorhanden war, werden die zusätzlichen Nachrichtenflüsse mit dem aktuellen Inhalt (falls vorhanden) eingeschlossen. Falls das Projekt vor Aufrufen des Befehls nicht vorhanden war, wird es für Sie erstellt. Der Befehl arbeitet am effektivsten, wenn er das Nachrichtenflussprojekt für Sie erstellen kann.
    • Es werden Nachrichtenflüsse und untergeordnete Flüsse erstellt und ihre Definitionen in Dateien mit dem Namen Flussname.msgflow gespeichert. Es werden benutzerdefinierte Knoten erstellt und ihre Definitionen in Dateien mit dem Namen Knotenname.msgnode gespeichert.

      Wenn Sie Nachrichtenflüsse oder Knoten nach ihrem Import umbenennen möchten, damit sie ihren lokalen Namenskonventionen entsprechen, müssen Sie die Funktionen der Workbench verwenden, um die Konsistenz und Integrität aller Verweise sicherzustellen. Benennen Sie keine Dateien innerhalb des Dateisystems um.

    • Falls einer der Knoten in den Nachrichtenflüssen ESQL enthielt, wird der Code vom Knoten selbst extrahiert und in der ESQL-Datei Nachrichtenflussname.esql gespeichert. Das ESQL für jeden Knoten wurde zwischen den entsprechenden CREATE- und END MODULE-Anweisungen (für Rechen-, Datenbank- oder Filterknoten) verwendet. Die ESQL-Datei wird durch den Befehl erzeugt, falls sie noch nicht vorhanden ist.

      Wenn Sie einen Nachrichtenfluss einer BAR-Datei hinzufügen, wird Laufzeit-ESQL-Code auf Versionsstufe 6.0 generiert. Dieser Code ist nicht mit Version 2.1-Brokern kompatibel. Wenn die BAR-Datei Laufzeit-ESQL von Version 2.1 enthalten soll, müssen Sie das Kontrollkästchen ESQL für Brokerversion 2.1 kompilieren aktivieren. In diesem Fall können Sie keine Erweiterungen von Version 6.0 in den ESQL-Code einschließen, aber die Flüsse in Broker von Version 2.1 und Version 6.0 implementieren.

      Der Abschnitt Dateien zu einem Brokerarchiv hinzufügen enthält weitere Informationen hierzu.

  5. Überprüfen Sie die Berichtsdatei mqsimigratemsgflows.report.txt, die in das Verzeichnis geschrieben wird, aus dem Sie den Befehl aufgerufen haben. Der Befehl stellt die folgenden Informationen bereit:
    • Der Name jedes Nachrichtenflusses, untergeordneten Nachrichtenflusses und benutzerdefinierten Knotens, der migriert wurde. Falls eine dieser Ressourcen einen Namen hatte, der nicht mit Version 6.0 kompatibel ist, aktualisiert der Befehl den Namen und alle Verweise auf ihn, um Konsistenz zu gewährleisten. (Wenn Sie eine Ressource mit einem ungültigen Namen mehr als einmal migrieren, ist die am Namen vorgenommene Korrektur immer die gleiche.)
    • Der Erfolg oder Fehler bei jeder migrierten Ressource.
    • Der Hinweis auf einen untergeordneten Fluss, der nicht gefunden werden kann (seine Definition ist in keiner Exportdatei, aber in einem oder mehreren migrierten Nachrichtenflüssen enthalten). Ist dies der Fall, machen Sie den fehlenden untergeordneten Fluss ausfindig, und importieren Sie ihn in das entsprechende Projekt. Wenn Sie den fehlenden untergeordneten Fluss aus irgendeinem Grund nicht abrufen können, erstellen Sie ihn erneut mit dem ursprünglichen Namen. Alle betroffenen Flüsse können dann zum neuen untergeordneten Fluss eine Verknüpfung erstellen.

      Sie müssen nicht den gesamten Export- und Importprozess wiederholen.

    • Ein Hinweis darauf, dass eine Ressource, die als Nachrichtenfluss migriert und in einer .msgflow-Datei gespeichert wurde, ein benutzerdefinierter Knoten sein könnte. Falls diese Warnung ausgegeben wird, müssen Sie prüfen, ob die angegebene Ressource ein benutzerdefinierter Knoten oder ein Nachrichtenfluss ist. Handelt es sich um einen Nachrichtenfluss, war die Migration korrekt. Falls es sich um einen benutzerdefinierten Knoten handelt, müssen Sie die Aktionen ausführen, die in Schritt 11 beschrieben werden.
  6. Starten Sie die Workbench, und wechseln sie zur Ansicht 'Brokeranwendungsentwicklung'.
  7. Öffnen Sie das durch den Migrationsbefehl erstellte oder aktualisierte Nachrichtenflussprojekt.

    Falls das Projekt bereits geöffnet ist, klicken Sie mit der rechten Maustaste, und wählen Sie Aktualisieren und anschließend Projekt erneut erstellen aus, um sicherzustellen, dass die Brokerentwicklungsansicht den neuen Inhalt zeigt. Bei der erneuten Erstellung wird auch eine Prüfung der Inhalte des Nachrichtenflussprojekts durchgeführt.

    Da ESQL-Code und Zuordnungen in Version 6.0 auf andere Weise gehandhabt werden, ersetzt der Migrationsprozess einige der Version 2.1-Knoten durch andere Version 6.0-Knoten. In der folgenden Tabelle werden die ersetzten Knoten aufgeführt. Das mit jedem Knoten assoziierte ESQL wird als Modul mit einem Standardnamen erstellt und die Knoteneigenschaft auf den Namen dieses Moduls gesetzt.

    Version 2.1-Knoten Version 6.0-Knoten
    Rechenknoten Rechenknoten
    Filterknoten Filterknoten
    Datenbankknoten Datenbankknoten
    Datenlöschknoten Datenbankknoten
    Dateneinfügeknoten Datenbankknoten
    Datenaktualisierungsknoten Datenbankknoten
    Extraktionsknoten Rechenknoten
    Warehouseknoten Datenbankknoten
  8. Wenn ein Nachrichtenfluss einen oder mehrere Filterknoten enthält, prüfen Sie das ESQL-Modul für jeden Knoten in der ESQL-Datei, um sicherzustellen, dass die Rückkehranweisung (RETURN) einen gültigen Ausdruck zurückgibt, der einen Booleschen Wert ergibt.
  9. Wenn ein Nachrichtenfluss einen Knoten mit ESQL enthält und ESQL-Felder in einer Nachricht referenziert, die von einem importierten C-Header abgeleitet wurde, und Sie das Nachrichtenmodell neu erstellt haben, indem Sie den C-Header in die Workbench importiert haben, prüfen Sie die ESQL-Anweisungen, die auf diese Nachricht verweisen. Der Importvorgang in die Workbench der Version 6.0 kann ein Modell mit anderen Namenskonventionen erzeugen als das vom Importer der Version 2.1; Sie müssen unter Umständen eine oder mehrere Feldverweise aktualisieren.
  10. Falls Sie die ESQL-Eigenschaft von einem der Version 2.1-Knoten, die ESQL-Anpassungen enthielten, weitergegeben haben, um ESQL-Code in mehreren Knoten wiederzuverwenden, wird die Weitergabe in den migrierten Version 6.0-Nachrichtenflüssen nicht beibehalten, da sie von Eigenschaften, die sich auf ESQL beziehen, nicht mehr unterstützt wird. In der Taskansicht wird für jede weitergegebene ESQL-Eigenschaft ein Fehler angezeigt. Um die gleiche Wirkung zu erzielen, müssen Sie eine ESQL-Funktion erstellen und diese vom ESQL-Modul eines jeden Knotens aufrufen.
  11. Wenn Sie einen benutzerdefinierten Knoten migriert haben, wird nur die XML-Schnittstellendefinitionsdatei in eine Knotendatei, .msgnode, migriert (in dieser Datei werden nur die Terminals und Eigenschaften des Knotens definiert). Schließen Sie die Migration und Definition manuell in Version 6.0 des Produkts ab. Die folgenden Schritte geben einen Überblick zum erforderlichen Prozess. Weitere Informationen finden Sie unter Darstellung der Benutzerschnittstelle eines benutzerdefinierten Knotens in der Workbench erstellen.
    1. Erstellen Sie ein benutzerdefiniertes Knotenprojekt, und verschieben Sie die Datei .msgnode aus dem Nachrichtenflussprojekt in das neue benutzerdefinierte Knotenprojekt. Hierbei werden die zugehörigen Eigenschaftendateien erstellt.
    2. Optional: Schließen Sie die Entwicklung des benutzerdefinierten Knotens in der Eclipse-Umgebung ab, um das Eclipse-Plug-in für den benutzerdefinierten Knoten zu erstellen (die Verzeichnisstruktur mit den Dateien, aus denen dieser Knoten besteht). Diese Task beinhaltet gegebenenfalls die Erstellung der Knotenressourcen für die Hilfefunktion, Symbole sowie die Eigenschafteneditoren und Compiler.
    3. Überprüfen Sie die Taskliste auf Fehler. Fehler können unter Umständen generiert werden, wenn beispielsweise der Knoten oder seine Terminalnamen ein Leerzeichen enthalten (was in Version 6.0 nicht unterstützt wird) oder wenn ein Fluss einen anderen migrierten Fluss einbettet und der Verweis nicht korrekt ist. Beheben Sie diese Fehler, indem Sie die Namen korrigieren oder die Menüoption 'Untergeordneten Fluss suchen' nutzen.
    4. Installieren Sie den Laufzeitcode für den Knoten (die Datei .lil) auf den entsprechenden Brokersystemen. Sie müssen den Code für Ihren benutzerdefinierten Knoten nicht erneut kompilieren, wenn Sie ihn migrieren.
    5. Stoppen Sie den Broker, und starten Sie ihn erneut, damit die neuen oder geänderten Dateien erkannt werden.
Lesen Sie nach der Migration Ihrer Ressourcen den Abschnitt Tasks nach der Migration in Version 2.1. Hier finden Sie Informationen zu den Tasks, die im Anschluss an eine Migration gegebenenfalls auszuführen sind.
Zugehörige Konzepte
Nachrichtenflüsse - Übersicht
ESQL-Funktionen
Zugehörige Tasks
Nachrichtenflüsse für die Verarbeitung von Namespaces aktivieren
Vorhandene Nachrichtenflüsse öffnen
Nachrichtenflussinhalte definieren
ESQL erstellen
Zugehörige Verweise
Ansicht 'Brokeranwendungsentwicklung'
ESQL-Editor
Integrierte Knoten
Befehl 'mqsimigratemsgflows'
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Letzte Aktualisierung : 2009-02-17 15:28:07

ac02355_