Migración de un flujo de mensajes

Puede hacer una migración de 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 Business Integration Message Broker versión 5.0.

(Si está migrando de WebSphere MQ Event Broker versión 2.1, toda la información de este tema que haga referencia a los ESQL Y plug-in definidos por el usuario no se aplica: estos recursos no están disponibles en WebSphere MQ Event Broker versión 2.1).

Es posible que desee cambiar los flujos de mensajes que migra para aprovechar los nuevos nodos y las características que están disponibles. Por ejemplo, quizá desee sustituir un nodo definido por el usuario que reciba peticiones de servicios web por el nodo HTTPInput incorporado.Para obtener más información sobre los cambios que se han realizado en este release, consulte el apartado Novedades.

Puede hacer una migración de más de un flujo de mensajes a la vez, si desea definirlos 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 a fin de garantizar la coherencia de la referencias.

Si ha definido más de un flujo de mensajes con el mismo nombre o si ha exportado el flujo de mensajes a más de un archivo de exportación, la tarea de migración escribe encima, sin avisar, de todos los flujos de mensajes existentes con el flujo siguiente que encuentra con el mismo nombre. Por lo tanto, debe prestar atención a fin de evitar posibles conflictos y, en el caso de un flujo de mensajes definido varias veces, asegurarse de que migra en último lugar la versión más reciente.

Si tiene varias versiones del mismo flujo de mensajes y lo utiliza como subflujo de otros flujos en el mismo directorio de migración, los resultados de la importación sin imprevisibles.

Para migrar un flujo de mensajes:

  1. Antes de desinstalar la Versión 2.1, exporte los flujos de mensajes del Centro de control utilizando las herramientas de la Versión 2.1 (para obtener información detallada, consulte la biblioteca de la Versión 2.1.

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

  2. Transfiera los archivos de exportación al nuevo sistema en el que ejecuta el área de trabajo. Compruebe que el directorio en el que almacena los archivos no contenga ningún otro archivo. Almacene los archivos que prevé exportar en un único proyecto de flujo de mensajes en un directorio separado y migre los directorios uno a uno. Asegúrese de que no almacena ningún archivo en subdirectorios del directorio de proyectos, puesto que el mandato de migración ignora estos archivos.
  3. Si tiene una sesión de área de trabajo abierta, debe cerrarla. No puede ejecutar el mandado de migración si el área de trabajo están en ejecución.
  4. En un indicador de mandatos, invoque el mandato mqsimigratemsgflows especificando el nuevo nombre del proyecto y el directorio en el que ha almacenado los archivos de exportación (consulte el apartado Mandato mqsimigratemsgflows para obtener información detallada sobre este mandato). Cuando se completa el mandato:
    • El flujo de mensajes contenido en los archivos de exportación del directorio especificado se importa al proyecto de flujo de mensajes especificado. Si el proyecto ya existía, los flujos de mensajes adicionales se incluyen con el contenido actual, si procede. Si el flujo de mensajes no existe antes de invocar el mandato, se crea automáticamente. Se aconseja permitir que el mandato cree el proyecto de flujo de mensajes automáticamente.
    • Se crean los flujos de mensajes y los subflujos, y sus definiciones se almacenan en archivos denominados <nombre_flujo>.msgflow. Se crean los nodos definidos por el usuario y sus definiciones se almacenan en archivos denominados <nombre_nodo>.msgnode.

      Si desea redenominar cualquiera de estos flujos de mensajes o nodo después de importarlos de modo que cumplan con sus convenios de denominación locales, debe utilizar los recursos que se proporcionan en el área de trabajo a fin de mantener la coherencia y la integridad de todas las referencias. No redenomine ningún archivo del sistema de archivos.

    • Si alguno de los nodos de los flujos de mensajes contiene ESQL, estos se extraen del nodo y se almacenan en el archivo ESQL <nombre_flujo_mensajes>.esql. El ESQL de cada nodo se acomoda entre las sentencias CREATE y END MODULE adecuadas (para Compute, Database o Filter). El mandato crea el archivo ESQL si aún no existe.

      Inicio del cambioCompruebe el nivel de compatibilidad por omisión de ESQL en la página de preferencias del editor de ESQL. El valor por omisión para esta opción es 5.0, lo que genera código ESQL de ejecución en el nivel 5.0 cuando se añade un flujo de mensajes en un archivo bar. 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, debe restablecer la preferencia del editor. Si lo hace, no puede incluir las mejoras de la versión 5.0 en el código ESQL, pero puede difundir los flujos tanto a intermediarios de la versión 2.1 como de la versión 5.0. Para obtener información más detallada, consulte el apartado Editor ESQL.Fin del cambio

  5. Compruebe el archivo de informe mqsimigratemsgflows.report.txt que se escribe en el directorio desde el que se ha invocado el mandato. El mandato proporciona la información siguiente:
    • El nombre de cada flujo de mensajes, subflujo, nodo definido por el usuario que se ha migrado. Si alguno de estos recursos tiene un nombre que es incompatible con la Versión 5.0, el mandato actualiza el nombre y todas las referencias a dicho nombre a fin de garantizar la coherencia. (Si migra más de una vez un recurso que tiene un nombre no válido, la corrección que se realiza en el nombre siempre es la misma).
    • Si la migración de cada recurso se ha realizado de modo correcto o con error.
    • Una indicación de un subflujo que no se ha podido localizar (su definición no está contenida en ningún archivo de exportación, pero está incluida en uno o más de los flujos de mensajes migrados). En este caso, localice el subflujo que falta e impórtelo al proyecto adecuado para resolver este error. Si, por cualquier motivo, no puede recuperar el subflujo que falta, vuélvalo a crear con el nombre original. De este modo, todos los flujos afectados se pueden enlazar correctamente al nuevo subflujo.

      No es necesario que repita el proceso de importación y exportación completo.

    • Una indicación de que un recurso migrado como flujo de mensajes y 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 se trata de un flujo de mensajes, se ha migrado correctamente, pero 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 conmute a la perspectiva Desarrollo de aplicaciones de intermediario.
  7. Abra el proyecto de flujo de mensajes que ha creado o actualizado 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, a continuación, Volver a crear proyecto para asegurarse de que la vista Navegador refleja el nuevo contenido. La acción de volver a crear también lleva a cabo una validación del contenido del proyecto de flujo de mensajes.

    Puesto que las correlaciones y ESQL se manejan de modo distinto en la Versión 5.0, el proceso de migración sustituye algunos de los nodos de la versión 2.1 por nodos diferentes de la versión 5.0. Los nodos sustituidos se muestran en la tabla siguiente. 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 dicho módulo.

    Nodo de la Versión 2.1 Nodo de la Versión 5.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 más nodos Filter, compruebe el módulo ESQL de cada nodo del archivo ESQL a fin de asegurarse de que la sentencia RETURN devuelva correctamente una expresión válida que se resuelva en un valor booleano.
  9. Si un flujo de mensajes incluye un nodo con ESQL, los campos de referencias ESQL de un mensaje derivan de una cabecera C importada y se ha vuelto a crear el modelo de mensaje al importar la cabecera C al área de trabajo, compruebe las sentencias ESQL que hacen referencia al mensaje. La importación al área de trabajo de la Versión 5.0 puede crear un modelo con convenios de denominación diferentes a los que se han utilizado para la creación con el importador de la Versión 2.1, por lo que es posible que necesite actualizar una o más referencias de campo.
  10. Si ha promocionado la propiedad ESQL de cualquiera de los nodos de la Versión 2.1 que incluyen la personalización de ESQL para la reutilización de ESQL en varios nodos, esta no se mantiene en los flujos de mensajes de la Versión 5.0 migrada, puesto que ya no se ofrece soporte para la promoción de propiedades relacionadas de ESQL. La vista Tareas muestra un error para cada propiedad promocionada de ESQL. Para obtener el mismo efecto, debe crear una función ESQL e invocar a la función correspondiente desde el módulo ESQL de cada nodo.
  11. Si ha migrado un nodo definido por el usuario, sólo se migra el archivo de definición de interfaz XML a un archivo .msgnode del nodo (lo que sólo define los terminales y las propiedades del nodo). Debe completar manualmente la migración y definición en la versión del producto. En los pasos siguientes se proporciona un esquema del proceso necesario: para obtener información detallada, consulte el apartado Creación de la representación de 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 asociadas.
    2. Opcional: Desarrollo completo del nodo definido por el usuario en el entorno Eclipse para crear el plug-in Eclipse del nodo definido por el usuario (la estructura de directorios que contiene los archivos que integran este nodo). Esta tarea incluye la creación de recursos del nodo para ayuda e iconos, así como compiladores y editores de propiedades, si procede.
    3. Compruebe los errores en la lista de tareas. Se pueden generar, por ejemplo, si el nodo o sus nombres de terminal incluyen el carácter de espacio (no soportado en la Versión 5), o bien, si en el flujo se ha intercalado otro flujo migrado y la referencia no es correcta. Resuelva los errores corrigiendo los nombres o utilizando la opción de menú Localizar subflujo.
    4. Instale el código de ejecución para el nodo (archivo .lil) en los sistemas de intermediario adecuados. No es necesario que vuelva 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 modificados.

Conceptos relacionados
Flujos de mensajes
Funciones ESQL

Tareas relacionadas
Apertura de un flujo de mensajes existente
Definición del contenido del flujo de mensajes
Desarrollo de ESQL

Referencia relacionada
perspectiva Desarrollo de aplicaciones de intermediario
Editor ESQL
Nodos incorporados
Mandato mqsimigratemsgflows