In alcuni scenari non è prevista la migrazione dei file .mfmap. Questo argomento spiega perché la migrazione in tali situazioni non è automatica e fornisce istruzioni su come portare a termine una migrazione con esito positivo.
Il modello di programmazione per le mappe di messaggi è diversa tra la Versione 5.0 (dove il formato del file è .mfmap) e la Versione 6.0 (dove il formato è .msgmap). Le mappe di messaggi della Versione 5.0 hanno un modello di programmazione procedurale, che è essenzialmente un'ESQL alternativa, in cui vengono descritti tutti i passi che sono richiesti per eseguire una trasformazione. La Versione 6.0 utilizza un modello di programmazione dichiarativa in cui viene descritto il risultato della trasformazione e gli strumenti determinano come archiviare tale risultato.
La maggior parte degli errori di migrazione deriva dalle mappe di messaggi che contengono troppe informazioni sui passi che eseguono la trasformazione, ma non informazioni sufficienti sui risultati desiderati. Relativamente a tali mappe di messaggi, la migrazione è abilitata modificando il file .mfmap in modo che le specifiche sezioni su come procedere sono separate in una procedura o funzione ESQL che può essere richiamata dalla mappa di messaggi. Il file .mfmap richiama l'ESQL anziché di contenerla come un'espressione. Il comando mqsimigratemfmaps esegue quindi la migrazione del file .mfmap, ma richiama l'ESQL anziché registrare un errore di migrazione.
Una limitazione è che l'ESQL (il runtime per i file .mfmap e .msgmap) non può definire le funzioni che restituiscono valori (o REFERENCE) dell'elemento complesso. Nella seguente procedura viene spiegato come operare con questa limitazione di destinazione dell'elemento complesso: in molti casi, ciò significa che la mappa deve essere riscritta come ESQL. Per ulteriori esempi ed informazioni sul richiamo di ESQL dalle mappe, fare riferimento all'esempio di mappatura di WebSphere Message Broker in .
src_msg.e[1] + src_msg.e[2]calcolare il risultato in una funzione ESQL come:
CREATE FUNCTION addOneAndTwo(IN src_msg) BEGIN RETURN src_msg.e[1] + src_msg.e[2]; END;Nel file .msgmap, richiamare la funzione ESQL addOneAndTwo utilizzando l'elemento parent src_msg come un parametro.
src_msg.*oppure
src_msg.*[]può essere elaborata utilizzando una funzione che assume il parent del campo ripetuto:
CREATE FUNCTION processAny(IN src_msg) BEGIN DECLARE nodeRef REFERENCE TO src_msg.e.*; DECLARE result <dataType> <initialValue>; WHILE LASTMOVE nodeRef DO --posizione dell'espressione SET result = result; END WHILE; RETURN RESULT; END;Nel file .msgmap, richiamare la funzione ESQL utilizzando l'elemento parent src_msg come un parametro.
src_msg.{'a' || 'b'}possono essere elaborate dalle funzioni ESQL che elaborano il parent del campo ripetuto:
CREATE FUNCTION processDynamicName(IN src_msg) BEGIN RETURN src_msg.{'a' || 'b'}; END;Nel file .msgmap, richiamare la funzione ESQL utilizzando l'elemento parent src_msg come un parametro.
SELECT MAX("#T".FIRSTNAME) FROM Database.CUSTOMER AS "#T" WHERE "#T".CUSTOMERID = custIdpossono essere elaborate dalle funzioni ESQL che elaborano il parent del campo ripetuto:
CREATE FUNCTION processMAX(IN custId) BEGIN RETURN SELECT MAX("#T".FIRSTNAME) FROM Database.CUSTOMER AS "#T" WHERE "#T".CUSTOMERID = custId END;Nel file .msgmap, richiamare la funzione ESQL utilizzando l'elemento custId come un parametro.
e || "#I"devono essere riscritte interamente in ESQL. Per definizione, deve essere presente un elemento parent ripetuto complesso e questo non è supportato dalle funzioni ESQL.
src_msg.e[src_msg.a]devono essere riscritte utilizzando righe if, funzioni msgmap:occurrence() e funzioni ESQL:
for src_msg.e if condition msgmap:occurrence(src_msg/e) = src_msg/a
src_msg.e["#I" +5] src_msg.e[< 3]l'intero file .mfmap deve essere riscritto in ESQL, in quanto i file .msgmap non supportano ancora l'accesso indicizzato ai campi ripetuti.
src_msg.e IN (1, 2, 3)devono essere riscritti in ESQL, in quanto i file .msgmap non supportano le espressioni ESQL ROW.