Migrar un flujo de mensajes

Puede migrar los flujos de mensajes que ha creado en WebSphere MQ Event Broker Versión 2.1 y utilizarlos en WebSphere Event Broker Versión 6.0.

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.

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

      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.

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

  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.

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
Tareas relacionadas
Abrir un flujo de mensajes existente
Definir el contenido del flujo de mensajes
Referencia relacionada
Perspectiva de Desarrollo de aplicaciones de intermediario
Nodos incorporados
Mandato mqsimigratemsgflows
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009. Reservados todos los derechos.
Última actualización : 2009-02-16 14:30:22

ac02355_