Einen Nachrichtenfluss migrieren

Bevor Sie beginnen, müssen Sie folgende Task(s) ausgeführt haben:

Das Konzeptthema Bedingungen für einen Broker der Version 5.0, der Teil einer Brokerdomäne der Version 6.0 ist lesen

Nachrichtenflüsse, die Sie in Ihrem Produkt der Version 2.1 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 alle Informationen in diesem Thema, 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-Namensbereiche verwenden. In Version 2.1 werden solche XML-Nachrichten anders als in WebSphere Message Broker Version 6.0 syntaktisch analysiert. Diese Nachrichtenflüsse werden weiterhin korrekt verarbeitet, wenn sie von Version 6.0 betrieben werden; es wird jedoch empfohlen, sie gemäß den Anweisungen unter Nachrichtenflüsse für die Verarbeitung von Namespaces aktivieren dahingehend zu aktualisieren, dass sie Namensbereiche beachten.

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.

Weitere Informationen zu Änderungen in diesem Release finden Sie unter Neuerungen in Version 6.0.

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 Sie mehrere Nachrichtenflüsse mit dem gleichen Namen definiert haben oder ein Nachrichtenfluss in mehr als eine Exportdatei exportiert wurde, überschreibt die Migrationstask ohne Vorwarnung jeglichen vorhandenen Nachrichtenfluss mit dem nächsten Fluss des gleichen Namens, den sie findet. Aus diesem Grund müssen Sie vorsichtig sein, um Konflikte zu vermeiden und um sicherzustellen, dass die aktuellste Version eines mehrfach definierten Nachrichtenflusses als letzte Version migriert wird.

Wenn mehrere Versionen des gleichen Nachrichtenflusses vorliegen und Sie diesen als untergeordneten Fluss in anderen Flüssen des gleichen Migrationsverzeichnisses verwenden, sind die Folgen des Imports unvorhersehbar.

So migrieren Sie einen Nachrichtenfluss:

  1. Bevor Sie Version 2.1 deinstallieren, exportieren Sie den Nachrichtenfluss (oder die Nachrichtenflüsse) mit Hilfe der Tools von Version 2.1 (zu Einzelheiten siehe die Dokumentation zu Version 2.1) von der Steuerzentrale.

    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. Es wird empfohlen, dem Befehl zu erlauben, das Nachrichtenflussprojekt für Sie zu erstellen.
    • 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 nach dem Import Nachrichtenflüsse oder Knoten 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, wurde dies 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.

      Beginn der ÄnderungWenn 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.0 enthalten soll, müssen Sie das Kontrollkästchen Compile ESQL for brokers version 2.1 (ESQL für Broker der Version 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. Ende der Änderung

      Weitere Informationen finden Sie unter Einem Brokerarchiv Dateien hinzufügen.

  5. Überprüfen Sie die Berichtsdatei mqsimigratemsgflows.report.txt, die in das Verzeichnis geschrieben wird, von dem Sie den Befehl aufgerufen haben. Der Befehl stellt die folgenden Informationen bereit:
    • Der Name von jedem Nachrichtenfluss, untergeordneten Fluss und benutzerdefinierten Knoten, 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, indem Sie mit der rechten Maustaste auf das Projekt klicken und die Option Open Project (Projekt öffnen) auswählen.

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

    Da ESQL 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 nachfolgenden 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
    Compute Compute
    Filter Filter
    Datenbankknoten Database
    DataDelete Database
    DataInsert Database
    DataUpdate Database
    Extract Compute
    Warehouse Database
  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 Import in die Version 6.0 Workbench kann ein Modell mit anderen Namenskonventionen erzeugen als das vom Importer von Version 2.1; Sie müssen unter Umständen einen oder mehrere Feldverweise aktualisieren.
  10. Falls Sie die ESQL-Eigenschaft von einem der Version 2.1-Knoten übergeben haben, die ESQL-Anpassungen enthielten, um ESQL in mehreren Knoten wieder zu verwenden, wird dies nicht in den migrierten Version 6.0-Nachrichtenflüssen beibehalten, da die Übergabe von Eigenschaften, die mit ESQL zusammenhängen, 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 Definitionsdatei für die XML-Schnittstelle in eine Knotendatei des Typs .msgnode migriert (diese definiert lediglich die Terminals und Eigenschaften des Knotens). Schließen Sie die Migration und Definition manuell in Version 6.0 des Produkts ab. Die folgenden Schritte zeigen einen Umriss 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. Bei diesem Vorgang 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. Diese werden unter Umständen generiert, 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 | Rückmeldung
Copyright IBM Corporation 1999, 2006 Letzte Aktualisierung: 23. Aug. 2006
ac02355_