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 Business Integration Event Broker Version 5.0.

You might want to change the message flows that you migrate to take advantage of the new nodes and features that are available. For more information about changes in this release, see What's new?.

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 any existing message flow with the next flow that it finds of the same name without warning. Therefore you must be careful to avoid conflicts, and to ensure that the most recent version of a multiply-defined message flow is the last one to be migrated.

If you have multiple versions of the same message flow, and you use this as a subflow in other flows in the same migration directory, the results of the import 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 library 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 you have a workbench session active, you must 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 (see mqsimigratemsgflows command for full details of this command). When the command has completed:
    • The message flows contained in the export files in the specified directory have been imported into the specified message flow project. If the project already existed, 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. You are recommended to allow the command to create the message flow project for you.
    • Message flows and subflows have been created and their definitions stored in files named <flow_name>.msgflow.

      If you want to rename any of these message flows or nodes after import to conform to your local naming conventions, you must use the facilities provided by the workbench 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 that 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 5.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 made to the name is always the same.)
    • The success or failure of each resource migrated.
    • An indication of a subflow that cannot be located (its definition is not contained in any of export files, but it is included in one or more of the migrated message flows). If this occurs, find the missing subflow and import it into the appropriate project to resolve this error. If you cannot retrieve the missing subflow for any reason, recreate it with the original name. All affected flows can then link correctly to the new subflow.

      You do not have 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 created or updated by the migrate command (right-click the project and select Open Project). If the project is already open, right-click and select Refresh then Rebuild Project to ensure that the Navigator view reflects the new content. Rebuild also performs a validation of the message flow project contents.

Related concepts
Message flows

Related tasks
Opening an existing message flow
Defining message flow content

Related reference
Broker Application Development perspective
ESQL editor
Built-in nodes
mqsimigratemsgflows command