You can migrate the message flows that you have created in your Version 2.1 product (WebSphere MQ Event Broker, WebSphere MQ Integrator Broker, or WebSphere MQ Integrator) and use them in WebSphere Business Integration Message Broker Version 5.0.
(If you are migrating from WebSphere MQ Event Broker Version 2.1, all information in this topic that refers to user-defined plug-ins and ESQL does not apply: these facilities are not available on WebSphere MQ Event Broker Version 2.1.)
You might want to change the message flows that you migrate to take advantage of the new nodes and features that are available. For example, you might want to replace a user-defined node that receives web services requests with the built-in HTTPInput node. 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 and user-defined nodes 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:
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.
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.
Check the
ESQL default compatibility level in the ESQL editor preferences page. The
default value for this option is 5.0, which results in runtime ESQL code generated
at 5.0 level when you add a message flow to a bar file. This code is incompatible
with version 2.1 brokers. If you want the bar file to include version 2.0
runtime ESQL, you must reset the editor preference. If you do so, you cannot
include version 5.0 enhancements in the ESQL code, but you can deploy the
flows to both version 2.1 and version 5.0 brokers. See the ESQL editor for
further details.
You do not have to repeat the whole export and import process.
Because ESQL and mappings are handled in a different way in Version 5.0, the migration process replaces some of the 2.1 nodes with different 5.0 nodes. The replaced nodes are shown in the following table. The ESQL associated with each node is created as a module with a default name, and the node property set to the name of that module.
Version 2.1 node | Version 5.0 node |
---|---|
Compute | Compute |
Filter | Filter |
Database | Database |
DataDelete | Database |
DataInsert | Database |
DataUpdate | Database |
Extract | Compute |
Warehouse | Database |
Related concepts
Message flows
ESQL functions
Related tasks
Opening an existing message flow
Defining message flow content
Developing ESQL
Related reference
Broker Application Development perspective
ESQL editor
Built-in nodes
mqsimigratemsgflows command
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac02355_ |