Einen Nachrichtenfluss migrieren

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 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 aus WebSphere MQ Integrator Broker Version 2.1 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 wird die Syntaxanalyse für XML-Nachrichten auf einer andere Weise wie bei WebSphere Message Broker durchgeführt. Diese Nachrichtenflüsse werden weiterhin korrekt verarbeitet, wenn Sie von WebSphere Message Broker betrieben werden; es wird jedoch empfohlen, sie für die Verarbeitung von Namespaces zu aktualisieren, indem Sie den Anweisungen unter Nachrichtenflüsse für die Verarbeitung von Namensbereichen aktivieren folgen.

Sie können die Nachrichtenflüsse ändern, die Sie migrieren, um die neuen Knoten und verfügbaren Funktion 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 die Version 2.1 deinstallieren, exportieren Sie den Nachrichtenfluss (oder die Nachrichtenflüsse) mit Hilfe der Tools von Version 2.1 (s. Bibliothek von Version 2.1 für weitere Details) 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. Falls eine Workbench-Sitzung aktiv ist, müssen Sie sie schließen. 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 in den Exportdateien des angegebenen Verzeichnisses befindlichen Nachrichtenflüsse 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 wurden Nachrichtenflüsse und untergeordnete Flüsse erstellt und ihre Definitionen in Dateien mit dem Namen <Flussname>.msgflow gespeichert. Es wurden 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.

      Prüfen Sie die ESQL-Standardkompatibilitätsstufe in der Eigenschaftenseite des ESQL-Editors. Der Standardwert für diese Option ist 6.0, was dazu führt, dass Laufzeit-ESQL-Code auf Stufe 6.0 generiert wird, wenn Sie einer BAR-Datei einen Nachrichtenfluss hinzufügen. 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 die Editorvorgabe zurücksetzen. 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.

      Weitere Informationen finden Sie unter ESQL-Editor.

  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 lokalisiert werden kann (seine Definition ist in keiner Exportdatei aber in einem oder mehreren migrierten Nachrichtenflüssen enthalten). Ist dies der Fall, lokalisieren Sie den fehlenden untergeordneten Fluss, und importieren Sie ihn in das entsprechende Projekt, um den Fehler aufzulösen. 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 auftritt, 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. Ist es ein benutzerdefinierter Knoten, müssen Sie die in Schritt 11 beschriebenen Aktionen durchführen.
  6. Starten Sie die Workbench, und wechseln sie zur Ansicht 'Brokeranwendungsentwicklung'.
  7. Öffnen Sie das durch den Migrationsbefehl erstellte oder aktualisierte Nachrichtenflussprojekt (klicken Sie mit der rechten Maustaste auf das Projekt, und wählen Sie Open Project (Projekt öffnen) aus). 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. Die ersetzten Knoten werden in der folgenden Tabelle gezeigt. 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
    Filter Filter
    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 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 eine oder mehrere Feldreferenzen 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. Die Ansicht 'Tasks' zeigt einen Fehler für jede von ESQL übergebene Eigenschaft. 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 (dies definiert nur die Terminals und Eigenschaften des Knotens). Sie müssen die Migration und Definition in dieser Version des Produkts manuell abschließen. 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 .msgnode-Datei vom Nachrichtenflussprojekt in das neue benutzerdefinierte Knotenprojekt. Hierbei werden die zugehörigen Eigenschaftendateien erstellt.
    2. Optional: Führen Sie die Entwicklung des benutzerdefinierten Knotens in der Eclipse-Umgebung durch, um das benutzerdefinierte Knoten-Eclipse-Plug-in (die Verzeichnisstruktur, welche die Dateien enthält, aus denen der Knoten besteht) zu erstellen. Zu dieser Aufgabe zählt das Erstellen von Knotenressourcen für Hilfe, Symbole und Eigenschaftseditoren und -Compiler, falls erforderlich.
    3. Suchen Sie in der Taskliste nach Fehlern. 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. Lösen Sie diese Fehler auf, indem Sie die Namen korrigieren oder die Menüoption Untergeordneten Fluss suchen nutzen.
    4. Installieren Sie den Laufzeitcode für den Knoten (die .lil-Datei) 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, um die neuen oder geänderten Dateien zu erkennen.
Zugehörige Konzepte
Nachrichtenflüsse - Übersicht
ESQL-Funktionen
Zugehörige Tasks
Nachrichtenflüsse für die Verarbeitung von Namensbereichen aktivieren
Einen vorhandenen Nachrichtenfluss öffnen
Nachrichtenflussinhalt 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, 2005 Letzte Aktualisierung: Nov 17, 2005
ac02355_