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.
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.
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.
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.
SELECT MAX("#T".FIRSTNAME) FROM Database.CUSTOMER AS "#T" WHERE "#T".CUSTOMERID = custIdkö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.
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.
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
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.
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.
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.
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 |