Migrating a message flow

You can migrate the message flows that you have created in WebSphere MQ Event Broker Version 2.1 and use them in WebSphere Event Broker Version 6.0.

You might want to change the message flows that you migrate to take advantage of the new nodes and features that are available in Version 6.0.

You can migrate more than one message flow at one time if you want them to be defined in the same message flow project. You must migrate subflows with the message flows in which they are included to ensure consistent references.

If you have defined more than one message flow with the same name, or the message flow has been exported into more than one export file, the migration task overwrites, without warning, any existing message flow with the next flow that it finds of the same name. Therefore, be careful to avoid conflicts, and to ensure that the most recent version of a message flow that has been defined more than once is the last one that you migrate.

If you have multiple versions of the same message flow, which you use as a subflow in other flows in the same migration directory, the results of the import process are unpredictable.

To migrate a message flow:

  1. Before you uninstall Version 2.1, export the message flow or flows from the Control Center using the Version 2.1 tools (see the Version 2.1 documentation for detailed information).

    The migration process is most efficient when all referenced subflows are included in the same export file, therefore export all message flows that you want to migrate to a single message flow project into a single export file.

  2. Transfer the export file or files to the new system on which you are running the workbench.
    • Check that the directory in which you store these files does not contain any other files.
    • Store the files that you intend to import into a single message flow project in a separate directory and migrate each directory separately.
    • Make sure that you do not store any files in subdirectories of the project directory, because these files are ignored by the migrate command.
  3. If a workbench session is active, close it. You cannot run the migrate command if the workbench is running.
  4. At a command prompt, invoke the mqsimigratemsgflows command, specifying the new project name and the directory in which you stored the export files. When the command has completed:
    • The message flows that are contained in the export files in the specified directory are imported into the specified message flow project. If the project already exists, the additional message flows are included with current content, if any. If the project does not exist before you invoke the command, it is created for you. The command is more effective if it creates the message flow project for you.
    • Message flows and subflows are created and their definitions are stored in files named flow_name.msgflow.

      After you have imported them, if you want to rename any of these message flows or nodes to conform to your local naming conventions, use only the facilities that are provided by the workbench, in order to preserve consistency and integrity of all references. Do not rename any files within the file system.

  5. Check the report file mqsimigratemsgflows.report.txt, which is written to the directory from which you invoked the command. The command provides the following information:
    • The name of each message flow and subflow that has been migrated. If any of these resources had a name that is incompatible with Version 6.0, the command updates the name and all references to that name to ensure consistency. (If you migrate a resource with an invalid name more than once, the correction that is made to the name is always the same.)
    • The success or failure of each resource that is migrated.
    • An indication of a subflow that cannot be located (its definition is not contained in any of the export files, but it is included in one or more of the migrated message flows). If this problem occurs, find the missing subflow and import it into the appropriate project. If you cannot retrieve the missing subflow for any reason, re-create it with the original name. All affected flows can then link correctly to the new subflow.

      You do not need to repeat the whole export and import process.

  6. Start the workbench and switch to the Broker Application Development perspective.
  7. Open the message flow project that was created or updated by the migrate command.

    If the project is already open, right-click it and click Refresh, then Rebuild Project to ensure that the Broker Development view reflects the new content. Rebuild also performs a validation of the message flow project contents.

When you have migrated your resources, see the Version 2.1 post-migration tasks for information about tasks that you might want to perform after migration.
Related concepts
Message flows overview
Related tasks
Opening an existing message flow
Defining message flow content
Related reference
Broker Application Development perspective
Built-in nodes
mqsimigratemsgflows command