Migrar un flujo de mensajes

Antes de empezar:

Consulte el tema de concepto sobre condiciones para un intermediario de la Versión 5.0 que participe en un dominio de intermediarios de la Versión 6.0.

Puede migrar los flujos de mensajes que ha creado en la Versión 2.1 del producto (WebSphere MQ Event Broker, WebSphere MQ Integrator Broker o WebSphere MQ Integrator) y utilizarlos en WebSphere Message Broker Versión 6.0.

Si está migrando de WebSphere MQ Event Broker Versión 2.1, toda la información de este tema que hace referencia a plug-ins definidos por el usuario y ESQL no se aplica: estos recursos no están disponibles en WebSphere MQ Event Broker Versión 2.1.

Si ha migrado de WebSphere MQ Integrator Broker Versión 2.1, es posible que haya grabado flujos de mensajes que manejen mensajes XML que utilizan espacios de nombres XML. En la Versión 2.1, los mensajes XML de este tipo se analizan de un modo diferente del utilizado por WebSphere Message Broker Versión 6.0. Aunque dichos flujos de mensajes continuarán funcionando correctamente cuando estén en la Versión 6.0, es mejor actualizarlos para estar al corriente de los espacios de nombres siguiendo los pasos descritos en Preparación de un flujo de mensajes para el espacio de nombres.

Es aconsejable cambiar los flujos de mensajes que migra para aprovechar los nuevos nodos y las nuevas características que están disponibles en la Versión 6.0. Por ejemplo, es posible que desee sustituir un nodo definido por el usuario que recibe peticiones de servicios web por el nodo incorporado HTTPInput.

Si desea ver más información sobre los cambios en este release, consulte Novedades de la Versión 6.0.

Puede migrar más de un flujo de mensajes a la vez si desea que se definan en el mismo proyecto de flujo de mensajes. Debe migrar subflujos y nodos definidos por el usuario con los flujos de mensajes en los que están incluidos, para asegurar la coherencia de las referencias.

Si ha definido más de un flujo de mensajes con el mismo nombre, o el flujo de mensajes se ha exportado a más de un archivo de exportación, la tarea de migración escribe encima de cualquier flujo de mensajes existente con el siguiente flujo que encuentra con el mismo nombre, sin previo aviso. Por tanto, evite cuidadosamente los conflictos y asegurarse de que la versión más reciente de un flujo de mensajes definido varias veces sea el último en migrar.

Si tiene varias versiones del mismo flujo de mensajes, que utiliza como subflujo en otros flujos del mismo directorio de migración, el resultado de la importación es imprevisible.

Para migrar un flujo de mensajes:

  1. Antes de desinstalar la versión 2.1, exporte el flujo o flujos de mensajes desde el Centro de control utilizando las herramientas de la versión 2.1 (consulte la documentación de la Versión 2.1 para obtener información detallada).

    El proceso de migración es más eficaz cuando en el mismo archivo de exportación se incluyen todos los subflujos a los que se hace referencia, por tanto exporte todos los flujos de mensajes que desee migrar en un solo proyecto de flujo de mensajes, en un solo archivo de exportación.

  2. Transfiera el archivo o archivos de exportación al nuevo sistema en el que está ejecutando el entorno de trabajo. Compruebe que el directorio en el que almacena estos archivos no contenga otros archivos. Guarde los archivos que intenta importar en un solo proyecto de flujo de mensajes, en un directorio aparte y migre cada directorio de forma separada. Asegúrese de que no almacena ningún archivo en subdirectorios del directorio del proyecto, porque el mandato de migración ignora estos archivos.
  3. Si tiene una sesión del entorno de trabajo activa, ciérrela. No puede ejecutar el mandato de migración si el entorno de trabajo está en ejecución.
  4. En un indicador de mandatos, invoque el mandato mqsimigratemsgflows, especificando el nuevo nombre de proyecto y el directorio donde ha almacenado los archivos de exportación. Cuando el mandato se haya completado:
    • Los flujos de mensajes contenidos en los archivos de exportación del directorio especificado se importan al proyecto de flujo de mensajes especificado. Si el proyecto ya existe, los flujos de mensajes adicionales se incluyen con el contenido actual, si lo hay. Si el proyecto no existe antes de invocar el mandato, se crea automáticamente. Se recomienda permitir que el mandato cree el proyecto de flujo de mensajes automáticamente.
    • Los flujos y subflujos de mensajes se crean y las definiciones se almacenan en archivos denominados nombre_flujo.msgflow. Los nodos definidos por el usuario se crean y las definiciones se almacenan en archivos denominados nombre_nodo.msgnode.

      Si desea redenominar cualquiera de estos flujos de mensajes o nodos después de la importación para adaptarlos a los convenios de denominación locales, utilice los recursos proporcionados por el entorno de trabajo para conservar la coherencia y la integridad de todas las referencias. No redenomine ningún archivo dentro del sistema de archivos.

    • Si alguno de los nodos de los flujos de mensajes contiene ESQL, éste se extrae del nodo y se almacena en el archivo ESQL nombre_flujo_mensajes.esql. El ESQL de cada nodo se reinicia entre las sentencias CREATE y END MODULE apropiadas (para Compute, Database o Filter). El mandato crea el archivo ESQL si éste aún no existe.

      Inicio del cambioCuando añada un flujo de mensajes a un archivo bar, se genera código ESQL de ejecución a nivel de la Versión 6.0. Este código es incompatible con los intermediarios de la Versión 2.1. Si desea que el archivo bar incluya ESQL de ejecución de la versión 2.0, seleccione el recuadro Compilar ESQL para intermediarios de versión 2.1. Si lo hace, no puede incluir las mejoras de la Versión 6.0 en el código ESQL, pero puede desplegar los flujos en los intermediarios de la Versión 2.1 y la Versión 6.0.Fin del cambio

      Para obtener más información, consulte el tema Adición de archivos a un archivador de intermediario.

  5. Compruebe el archivo de informe mqsimigratemsgflows.report.txt que se graba en el directorio desde el que ha invocado el mandato. Proporciona la siguiente información:
    • El nombre de cada flujo de mensajes, subflujo y nodo definido por el usuario que se ha migrado. Si alguno de estos recursos tenía un nombre incompatible con la Versión 6.0, el mandato actualiza el nombre y todas las referencias a dicho nombre para asegurar la coherencia. (Si migra un recurso con un nombre no válido más de una vez, la corrección que se realiza en el nombre es siempre la misma.)
    • La realización satisfactoria o anómala de cada recurso que se migra
    • Una indicación de un subflujo que no se puede localizar (la definición no está contenida en ninguno de los archivos de exportación, pero se incluye en uno o más de los flujos de mensajes migrados). Si esto ocurre, busque el subflujo que falta e impórtelo al proyecto apropiado. Si, por algún motivo, no puede recuperar el subflujo que falta, vuelva a crearlo con el nombre original. A continuación, todos los flujos afectados podrán enlazar correctamente con el nuevo subflujo.

      No es necesario que repita el proceso de exportación e importación entero.

    • Una indicación de que un recurso que se ha migrado como flujo de mensajes y se ha almacenado en un archivo .msgflow puede ser un nodo definido por el usuario. Si se produce este aviso, compruebe si el recurso especificado es un nodo definido por el usuario o un flujo de mensajes. Si es un flujo de mensajes, se ha migrado correctamente. Si es un nodo definido por el usuario, realice las acciones descritas en el paso 11.
  6. Inicie el entorno de trabajo y conmute a la Perspectiva de Desarrollo de aplicaciones de intermediario.
  7. Abra el proyecto de flujo de mensajes creado o actualizado por el mandato de migración pulsando el botón derecho del ratón sobre el proyecto y pulsando Abrir proyecto).

    Si el proyecto ya está abierto, pulse el botón derecho del ratón y seleccione Renovar y, a continuación, Volver a crear el proyecto para asegurarse de que la vista Navegador refleja el nuevo contenido. Volver a crear también realiza una validación del contenido del proyecto de flujo de mensajes.

    Puesto que ESQL y las correlaciones se manejan de un modo diferente en la Versión 6.0, el proceso de migración sustituye algunos de los nodos de la Versión 2.1 por nodos de la Versión 6.0 diferentes. La tabla siguiente lista los nodos sustituidos. El ESQL asociado a cada nodo se crea como un módulo con un nombre predeterminado y la propiedad de nodo se establece en el nombre de ese módulo.

    Nodo de la Versión 2.1 Nodo de la Versión 6.0
    Compute Compute
    Filter Filter
    Database Database
    DataDelete Database
    DataInsert Database
    DataUpdate Database
    Extract Compute
    Warehouse Database
  8. Si un flujo de mensajes incluye uno o varios nodos Filter, compruebe el módulo ESQL para cada nodo en el archivo ESQL para asegurarse de que la sentencia RETURN devuelve correctamente una expresión válida que se resuelve en un valor booleano.
  9. Si un flujo de mensajes incluye un nodo con ESQL, los campos de referencias de ESQL de un mensaje obtenido de una cabecera C importada y ha vuelto a crear el modelo de mensaje importando la cabecera C al entorno de trabajo, compruebe las sentencias ESQL que hacen referencia a ese mensaje. Es posible que la importación al entorno de trabajo de la Versión 6.0 cree un modelo con convenios de denominación diferentes de los creados por el importador de la Versión 2.1 y que sea necesario actualizar una o varias referencias de campo.
  10. Si había promocionado la propiedad ESQL de cualquiera de los nodos de la Versión 2.1 que incluía la personalización de ESQL para volver a utilizar ESQL en varios nodos, esto no se mantiene en los flujos de mensajes de la Versión 6.0 migrados porque la promoción de las propiedades relacionadas con ESQL ya no se soporta. La vista Tareas muestra un error para cada propiedad de ESQL promocionada. Para lograr el mismo efecto, cree una función ESQL y llame a esa función desde el módulo ESQL de cada nodo.
  11. Si ha migrado un nodo definido por el usuario, sólo el archivo de definición de interfaz XML se migra a un archivo .msgnode de nodo (define solamente los terminales y las propiedades del nodo). Complete la migración y la definición manualmente en la Versión 6.0 del producto. Los pasos siguientes proporcionan una indicación del proceso que se requiere: para obtener más detalles, consulte Creación de la representación de la interfaz de usuario de un nodo definido por el usuario en el entorno de trabajo.
    1. Cree un proyecto de nodo definido por el usuario y mueva el archivo .msgnode del proyecto de flujo de mensajes al nuevo proyecto de nodo definido por el usuario. Al hacerlo, se crean los archivos de propiedades asociados.
    2. Opcional: Complete el desarrollo del nodo definido por el usuario en el entorno de Eclipse para crear el plug-in de Eclipse del nodo definido por el usuario (la estructura de directorio que contiene los archivos que forman este nodo). Esta tarea incluye la creación de recursos de nodo para la ayuda, iconos, y compiladores y editores de propiedades, si fuera necesario.
    3. Consulte si hay errores en la lista de tareas. Por ejemplo, es posible que éstos se generen si el nombre de nodo o los nombres de terminal incluyen el carácter de espacio (no se soporta en la Versión 6.0) o si un flujo incorpora otro flujo migrado y la referencia no es correcta. Resuelva estos errores corrigiendo los nombres o utilizando la opción de menú Localizar subflujo.
    4. Instale el código de ejecución para el nodo (el archivo .lil) en los sistemas de intermediario apropiados. No necesita volver a compilar el código para el nodo definido por el usuario al migrarlo.
    5. Detenga y reinicie el intermediario para que reconozca los archivos nuevos o cambiados.
Cuando haya migrado los recursos, consulte las Tareas posteriores de la migración de la Versión 2.1 para obtener información sobre las tareas que puede desear realizar después de la migración.
Conceptos relacionados
Visión general de flujos de mensajes
Funciones ESQL
Tareas relacionadas
Preparación de un flujo de mensajes para el espacio de nombres
Abrir un flujo de mensajes existente
Definir el contenido del flujo de mensajes
Desarrollo de ESQL
Referencia relacionada
Perspectiva de Desarrollo de aplicaciones de intermediario
Editor ESQL
Nodos incorporados
Mandato mqsimigratemsgflows
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
ac02355_