Use the mqsimigratemsgflows command to migrate message flows from Version 2.1 to Version 6.0. It is not necessary to use this command when migrating from Version 5.0 to Version 6.0.
When a user-defined node or a promoted property has a Property editor, the XML attribute is type="MyType" and there exists a class <package>MyTypePropertyEditor.class.
The Property editors themselves (written in Java code) are not migrated. However, if new ones are created (using the Eclipse SWT toolkit) with the same class name, the new editor is found and loaded without the need to change the migrated flow.
In Version 2.1, when a promoted property is created through the drag-and-drop process, the property name (xmi.label) is set to be the translation of the attribute name. The original attribute name must not contain spaces otherwise it is rejected by the broker. However, promoted attributes are never sent to the broker, so they might have contained spaces in Version 2.1.
When the message flow is migrated, the original name is lost and only the translation is kept. The promoted attribute can override several attributes, so the original name must correspond to the translated name.
The solution is to generate a suitable attribute name by replacing spaces or other offending characters with the unicode representation. The propertyName attribute of the propertyDescriptor is set to key=Property.<the translated attribute name>. The UI returns <the translated attribute name>.
However, migrated message flows have not retained the attribute system name, only the translated name. It is therefore difficult or impossible to locate the original attribute. For example, a DataSource promoted property is not shown as translated if the message flow is shipped as a plug-in flow and another user flow promotes the property from the plug-in flow.
Message flows and properties can contain names that are not valid in Version 6.0. If this situation arises, the following transformation occurs. Each offending character is replaced with a series of characters representing its unicode code point. For example, an exclamation mark ("!") is replaced with X0026. This is explained in the report file that is generated.
This transformation is deterministic. If a message flow is migrated on another occasion, and the message flow refers to a flow with a character that is not valid, both names are transformed in the same way.
These transformations do not result in conflicting names except in extremely rare circumstances. A conflict might occur because a Unicode code point sequence occurs in a name precisely where the corresponding character occurs in another name, which is otherwise identical. In this case, rename one of these message flows or properties and re-export the flows. Select a new name that does not contain a Unicode code point sequence ('Xnnnn') and rename the message flow in the Control Center before you migrate. Never rename a .msgflow file in the file system; always use the Control Center or the workbench to perform renaming tasks.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
an18530_ |