Restricciones en la migración de correlaciones de mensajes

Obtenga información sobre cómo migrar correlaciones de mensajes de Versión 5.0.

El modelo de programación para las correlaciones de mensaje 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 necesario. Para estas correlaciones de mensajes, la migración se habilita cambiando el archivo .mfmap para que las secciones "how to" específicas se separen en una función o un procedimiento ESQL al que la correlación de mensajes pueda llamar. El archivo .mfmap llama a la función ESQL en lugar de contenerla como una expresión. Entonces el mandato mqsimigratemfmaps migra el archivo .mfmap, pero llama a la función ESQL en lugar de anotar un error de migración.

Una limitación consiste en que 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, la correlación se debe volver a escribir como una función ESQL. Para ver más ejemplos y obtener información sobre cómo llamar a ESQL desde las correlaciones, consulte el ejemplo siguiente: Los ejemplos sólo pueden verse cuando se utiliza el centro de información que está integrado en el Kit de herramientas de Message Brokers.
  1. Determine si puede definir una función ESQL para el archivo .mfmap.
    1. Cuando el valor de destino es un elemento complejo o, en términos de ESQL, una REFERENCE, la correlación individual se debe volver a escribir en el archivo .msgmap. Suprima la correlación del archivo .mfmap y continúe en el Paso 4.
    2. Utilice una función para todos los demás casos: serie de caracteres (CHAR), números, fecha y hora. Continúe en el Paso 2.
  2. Determine los parámetros de origen y el tipo de retorno para la función.
    1. Para cada vía de acceso de origen en la correlación, debe haber un parámetro en la función o procedimiento. Para una función, todos los parámetros son inalterables. El tipo del parámetro debe coincidir con el tipo de los datos de origen.
    2. El tipo de retorno de la función es el tipo de datos ESQL identificado anteriormente.
  3. Actualice el archivo .mfmap para habilitar la migración. Cambie el archivo .mfmap para invocar la función en la correlación, pasando los parámetros de origen a la función en el orden en que se listan en el paso 2a.
  4. Vuelva a ejecutar el mandato mqsimigratemfmaps para migrar el archivo .mfmap modificado.
  5. Repita los Pasos 1 a 4 hasta que no se indiquen errores en las anotaciones de migración.
  6. Inicie el Kit de herramientas de Message Brokers de la Versión 6.0 y abra el archivo .msgmap migrado.
    1. Para el ESQL que se ha migrado como funciones, no debería haber ningún error.
    2. Para destinos de elemento complejo, reescriba la correlación utilizando las características de la Versión 6.0.
Los ejemplos siguientes ilustran la migración de archivos .mfmap a archivos .msgmap.
  • Para migrar una referencia múltiple a una expresión de origen de repetición:
    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 addOneAndTwo de ESQL mediante el elemento padre src_msg como parámetro.

  • Una expresión que no utiliza nombres de elemento:
    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 addOneAndTwo de ESQL mediante el elemento padre src_msg como parámetro.

  • Las expresiones que calculan de forma dinámica nombres de elemento:
    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 processDynamicName de ESQL mediante el elemento padre src_msg como parámetro.

  • Las expresiones que utilizan las funciones select MIN, MAX y COUNT:
    SELECT MAX("#T".FIRSTNAME)  		
    	FROM Database.CUSTOMER AS "#T"  		
    	WHERE "#T".CUSTOMERID = custId  
    pueden 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 processMAX de ESQL mediante el elemento custId como parámetro.

  • Los archivos .mfmap que utilizan variables de índice mfmap en expresiones:
    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.

  • Las expresiones que utilizan expresiones de origen para calcular valores:
    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 

  • Para las expresiones que utilizan expresiones de índice para calcular valores:
    src_msg.e["#I" +5] 	
    src_msg.e[< 3]  
    el archivo .msgmap entero se debe volver a escribir en ESQL, porque los archivos .msgmap no soportan el acceso indexado a los campos de repetición.

  • Los archivos .mfmap que utilizan expresiones ROW para calcular valores:
    src_msg.e IN (1, 2, 3)  
    se deben volver a escribir en ESQL, porque los archivos .msgmap no soportan expresiones ROW de ESQL.

Restricciones en la migración de subcorrelaciones

En las correlaciones de mensajes de la Versión 5.0, cualquier tipo de elemento complejo puede ser la raíz de una subcorrelación. Sin embargo, en la Versión 6.0, sólo un elemento global o un atributo global pueden ser la raíz de una subcorrelación. Cuando se migra una correlación de mensajes de la Versión 5.0 con una llamada a una subcorrelación con un elemento no global como raíz de la correlación, la subcorrelación no se migra como una subcorrelación autónoma. La llamada a la subcorrelación en la correlación de mensajes principal se sustituye por el contenido migrado de la subcorrelación. Como método alternativo, si la subcorrelación tiene un elemento global como raíz de la correlación, la subcorrelación se migra como subcorrelación autónoma de la Versión 6.0.

Para la Versión 6.0, debe definir estructuras de esquema reutilizables como elementos y tipos globales. Si tiene subcorrelaciones de la Versión 5.0 que utilizan elementos locales, debe cambiar el esquema para añadir definiciones de elementos globales para los elementos locales y, a continuación, utilizar el nuevo esquema después de la migración. Si los nuevos elementos globales tienen el mismo nombre y tipo que los elementos locales, no es necesario cambiar las subcorrelaciones de la Versión 5.0.

Un elemento local de una subcorrelación de la Versión 5.0 se debe calificar con un espacio de nombres para asegurar que la migración se realice satisfactoriamente a la Versión 6.0, porque el elemento global que lo sustituye después de la migración debe estar calificado por el espacio de nombres. Si la subcorrelación contiene elementos locales, debe volver a crear la subcorrelación y volver a crear la llamada a la subcorrelación desde la correlación de mensajes principal.

La tabla siguiente muestra las diferencias entre las características soportadas en una subcorrelación en la Versión 5.0 y en la Versión 6.0.
Versión Característica soportada
Versión 5.0 elementos globales y atributos globales como origen de correlación
elementos globales y atributos globales como destino de correlación
elementos locales y atributos locales como origen de correlación
elementos locales y atributos locales como destino de correlación
Versión 6.0 elementos globales, atributos globales y tipos globales como origen de correlación
elementos globales y atributos globales como destino de correlación
Tareas relacionadas
Desarrollo de ESQL
Referencia relacionada
Migración de correlaciones de mensajes de la Versión 5.0
Mandato mqsimigratemfmaps
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Última actualización : 2009-02-16 13:56:05

ar25255_