Migración de un flujo de mensajes

Puede hacer una migración de los flujos de mensajes que ha creado en WebSphere MQ Event Broker versión 2.1 y utilizarlos en WebSphere Business Integration Event Broker versión 5.0.

Es posible que desee cambiar los flujos de mensajes que migra para aprovechar los nuevos nodos y las características que están disponibles. 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 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.

      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.

  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 y subflujo 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.

  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.

Conceptos relacionados
Flujos de mensajes

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

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