You need to be aware of the following information about each message flow when you use the mqsimigratemsgflows command.
This helps you to identify and resolve references to the other flows and subflows, and to rename objects consistently. The migration uses the name of the flow rather than the UUID to link flows and subflows and to name the message flow file.
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) 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 could, in Version 2.1, have contained spaces.
When the flow is migrated, the original name is lost and only the translation is kept. As the promoted attribute can override several attributes the code must ensure that the original name corresponds 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 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 flow is shipped as a plug-in flow and another user flow promotes the property from the plug-in flow.
Flows and properties can contain names that are not valid in Version 5.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, the "!" is replaced with X0026. This is explained in the report file that is generated.
This transformation is deterministic. If a flow is migrated on another occasion, which 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 you must rename one of these flows or properties and re-export the flows. You are recommended to select a new name that does not contain a Unicode code point sequence ('Xnnnn') and to 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.
Version 2.1 node | Version 5.0 node |
---|---|
Compute | Compute |
Filter | Filter |
Database | Database |
DataDelete | Database |
DataInsert | Database |
DataUpdate | Database |
Extract | Compute |
Warehouse | Database |
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
an18530_ |