Para migrar los conjuntos de mensajes de la Versión 2.1 a la Versión 6.0 utilice el mandato mqsimigratemsgsets. No es necesario utilizar este mandato cuando efectúa la migración de la Versión 5.0 a la Versión 6.0.
No modifique manualmente el archivo de conjunto de mensajes entre la exportación de la Versión 2.1 y la importación a WebSphere Message Broker Versión 6.0 debido a que esto generaría errores, indicados por los siguientes mensajes de aviso y error en el informe: BIP0141, BIP0142 a BIP0157 y BIP0163.
Las limitaciones de valor sin referencia se descartan con un mensaje de aviso BIP0158, BIP0159 o BIP0160.
Para cada archivo .mrp encontrado, se crea un nuevo proyecto de conjunto de mensajes con un nombre derivado del nombre de conjunto de mensajes y del nivel Versión 2.1. El programa de utilidad realiza dicha acción añadiendo un sufijo al nombre de conjunto de mensajes para todos los valores de nivel distintos de "1". Este proceso restaura la correlación de uno a uno y permite al intermediario localizar sólo un conjunto de mensajes proporcionando el nombre.
Por ejemplo, un conjunto de mensajes de la Versión 2.1 con el nombre "SWIFT" y Nivel "1", se migra en Versión 6.0 al nombre de conjunto de mensajes "SWIFT", mientras que un conjunto mensajes de la Versión 2.1 con el nombre "SWIFT" y el Nivel "2" se migra en Versión 6.0 a "SWIFT_2"
Se crea un solo archivo .mxsd de definición de mensajes en el conjunto de mensajes con el mismo nombre que el conjunto de mensajes y en el espacio de nombres por omisión (notarget), a menos que exista el parámetro -part.
En la Versión 2.1, todos los elementos y tipos compuestos eran globales. En Versión 6.0, los tipos xsd:elements y xsd:complex pueden ser globales o locales. Cuando migra un conjunto de mensajes de la Versión 2.1, probablemente encontrará que muchos elementos y tipos compuestos que era globales en Versión 2.1 se han convertido a xsd:elements y xsd:complex types en Versión 6.0, según las normas indicadas anteriormente.
Esto significa que el contenido válido de un tipo compuesto puede ser cualquier objeto del conjunto de mensajes, sujeto a las normas de propiedad de Composición de tipo. Normalmente en este caso el tipo compuesto no se ha modelado con cualquier contenido explícito.
Esto puede hacer que el mandato mqsimigratemsgsets convierta de forma incorrecta algunos elementos en locales y no en globales. Si utiliza Abierto definido y, después de la migración, encuentra que se produce un error de validación de ejecución BIP5372E, cuando anteriormente no lo había encontrado, deberá volver a ejecutar el mandato mqsimigratemsgsets con la opción -g.
En la Versión 2.1, un identificador con prefijo tenía la finalidad de indicar que un elemento era en realidad local. Sin embargo, es posible que un elemento con un identificador con prefijo se utilice realmente en más de un tipo compuesto, convirtiéndolo en global. Si es así, se crea un xsd:element global de acuerdo con las normas anteriores También se emite un mensaje de aviso BIP0195, porque los identificadores con prefijo se están utilizando erróneamente y esto puede hacer que se creen xsd:elements globales duplicados. Por ejemplo, A^X y B^X, pero se están utilizando ambos más de una vez, lo que produce dos xsd:elements globales con el nombre X.
Si se crean duplicados, puede volver a ejecutar el mandato mqsimigratemsgsets y especificar el parámetro -pl. Esto obliga a que todos los elementos a los que se hace referencia con identificadores como prefijo se creen como xsd:elements locales .
Los tipos simples incorporados en tipos compuestos necesitan un trato especial porque el modelo de esquema no puede manejar esta construcción. Dado que los tipos simples incorporados se han dejado de utilizar, se recomienda encarecidamente sustituir la utilización de los tipos simples incorporados aprovechando el atributo 'mixto' del tipo xsd:complex que los contiene.
Los tipos simples incorporados se empezaron a utilizar principalmente para modelar un elemento XML complejo que contenía valores de datos entremezclados entre los elementos hijo. Cada valor de datos de este tipo lo modelaba explícitamente un tipo simple incorporado, que actuaba como marcador de posición para el valor y también proporcionaba el tipo simple.
En el esquema XML, no hay ningún equivalente exacto. Lo más parecido es el atributo 'mixto' de xsd:complexType. Sin embargo, esto sólo indica que el texto puede aparecer antes de o entre los elementos hijo. No implica nada sobre la ubicación o el tipo de datos del texto.
Para conservar esta semántica, se presenta una extensión de esquema, denominada Tipo simple incorporado. Se trata simplemente de un xsd:element local sin nombre del tipo simple apropiado. El propio tipo es una restricción del tipo xsd:simple real subyacente, con un nombre especial (que empieza por ComIbmMrm_Anon).
Esta situación produce un mensaje de aviso BIP0161 y necesita un trato especial, porque el modelo de esquema no puede manejar esta construcción 'compuesta'. Puesto que los elementos compuestos se han dejado de utilizar, se recomienda encarecidamente sustituir la utilización de los elementos compuestos por el uso de elementos normales que hacen referencia al xsd:complexType global descrito en el apartado 1 siguiente y aprovechar el atributo 'mixto'.
Estos tipos compuestos se empezaron a utilizar principalmente para modelar un elemento XML complejo que contenía un valor de datos así como elementos hijo. Por consiguiente, un elemento de un tipo complejo de este estilo tiene contenido complejo como un elemento complejo normal, pero también tiene un valor como un elemento simple (la información de tipo base de MRM).
En el esquema XML, no hay ningún equivalente exacto. Lo más parecido es utilizar el atributo 'mixto' de xsd:complexType. Pero esto sólo indica que el texto puede aparecer antes de y entre (o entre) elementos hijo. No implica nada sobre la ubicación o el tipo de datos del texto.
Se crea un elemento compuesto para cada elemento que hacía referencia al tipo compuesto. Tenga en cuenta que esto sólo se puede realizar si el propio elemento era miembro de otro tipo compuesto.
La combinación de estos dos puntos significa que se conserva la utilización significativa de dichos tipos compuestos en un mensaje, porque la información de tipo base de MRM sólo se pierde cuando no se había utilizado nunca activamente en un mensaje.
Los tipos de datos especiales creados por las situaciones descritas en las secciones anteriores, que empiezan por ComIbmMrm, se definen en un esquema XML denominado .wmq21.mxsd, que se incluye en cada archivo de definición de mensajes creado por el mandato mqsimigratemsgsets.
Tipo MRM | Tipo de esquema |
---|---|
BINARY | xsd:hexBinary |
BOOLEAN | xsd:boolean |
DECIMAL | xsd:decimal |
DATETIME | xsd:dateTime (vea también la tabla siguiente) |
FLOAT | xsd:float |
INTEGER | xsd:int |
STRING | xsd:string |
Plantilla de fecha MRM DATETIME | Tipo de esquema |
---|---|
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 |
Si la Plantilla de fecha no está en la lista anterior, DATETIME se correlaciona con xsd:time o xsd:dateTime con un mensaje de aviso BIP0175, en función de si la plantilla de fecha tenía solamente un componente de hora o no lo tenía. Sin embargo, tenga en cuenta que esta correlación puede hacer que aparezcan errores en la lista de tareas después de la importación.
Si el elemento implicado también tenía las limitaciones de valor de la Versión 2.1 Valor por omisión, InclusivaMín, InclusivaMáx o Enumeración, los valores de éstas no coincidirán con el espacio léxico de xsd:time o xsd:dateTime y, por consiguiente, fallarán la validación. Éstos se deberán corregir manualmente utilizando el editor.
El mismo error de lista de tareas también aparecerá para cualquier tipo DATETIME de la Versión 2.1 que haya proporcionado una limitación de valor de Valor por omisión, InclusivaMín, InclusivaMáx o Enumeración donde no se ha especificado completamente el valor. Por ejemplo, la plantilla de fecha 'CCYY-MM', Enumeración '2003' se permitía en la Versión 2.1 porque se interpretaba como '2003-01' en la ejecución. Sin embargo, en el modelo nuevo el valor debe coincidir con el espacio léxico del tipo simple y, por consiguiente, debe incluir '-01'.