This topic explains what you need to do with each message
set file when you migrate.
You need to be aware of the following
information about each message set file when you use the mqsimigratemsgsets command.
You are strongly recommended not to modify the message set file manually between export from Version 2.1 and import into WebSphere Business Integration Message Broker Version 5.0 because the results are not guaranteed. This can be indicated by the presence of the following warning and error messages in the report (BIP0141, BIP0142 through BIP0157, BIP0163)
Note that the type composition of 'simpleUnorderedSet' is dropped from the model in WebSphere Business Integration Message Broker Version 5.0. If type content is 'closed' then it is replaced by composition 'all' with a BIP0191 warning message, otherwise by composition 'unorderedSet' with a BIP0192 warning message.
Type
composition of 'empty' is replaced by an empty 'sequence'
with a BIP0193 warning message.
Any unreferenced value constraint is discarded with a BIP0158, BIP0159 or BIP0160 warning message
For each .mrp file encountered, a new message set project is created with a name derived from the message set name and level in Version 2.1. The utility does this by adding a suffix to the message set name for all Level values other than "1". This process restores the one-to-one mapping and enables the broker to locate just one message set given the name.
For example, a Version 2.1 message set with name "SWIFT" and Level "1", migrates in Version 5.0 to the message set name "SWIFT", whereas a Version 2.1 message set with name "SWIFT" and Level "2" migrates in Version 5.0 to "SWIFT_2"
A single message definition .mxsd file is created within the message set with the same name as the message set and in the default (notarget) namespace, unless the -part parameter is present.
In Version 2.1 all elements and compound types were global.
In Version 5.0 xsd:elements and xsd:complex types can
be global or local. When you migrate a Version 2.1 message set, you will probably
find that many elements and compound types that were global in Version 2.1
have been converted into local xsd:elements and xsd:complex
types in Version 5.0, according to the rules stated above.
This means that the valid content of a compound type can be any object in the message set, subject to Type composition property rules. Typically in this case the compound type has not been modelled with any explicit content.
This can cause the mqsimigratemsgsets command to incorrectly deduce that certain elements are to be made local rather than global. If you use Open defined and you find that after migration a runtime validation error BIP5372E occurs, when previously it did not, you should rerun the mqsimigratemsgsets command with the -g option.
In Version 2.1 a prefixed identifier was intended to indicate that an element was actually local. However, it is possible that an element with a prefixed identifier is actually used in more than one compound type, making it global. If this is so, a global xsd:element is created according to the preceding rules. A BIP0195 warning message is also issued, because this is a misuse of prefixed identifiers, and can result in duplicate global xsd:elements being created. For example, A^X and B^X, but both are used more than once, resulting in two global xsd:elements with name X.
If duplicates are created, you can run the command again specifying the -pl parameter. This forces all referenced elements with prefixed identifiers to be created as local xsd:elements.
Embedded simple types within compound types need special treatment, because the schema model is unable to cope with this construct. As embedded simple types are deprecated, you are strongly recommended to replace the use of embedded simple types by taking advantage of the 'mixed' attribute of the containing xsd:complex type.
Embedded simple types were introduced primarily to model a complex XML element that contained data values interspersed between child elements. Each such data value was explicitly modelled by an embedded simple type, which acted as a placeholder for the value and also supplied its simple type.
In XML schema, there is no exact equivalent. The closest is use of the 'mixed' attribute of xsd:complexType. However, this only says that text can appear before and between (or between) child elements. It implies nothing about the location or data type of the text.
To retain this
semantic, a schema extension is introduced, called the Embedded Simple Type.
This is simply an unnamed local xsd:element of the appropriate
simple type. The type itself is a restriction of the real underlying xsd:simple
type, with a special name (commencing ComIbmMrm_Anon).
This situation produces a BIP0161 warning message and needs special treatment, because the schema model is unable to cope with this 'compound' construct. As compound elements are deprecated, you are strongly recommended to replace the use of compound elements by the use of normal elements that reference the global xsd:complexType described in 1 below, and take advantage of the 'mixed' attribute.
Such compound types were introduced primarily to model a complex XML element that contained a data value as well as child elements. So an element of such a complex type has both complex content like a normal complex element, but also has a value like a simple element (the MRM base type information).
In XML schema, there is no exact equivalent. The closest is use of the 'mixed' attribute of the xsd:complexType. But this just says that text can appear before and between (or between) child elements. It implies nothing about the location or data type of the text.
A compound element is created for each element that referenced the compound type. Note that this can be done only if the element was itself a member of another compound type.
The combination of these two things means that meaningful use of such compound types within a message is preserved, as the MRM base type information is lost only when it was never actively used in a message.
The special data types created by the situations described in the preceding sections, commencing ComIbmMrm are defined in an XML schema called .wmq21.mxsd, which is included in each message definition file created by the mqsimigratemsgsets command.
MRM type | Schema type |
---|---|
BINARY | xsd:hexBinary |
BOOLEAN | xsd:boolean |
DECIMAL | xsd:decimal |
DATETIME | xsd:dateTime (also, see following table) |
FLOAT | xsd:float |
INTEGER | xsd:int |
STRING | xsd:string |
MRM DATETIME Date Template | Schema type |
---|---|
CCYY-MM-DDThh:mm:ss.s | xsd:dateTime |
CCYY-MM-DD | xsd:date |
CCYY-MM | xsd:gYearMonth |
CCYY | xsd:gYear |
--MM-DD | xsd:gMonthDay |
--MM | xsd:gMonth |
---DD | xsd:gDay |
Thh:mm:ss.s | xsd:time |
If the Date Template is not in the preceding list, the DATETIME is mapped to either an xsd:time or an xsd:dateTime with a BIP0175 warning message, depending on whether or not the Date Template had just a time component. However, note that this mapping can cause errors to appear in the task list after the import.
If the element concerned also had Version 2.1 Default Value, Min Inclusive, Max Inclusive, or Enumeration value constraints, the values for these do not match the lexical space for an xsd:time or xsd:dateTime, and so fail validation. These must be corrected manually using the editor.
The same task list error also appears for any Version 2.1 DATETIME type that supplied a Default Value, Min Inclusive, Max Inclusive, or Enumeration value constraint where the value was not fully specified. For example, Date Template 'CCYY-MM', Enumeration '2003' was allowed in Version 2.1 as it was interpreted as '2003-01' at runtime. However, in the new model the value must match the lexical space of the simple type and so must include the '-01'.
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ad15750_ |