Existen ciertos casos en los que la migración de archivos .mfmap no está soportada. Este tema explica las razones por las cuales la migración no es automática en estas situaciones y proporciona instrucciones para completar una migración satisfactoria.
El modelo de programación para las correlaciones de mensajes es diferente entre la Versión 5.0 (donde el formato de archivo es .mfmap) y la Versión 6.0 (donde el formato es .msgmap). Las correlaciones de mensajes de la Versión 5.0 tienen un modelo de programación de procedimiento, que es esencialmente un ESQL alternativo, en el que usted describe todos los pasos necesarios para realizar una transformación. La Versión 6.0 utiliza un modelo de programación declarativo, en el que usted describe el resultado de la transformación, y las herramientas determinan cómo conseguir dicho resultado.
La mayoría de los errores de migración son debidos a correlaciones de mensajes que contienen demasiada información sobre los pasos que realizan la transformación, e información insuficiente sobre el resultado deseado. Para estas correlaciones de mensajes, la migración se habilita modificando el archivo .mfmap de modo que secciones "how to" específicas se separen en una función o procedimiento ESQL al que la correlación de mensajes pueda llamar. El archivo .mfmap llama al ESQL en lugar de contenerlo como una expresión. El mandato mqsimigratemfmaps migra entonces el archivo .mfmap, pero llama al ESQL en lugar de anotar un error de migración.
Una limitación es que el ESQL (la ejecución para archivos .mfmap y .msgmap) no puede definir funciones que devuelven valores de elemento complejo (o REFERENCE). El procedimiento siguiente explica cómo resolver esta limitación de destino de elemento complejo; en muchos casos, eso significa que la correlación debe reescribirse como ESQL. Para obtener más ejemplos e información acerca de cómo llamar a ESQL desde correlaciones, consulte el ejemplo de correlación de WebSphere Message Brokers en .
src_msg.e[1] + src_msg.e[2]calcule el resultado en una función ESQL como:
CREATE FUNCTION addOneAndTwo(IN src_msg) BEGIN RETURN src_msg.e[1] + src_msg.e[2]; END;En el archivo .msgmap, llame a la función ESQL addOneAndTwo utilizando el elemento padre src_msg como parámetro.
src_msg.*o
src_msg.*[]puede procesarse utilizando una función que utiliza el padre del campo de repetición:
CREATE FUNCTION processAny(IN src_msg) BEGIN DECLARE nodeRef REFERENCE TO src_msg.e.*; DECLARE result <TipoDatos> <ValorInicial>; WHILE LASTMOVE nodeRef DO --la expresión va aquí SET result = result; END WHILE; RETURN RESULT; END;En el archivo .msgmap, llame a la función ESQL utilizando el elemento padre src_msg como parámetro.
src_msg.{'a' || 'b'}pueden procesarse mediante funciones ESQL que procesan el padre del campo de repetición:
CREATE FUNCTION processDynamicName(IN src_msg) BEGIN RETURN src_msg.{'a' || 'b'}; END;En el archivo .msgmap, llame a la función ESQL utilizando el elemento padre src_msg como parámetro.
SELECT MAX("#T".FIRSTNAME) FROM Database.CUSTOMER AS "#T" WHERE "#T".CUSTOMERID = custIdpueden procesarse mediante funciones ESQL que procesan el padre del campo de repetición:
CREATE FUNCTION processMAX(IN custId) BEGIN RETURN SELECT MAX("#T".FIRSTNAME) FROM Database.CUSTOMER AS "#T" WHERE "#T".CUSTOMERID = custId END;En el archivo .msgmap, llame a la función ESQL utilizando el elemento custId como parámetro.
e || "#I"deben reescribirse por completo en ESQL. Por definición, debe haber un elemento padre de repetición complejo, y esto no está soportado por las funciones ESQL.
src_msg.e[src_msg.a]se deben reescribir utilizando filas if, funciones msgmap:occurrence() y funciones ESQL:
for src_msg.e if condition msgmap:occurrence(src_msg/e) = src_msg/a
src_msg.e["#I" +5] src_msg.e[< 3]el archivo .mfmap entero debe reescribirse en ESQL, ya que los archivos .msgmap aún no dan soporte al acceso indexado a campos de repetición.
src_msg.e IN (1, 2, 3)deben reescribirse en ESQL, ya que los archivos .msgmap no dan soporte a expresiones ROW de ESQL.