Migrar un flujo de mensajes

Antes de empezar:

Lea la información sobre las diferencias entre los productos de la Versión 2.1 y 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 estos flujos de mensajes seguirán funcionando correctamente cuando estén en la Versión 6.0, actualícelos para prepararlos para espacios 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.

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 sobrescribe, sin previo aviso, cualquier flujo de mensajes existente con el siguiente flujo que encuentra con el mismo nombre. Por consiguiente, procure evitar conflictos y asegúrese de que la versión más reciente de un flujo de mensajes que se ha definido más de una vez sea la última que migra.

Si tiene varias versiones del mismo flujo de mensajes, que utiliza como subflujo en otros flujos del mismo directorio de migración, el resultado del proceso de 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 hay 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 en el que ha almacenado los archivos de exportación. Cuando el mandato se ha completado:
    • Los flujos de mensajes que están 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. El mandato es más efectivo si crea el proyecto de flujo de mensajes automáticamente en su nombre.
    • Se crean flujos de mensajes y subflujos y sus definiciones se almacenan en archivos denominados nombre_flujo.msgflow. Se crean nodos definidos por el usuario y sus definiciones se almacenan en archivos denominados nombre_nodo.msgnode.

      Una vez que los haya importado, si desea redenominar cualquiera de estos flujos de mensajes o nodos para adaptarlos a sus convenios de denominación locales, utilice solamente los recursos que se proporcionan en el entorno de trabajo, a fin de mantener la coherencia e 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, el código se extrae del propio nodo y se almacena en el archivo ESQL nombre_flujo_mensajes.esql. El ESQL de cada nodo se incluye 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.

      Cuando 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.1, 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.

      Para obtener más información, consulte 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.)
    • El resultado satisfactorio o anómalo 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 se produce este problema, 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 vaya a la Perspectiva de Desarrollo de aplicaciones de intermediario.
  7. Abra el proyecto de flujo de mensajes que se ha creado o actualizado con el mandato de migración.

    Si el proyecto ya está abierto, pulse el botón derecho del ratón sobre el mismo y seleccione Renovar, luego pulse Reconstruir proyecto para asegurarse de que la vista Desarrollo de intermediario refleje el nuevo contenido. Volver a crear también realiza una validación del contenido del proyecto de flujo de mensajes.

    Puesto que el 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, el ESQL hace referencia a campos de un mensaje obtenido de una cabecera C importada, y usted ha vuelto a crear el modelo de mensaje importando la cabecera C al entorno de trabajo, compruebe las sentencias ESQL que hacen referencia a este mensaje. El proceso de importación al entorno de trabajo de la Versión 6.0 puede crear un modelo con convenios de denominación diferentes de los creados por el importador de la Versión 2.1, y es posible que tenga que 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 personalización de ESQL para volver a utilizar ESQL en varios nodos, la promoción no se mantiene en los flujos de mensajes de la Versión 6.0 migrados porque la promoción de propiedades relacionadas con ESQL ya no está soportada. 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 de nodo .msgnode (este archivo 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 resumen brevemente el proceso a seguir. Para ver información más detallada, consulte el tema Creación de la representación de 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 mover este archivo, 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. Pueden generarse errores, por ejemplo, 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 a la migración de la Versión 2.1 para obtener información sobre las tareas que tal vez desee realizar después de la migración.
Conceptos relacionados
Visión general de flujos de mensajes
Funciones ESQL
Tareas relacionadas
Creación de un flujo de mensajes preparado 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, 2009Copyright IBM Corporation 1999, 2009.
Última actualización : 2009-02-16 13:53:36

ac02355_