Migrating or importing message flows and message sets:
This topic contains advice for dealing with some common problems
that can arise when importing or migrating resources:
The mqsimigratemsgflows command
gives unexpected results
- Scenario: You have imported your Version 2.1 or Version
5.0 message flows into the workbench using
the mqsimigratemsgflows command,
but the results are not what you were expecting.
- Explanation: The mqsimigratemsgflows command
creates a report called mqsimigratemsgflows.report.txt in
the directory from which you ran the command (typically the /eclipse directory).
Read the report for details of the actions taken by the command.
Message flows that refer to a migrated user-defined node have connection
errors
- Scenario: After migration, all message flows that refer
to a migrated user-defined node have errors indicating that connections cannot
be made.
- Explanation: One possible cause is that the original user-defined
node had space characters as part of one or more terminal names. The
spaces are rendered as 'X20' erroneously.
- Solution: You can correct this by editing the
user-defined node .msgnode file. After migration, the .msgnode file
is in the same project where flows were migrated. Open the editor and correct
the terminal name. Ensure that the name is exactly as the broker node implementation
expects.
Message flows that have been migrated from Version 2.1 cannot
resolve subflows
- Scenario: A set of message flows has been migrated from Version 2.1 to Version 6.0 and
an error message is issued indicating that: Subflow message
flow name cannot be located.
- Explanation: The subflow in the message flow has not been
migrated correctly. The message flow was exported from Version 2.1 without
the subflow or it was exported into a different file to the subflow.
- Solution: Export everything from Version 2.1 into
one large export file, then migrate the export file to Version 6.0. Alternatively, if the subflow has been imported but the message flow
still shows the error, right-click the node that is causing the error and
click Locate subflow.
A broker has been migrated from Version 2.1 to Version 6.0 and some message flows are now stopped
- Scenario: A broker has been migrated from Version 2.1 to Version 6.0 and some message flows are now stopped
- Explanation: This error can be caused by invalid ESQL in
the deployed message flows that was not detected on the Version 2.1 broker.
- Solution: Remove the affected message flows from the execution
group, then redeploy the message flows. This provides more information
about the error so that you can resolve it.
After migration, message flows cannot locate a user-defined node
- Scenario: After migration, message flows cannot locate a
user-defined node.
- Explanation: One possible cause is that the flows do not
have the correct reference internally to a user-defined node.
- Solution: Invoke the Locate subflow pop-up
menu from the node that cannot be located. Using the Browse dialog box, locate
the user-defined node (which is in the same project as migrated flows). The message flow should now link to the user-defined node correctly
and the task list entry is removed when the flow is saved.
Deployment of message flows fails when you migrate them from Version 2.1 to Version 6.0
- Scenario: After migration from Version 2.1 to Version 6.0, the deployment of message flows fails
and a BIP2493 error message is displayed.
- Solution: Modify the ESQL so that it references a list rather
than a scalar value. A list is denoted by an empty set of square brackets
("[ ]"), as in the example:
InputRoot.XMl.Field1[]
Warnings are displayed for message flows that you have imported from Version 2.1 to Version 6.0
- Scenario: Warning messages are displayed for message flows
that you have imported from Version 2.1 to Version 6.0, such as Unresolvable message
field reference Body.RootTag.ID.
- Explanation: Version 6.0 warns
of any field reference that it cannot resolve. These warnings do not cause
any problems with deploying or running the message flows.
- Solution: You can remove a large number of warning messages
by performing the following steps:
- Reference any MRM message sets in the message flow projects Property pane.
This removes any warnings for messages that are defined in the message sets.
Run the Database Definition File wizard
to define all the databases that are used by the message flows.
The mqsimigratemsgsets command
gives unexpected results
- Scenario: You have imported your Version 2.1 or Version
5.0 message sets into the workbench using
the mqsimigratemsgsets command,
but the results are not what you were expecting.
- Explanation: The mqsimigratemsgsets command
creates a report called mqsimigratemsgsets.report.txt in
the directory from which you ran the command (typically the /eclipse directory). Read the report for details of the actions taken by the command.
You get import problems with imported message sets
- Scenario: Your message set works with Version 2.1,
but when you import it into WebSphere
Message Broker Version
6.0,
you get import problems or task list errors.
- Explanation: Within Version 2.1,
message sets were checked at several different levels. A message set was not
checked completely until it was deployed to a broker. If your Version 2.1 message
set was never deployed to a broker, the checks will not have been completed,
and as a result you might not have been informed about problems with the message
set. WebSphere
Message Broker Version
6.0 ensures that message sets
are checked completely whenever they are saved. This ensures that you are
informed about problems with the message sets as soon as possible. As a result, Version 2.1 message sets might contain errors that
are reported as soon as you import the message sets into WebSphere
Message Broker Version
6.0.
- Solution: Fix the problems using either Version 2.1,
remembering to deploy the message set to be sure that the checks are complete,
or WebSphere
Message Broker Version
6.0.