Migración de un flujo de mensajes

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 en este tema que hace referencia a plug-ins definidos por el usuario y ESQL no es aplicable: 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 menajen 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. Aunque dichos flujos de mensajes continuarán funcionando correctamente cuando estén en WebSphere Message Broker, se recomienda que para estar al corriente de los espacios de nombres los actualice siguiendo los pasos descritos en Preparación de un flujo de mensajes para el espacio de nombres.

Es posible que desee cambiar los flujos de mensajes que migra para aprovechar los nuevos nodos y las nuevas características disponibles. 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, debe evitar 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 y utiliza este flujo como subflujo en otros flujos en el 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 biblioteca 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 área 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 área de trabajo activa, debe cerrarla. No puede ejecutar el mandato de migración si el área 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 en el directorio especificado, se han importado 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.
    • Se han creado los flujos de mensajes y los subflujos, y sus definiciones se han almacenado en archivos denominados <nombre_flujo>.msgflow. Se han creado los nodos definidos por el usuario y sus definiciones se han almacenado en archivos denominados <nombre_nodo>.msgnode.

      Si desea renombrar alguno de estos flujos de mensajes o nodos después de importar para ajustarse a los convenios de denominación locales, debe utilizar los recursos proporcionados por el área de trabajo para mantener la coherencia e integridad de todas las referencias. No renombre ningún archivo dentro del sistema de archivos.

    • Si alguno de los nodos en los flujos de mensajes contenía ESQL, éste se ha extraído del nodo y se ha almacenado en el archivo ESQL <nombre_flujo_mensajes>.esql. El ESQL de cada nodo se encuentra entra las sentencias CREATE y END MODULE correspondientes (para Compute, Database o Filter). Si todavía no existe el archivo ESQL, lo crea el mandato.

      Compruebe el nivel de compatibilidad ESQL por omisión en la página de preferencias del editor de ESQL. El valor por omisión para esta opción es 6.0, que hace que el código ESQL de ejecución se genere en el nivel 6.0 cuando se añade un flujo de mensajes a un archivo bar. Este código es incompatible con los intermediarios de la Versión 2.1. Si desea que el archivo bar incluya el ESQL de ejecución de la versión 2.0, debe restablecer la preferencia del editor. Si realiza esto, 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.

      Si desea ver más información, consulte Editor ESQL.

  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 finalización satisfactoria o con error de cada recurso migrado.
    • Una indicación de un subflujo que no se puede localizar (su 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 adecuado para resolver este error. 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 todo el proceso de exportación e importación.

    • Una indicación de que un recurso migrado como un flujo de mensajes y almacenado en un archivo .msgflow puede ser un nodo definido por el usuario. Si se produce este aviso, debe comprobar 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, debe completar las acciones que se indican en el paso 11.
  6. Inicie el área de trabajo y vaya 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 (pulse el botón derecho del ratón en el proyecto y seleccione Abrir proyecto). Si el proyecto ya está abierto, pulse el botón derecho del ratón y seleccione Renovar y luego 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. En la siguiente tabla se muestran los nodos que se sustituyen. El ESQL asociado a cada nodo se crea como un módulo con un nombre por omisión y la propiedad del 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 y los campos de referencias de ESQL en un mensaje proveniente de una cabecera C importada, y ha vuelto a crear el modelo de mensaje importando la cabecera C en el área de trabajo, compruebe las sentencias ESQL que hacen referencia a ese mensaje. Es posible que la importación al área 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, debe crear una función ESQL y llamar 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). Debe completar manualmente la migración y la definición en esta versión 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 área 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 tiene que volver a compilar el código para el nodo definido por el usuario, cuando lo migra.
    5. Detenga y reinicie el intermediario para que reconozca los archivos nuevos o cambiados.
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
Definición del 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, 2005 Última actualización: 11/11/2005
ac02355_