Resolving other problems when developing message flows
This topic contains advice for dealing with problems that can arise
when developing message flows, that are not covered in the specific
categories listed in "Resolving problems when developing message flows"
The values of your promoted properties are lost after editing
- Scenario: You edited a message flow using the Message Flow
editor, and the values of your promoted properties are lost.
- Explanation: The values of promoted properties for nodes
with more than a single subflow definition (that is, two identically named
subflows in the same project reference path) are lost if the flow is edited
and saved.
- Solution: To avoid this problem, ensure that each subflow
in your project has a different name.
The Message Flow editor experiences problems when opening a message
flow, and opens in error mode
- Scenario: You attempt to open an existing message flow in
the Message Flow editor and it opens in read-only error mode, displaying a
list of parsing or loading errors. The message flow is not open and a message
is displayed indicating that the message flow file is not valid.
- Explanation: The message flow file is unreadable or is corrupted,
and the Message Flow editor cannot render the model graphically.
- Solution: Contact IBM Customer
Support for assistance with the corrupted file.
You get an exception when saving changes to a .tblxmi file
- Scenario: You are using the Database Table editor
to make changes to a .tblxmi file, but you
repeatedly get exceptions when you try to save the changes.
- Explanation: When you make changes to a .tblxmi file
using the Database Table editor, the editor successfully saves the changes
for the first save only. Subsequent saves after additional changes fail with
an exception.
- Solution: To stop this from happening, close the
Database Table editor after each save, and reopen it when you want to continue
making changes.
You do not know when to use the MQeMbMsgObject object
- Scenario: You do not know when to use the MQeMbMsgObject
object rather than the base MQeMsgObject object.
- Explanation: Any messages from existing WebSphere MQ Everyplace applications
(which are of type MQeMsgObject, or a subclass) can pass through WebSphere Message Broker unchanged. WebSphere Message Broker cannot parse the contents of these
messages. However, the full representation of the data that has been dumped
is available within the broker. Do not operate on this data.
- Solution: If you need to parse or modify the data contained
within a WebSphere MQ Everyplace message, use an MQeMbMsgObject
object. This is similar to standard WebSphere MQ messages:
you can set fields such as correlation ID, and there is a field that can be
parsed using any WebSphere Message Broker parser.