Einschränkungen bei der Migration von Nachrichtenzuordnungen

Hier erfahren Sie, wie Sie Nachrichtenzuordnungen aus Version 5.0 migrieren.

Das Programmiermodell für Nachrichtenzuordnungen in Version 5.0 (mit dem Dateiformat .mfmap) unterscheidet sich in wesentlichen Punkten vom Programmiermodell in Version 6.0 (mit dem Dateiformat .msgmap). Das Programmiermodell für Nachrichtenzuordnungen in Version 5.0 ist ein prozedurales Programmiermodell, das im Grunde genommen eine Alternative zu ESQL darstellt. In diesem Modell werden alle erforderlichen Schritte für die Durchführung einer Umsetzung beschrieben. In Version 6.0 wird ein deklaratives Programmiermodell verwendet. In diesem Modell wird das Ergebnis der Umsetzung beschrieben; über die Tools wird festgelegt, wie das Ergebnis erzielt wird.

Die meisten Migrationsfehler sind darauf zurückzuführen, dass die Nachrichtenzuordnungen zu viele Informationen zu den Schritten für die Umsetzung und zu wenig Informationen zu dem erforderlichen Ergebnis enthalten. Für diese Nachrichtenzuordnungen wird die Migration aktiviert, indem die .mfmap-Datei geändert wird, so dass bestimmte Abschnitte zur Vorgehensweise gesondert in eine ESQL-Funktion oder -Prozedur geschrieben werden, die von der Nachrichtenzuordnung aufgerufen werden kann. Die ESQL-Funktion wird aus der .mfmap-Datei aufgerufen und ist nicht als Ausdruck darin enthalten. Mit dem Befehl mqsimigratemfmaps wird die .mfmap-Datei dann migriert, wobei jedoch kein Migrationsfehler protokolliert, sondern die ESQL-Funktion aufgerufen wird.

Eine Einschränkung besteht darin, dass ESQL (die Laufzeit für .mfmap und .msgmap-Dateien) keine Funktionen definieren kann, die komplexe Elementwerte (Werte des Typs REFERENCE) zurückgeben. In der folgenden Prozedur wird erläutert, wie diese Einschränkung für komplexe Elemente umgangen werden kann; in vielen Fällen muss die Zuordnung als ESQL-Funktion neu geschrieben werden. Weitere Beispiele und Informationen zum Aufrufen von ESQL-Code aus Zuordnungen finden Sie im folgenden Mustercode: Sie können Beispiele nur anzeigen, wenn Sie das Information Center verwenden, das im Message Brokers Toolkit integriert ist.
  1. Stellen Sie fest, ob Sie eine ESQL-Funktion für die .mfmap-Datei definieren können.
    1. Wenn es sich beim Zielwert um ein komplexes Element oder um den ESQL-Typ REFERENCE handelt, muss die einzelne Zuordnung in der .msgmap-Datei neu geschrieben werden. Löschen Sie die Zuordnung aus der .mfmap-Datei, und gehen Sie zu Schritt 4.
    2. Verwenden Sie in allen anderen Fällen eine Funktion: Zeichenfolge, Zahlen, Datum und Uhrzeit. Fahren Sie mit Schritt 2 fort.
  2. Bestimmten Sie die Quellenparameter und den Rückgabetyp für Ihre Funktion.
    1. Für alle Quellenpfade in der Zuordnung muss es jeweils einen Parameter in der Funktion bzw. Prozedur geben. Bei einer Funktion können die Parameter nicht geändert werden. Der Parametertyp muss dem Quellendatentyp entsprechen.
    2. Der Funktionsrückgabetyp entspricht dem zuvor identifizierten ESQL-Datentyp.
  3. Aktualisieren Sie die .mfmap-Datei, um die Migration zu aktivieren. Ändern Sie die .mfmap-Datei, um die Funktion in der Zuordnung aufzurufen, und übergeben Sie der Funktion die Quellenparameter in der Reihenfolge, in der sie in Schritt 2a aufgelistet sind.
  4. Führen Sie den Befehl mqsimigratemfmaps erneut aus, um die geänderte .mfmap-Datei zu migrieren.
  5. Wiederholen Sie die Schritte 1 bis 4, bis im Migrationsprotokoll keine Fehler mehr enthalten sind.
  6. Starten Sie das Message Brokers Toolkit der Version 6.0, und öffnen Sie die migrierte .msgmap-Datei.
    1. Für ESQL-Ausdrücke, die als Funktionen migriert wurden, sollten keine Fehler auftreten.
    2. Für komplexe Elementziele sollten Sie die Zuordnung unter Verwendung der Version 6.0-Funktionen neu schreiben.
Die folgenden Beispiele zeigen die Migration von .mfmap-Dateien in .msgmap-Dateien.
  • Gehen Sie wie folgt vor, um einen Mehrfachverweis auf einen sich wiederholenden Quellenausdruck zu migrieren:
    src_msg.e[1] + src_msg.e[2]  
    Berechnen Sie das Ergebnis in einer ESQL-Funktion. Beispiel:
    CREATE FUNCTION addOneAndTwo(IN src_msg)
    BEGIN
    	RETURN src_msg.e[1] + src_msg.e[2]; 	
    END;  
    Rufen Sie in der .msgmap-Datei die ESQL-Funktion 'addOneAndTwo' unter Angabe des übergeordneten Elements src_msg als Parameter auf.

  • Ein Ausdruck, der keine Elementnamen verwendet
    src_msg.* 
    oder
    src_msg.*[]  	
    kann unter Verwendung einer Funktion verarbeitet werden, die das übergeordnete Element des Wiederholungsfeld verarbeiten:
    CREATE FUNCTION processAny(IN src_msg)  	
    BEGIN 		
    	DECLARE nodeRef REFERENCE TO src_msg.e.*; 		
    	DECLARE result <dataType> <initialValue>;
    	WHILE LASTMOVE nodeRef DO 			
    		--expression goes here 			
    		SET result = result; 		
    	END WHILE; 		
    	RETURN RESULT; 	
    END;  
    Rufen Sie in der .msgmap-Datei die ESQL-Funktion 'processAny' unter Angabe des übergeordneten Elements src_msg als Parameter auf.

  • Ausdrücke, die Elementnamen dynamisch berechnen
    src_msg.{'a' || 'b'}  
    können von Funktionen verarbeitet werden, die das übergeordnete Element des Wiederholungsfeldes verarbeiten:
    CREATE FUNCTION processDynamicName(IN src_msg)  	
    BEGIN 		
    	RETURN src_msg.{'a' || 'b'}; 	
    END;  
    Rufen Sie in der .msgmap-Datei die ESQL-Funktion 'processDynamicName' unter Angabe des übergeordneten Elements src_msg als Parameter auf.

  • Ausdrücke, die die Funktionen MIN, MAX und COUNT verwenden:
    SELECT MAX("#T".FIRSTNAME)  		
    	FROM Database.CUSTOMER AS "#T"  		
    	WHERE "#T".CUSTOMERID = custId  
    können von Funktionen verarbeitet werden, die das übergeordnete Element des Wiederholungsfeld verarbeiten:
    CREATE FUNCTION processMAX(IN custId)  	
    BEGIN 		
    	RETURN  			
    	SELECT MAX("#T".FIRSTNAME) 				
    		FROM Database.CUSTOMER AS "#T" 				
    		WHERE "#T".CUSTOMERID = custId 	
    END;  
    Rufen Sie in der .msgmap-Datei die ESQL-Funktion 'processMAX' unter Angabe des Elements custId als Parameter auf.

  • .mfmap-Dateien, die MFMAP-Indexvariablen in Ausdrücken verwenden:
    e || "#I"  
    müssen in ESQL vollständig neu geschrieben werden. Laut Definition muss ein komplexes übergeordnetes Wiederholelement vorhanden sein. Dies wird von ESQL-Funktionen nicht unterstützt.

  • Ausdrücke, die Quellenausdrücke für die Berechnung von Werten verwenden:
    src_msg.e[src_msg.a]  
    müssen unter Verwendung von if-Zeilen, 'msgmap:occurrence()'-Funktionen und ESQL-Funktionen neu geschrieben werden:
    for src_msg.e 		
    	if 			
    		condition msgmap:occurrence(src_msg/e) = src_msg/a 

  • Für Ausdrücke, die Indexausdrücke für die Berechnung von Werten verwenden:
    src_msg.e["#I" +5] 	
    src_msg.e[< 3]  
    muss die gesamte .msgmap-Datei in ESQL neu geschrieben werden, da der indexierte Zugriff auf Wiederholungsfelder von .msgmap-Dateien nicht unterstützt wird.

  • .mfmap-Dateien, die ROW-Ausdrücke für die Berechnung von Werten verwenden:
    src_msg.e IN (1, 2, 3)  
    müssen in ESQL neu geschrieben werden, da ESQL-ROW-Ausdrücke von .mfmap-Dateien nicht unterstützt werden.

Einschränkungen bei der Migration von Submaps

In Nachrichtenzuordnungen der Version 5.0 kann jeder komplexe Elementtyp das Stammelement einer Submap sein. In Version 6.0 kann jedoch nur ein globales Element oder ein globales Attribut ein Stammelement einer Submap sein. Wenn eine Nachrichtenzuordnung der Version 5.0 mit einem Aufruf an eine Submap mit einem nicht globalen Element als Zuordnungsstammelement migriert wird, wird die Submap nicht als eigenständige Submap migriert. Stattdessen wird der Aufruf der Submap in der Hauptnachrichtenzuordnung durch den migrierten Inhalt der Submap ersetzt. Alternativ gilt Folgendes: Wenn die Submap über ein globales Element als Zuordnungsstammelement verfügt, wird die Submap stattdessen auf eine eigenständige Submap der Version 6.0 migriert.

Für Version 6.01 müssen Sie wiederverwendbar Schemastrukturen als globale Elemente und Typen definieren. Wenn Sie über Submaps der Version 5.0 verfügen, die lokale Elemente verwenden, müssen Sie das Schema dahingehend ändern, dass für die lokalen Elemente Definitionen globaler Elemente hinzugefügt werden. Nach der Migration müssen Sie dann das neue Schema verwenden. Wenn die neuen globalen Elemente denselben Namen und Typ wie die lokalen Elemente haben, müssen die Submaps der Version 5.0 nicht geändert werden.

Es muss ein lokales Element in einer Submap der Version 5.0 mit einen Namespace qualifiziert werden, damit es erfolgreich auf Version 6.0 migriert werden kann. Dies ist darauf zurückzuführen, dass das globale Element, durch das es bei der Migration ersetzt wird, über den Namespace qualifiziert sein muss. Wenn Ihre Submap lokale Elemente enthält, müssen Sie die Submap und auch den Aufruf der Submap über die Hauptnachrichtenzuordnung erneut erstellen.

In der folgenden Tabelle werden die Unterschiede zwischen den Funktionen bei Version 5.0 und Version 6.0 dargestellt, die in einer Submap unterstützt werden.
Version Unterstützte Funktion
Version 5.0 globale Elemente und globale Attribute als Zuordnung
globale Elemente und globale Attribute als Zuordnungsziel
lokale Elemente und lokale Attribute als Zuordnungsquelle
lokale Elemente und lokale Attribute als Zuordnungsziel
Version 6.0 globale Elemente, globale Attribute und globale Typen als Zuordnungsquelle
globale Elemente und globale Attribute als Zuordnungsziel
Zugehörige Tasks
ESQL erstellen
Zugehörige Verweise
Nachrichtenzuordnungen von Version 5.0 migrieren
mqsimigratemfmaps-Befehl
Bemerkungen | Marken | Downloads | Bibliothek | Unterstützung | Feedback

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Letzte Aktualisierung : 2009-02-17 15:29:52

ar25255_