Migración de conjuntos de mensajes de la Versión 2.1

Para migrar 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.

Condiciones del mandato mqsimigratemsgsets

No modifique el archivo de conjunto de mensajes manualmente entre la exportación de la Versión 2.1 y la importación a WebSphere Message Broker Versión 6.0 porque esto genera errores, indicados por estos mensajes de aviso y error del informe: BIP0141, BIP0142 a BIP0157 y BIP0163.

Cada archivo de definición de mensajes nuevo .mxsd es un modelo de esquema XML anotado y cada artefacto del conjunto de mensajes se vuelve a crear y conserva las propiedades existentes en el nuevo modelo, con las excepciones siguientes:
  • El Nombre en el modelo de WebSphere Message Broker Versión 6.0 es el Identificador del modelo de la Versión 2.1. Si el objeto es un elemento con un identificador con prefijo, se elimina el prefijo, ya que el prefijo de la Versión 2.1 era un modo de indicar que este elemento era local.
  • Etiqueta, Descripción corta y Descripción larga e Historial se fusionan en una sola propiedad Documentación para WebSphere Message Broker Versión 6.0
  • Cada tipo compuesto se convierte en un tipo xsd:complexType y un xsd:group asociado en WebSphere Message Broker Versión 6.0.
    El xsd:complexType que se crea de este modo puede ser local o global. El valor por omisión es local, pero se convierte en global si se cumple cualquiera de las condiciones siguientes:
    • No hay ninguna referencia al tipo compuesto
    • El tipo compuesto tiene un tipo base MRM Versión 2.1.
    • Más de un elemento hacen referencia al tipo compuesto
    • Un mensaje está basado en el tipo compuesto
    • Se especifica el parámetro -g
    El xsd:group que se crea de este modo puede ser local o global. El valor por omisión es local, pero se convierte en global si se cumple cualquiera de las condiciones siguientes:
    • El tipo compuesto está directamente incorporado en otro tipo compuesto.
    • El tipo compuesto tiene un tipo base MRM de la Versión 2.1.
    • El tipo compuesto tiene una composición de tipo de la Versión 2.1 de simpleUnorderedSet y un contenido de tipo de la Versión 2.1 de closed.
    La composición de tipo de simpleUnorderedSet se ha eliminado del modelo en WebSphere Message Broker Versión 6.0.
    • Si el tipo de contenido es closed, se sustituye por la composición all con un mensaje de aviso BIP0191.
    • De lo contrario, se sustituye por la composición unorderedSet con un mensaje de aviso BIP0192.
    • La composición de tipo vacío se sustituye por una secuencia vacía con un mensaje de aviso BIP0193.

  • En los mensajes incorporados con Mín apariciones o Máx apariciones no igual a 1 se corrigen las apariciones a 1 con un mensaje de aviso BIP0162.
  • Cada elemento se convierte en un xsd:element. El xsd:element creado de este modo puede ser local o global, en función de los siguientes criterios aplicados en el orden especificado:
    1. Si el elemento no tiene ninguna referencia, es global.
    2. Si el elemento tiene identificador con prefijo y es miembro exactamente de un tipo compuesto, es local.
    3. Si el elemento tiene un identificador con prefijo y se especifica el parámetro -pl, es local.
    4. Si el elemento es de un tipo compuesto con un tipo base MRM de la Versión 2.1 es local.
    5. Si el elemento es miembro de más de un tipo compuesto, es global.
    6. Si se especifica el parámetro -g, es global.
    7. De lo contrario, el elemento es local.
    El tipo del xsd:element creado de este modo puede ser:
  • Las limitaciones de valor que pertenecen al elemento se procesan como se indica a continuación:
    • Una limitación de valor por omisión establece el atributo de valor por omisión de xsd:element.
    • Una limitación de nulo permitido establece el atributo de nulos permitidos de xsd:element.
    • Una limitación de plantilla de fecha cambia el xsd:simpleType de xsd:element. (Consulte Correlación de tipos simples MRM con tipos simples de esquema.)
    • Todas las demás limitan el xsd:simpleType de xsd:element mediante la aplicación de xsd:facets.

    Las limitaciones de valor sin referencia se descartan con un mensaje de aviso BIP0158, BIP0159 o BIP0160.

    Las limitaciones de valor que producen un xsd:facet no permitido no se migran, con un mensaje de aviso BIP0165.
    Nota: Sólo en el caso de elementos de tipo STRING, en lugar de ello se importan las limitaciones de valor inclusivaMín e inclusivaMáx como anotaciones ocultas para la documentación, porque no hay ningún xsd:facet equivalente.
  • Los calificadores de elemento se descartan con un mensaje de aviso BIP0167 único.
  • Cada mensaje se convierte en un mensaje y un xsd:element global asociado.
  • En un mensaje que ha utilizado calificadores de elemento se descarta la calificación con un mensaje de aviso BIP0166.
  • Se han eliminado del nuevo modelo algunas propiedades de formato físico que eran redundantes en Versión 2.1. Si se encuentra una de estas propiedades con un valor distinto del valor por omisión, se emite un mensaje de aviso BIP0164 (u otro más específico).
  • El valor por omisión Ventana de siglo de la propiedad de nivel de conjunto de mensajes se establecía siempre en 53 en la Versión 2.1. Dado que para el estándar de mensajería SWIFT esto es incorrecto, el valor por omisión para SWIFT sólo cambia a 80. Esto se refleja en un modelo importado.

Qué crea el mandato mqsimigratemsgsets

Para cada archivo .mrp encontrado, se crea un nuevo proyecto de conjunto de mensajes con un nombre derivado del nombre y nivel de conjunto de mensajes de la Versión 2.1. Este programa de utilidad realiza esta tarea añadiendo un sufijo al nombre de conjunto de mensaje 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 el Nivel 1 se migra en la 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 la Versión 6.0 a SWIFT_2.

En el nuevo proyecto se crean una carpeta de conjunto de mensajes y el archivo messageSet.mset asociado. Se aplican los puntos siguientes al contenido del conjunto de mensajes:
  • El nombre de carpeta de conjunto de mensajes es el mismo que el del nuevo proyecto
  • El identificador de conjunto de mensajes es el identificador del conjunto de mensajes original de la Versión 2.1
  • El conjunto de mensajes se crea especificando que no se soportan los espacios de nombres.
  • Todas las capas de formato físico se vuelven a crear en el nuevo conjunto de mensajes.
  • La capa de enlace de lenguaje COBOL se descarta con un mensaje de aviso BIP0174.
  • La capa de enlace de lenguaje C se descarta con un mensaje de aviso BIP0173.
  • Cualquier estado finalizado se descarta con un mensaje de aviso BIP0170.
  • Cualquier información de base se descarta con un mensaje de aviso BIP0172.
  • Cualquier indicación de la hora de congelación se descarta con un mensaje de aviso BIP0169. Tenga en cuenta que siempre recibirá este mensaje porque la operación de exportación de la Versión 2.1 congela el conjunto de mensajes.
Cada categoría de mensajes que se encuentra en el archivo .mrp hace que se cree un archivo .category nuevo. Nota:
  • Cada transacción se sustituye por la categoría de mensajes equivalente, que contiene todos los mensajes de la transacción.
  • Cada categoría de transacción se sustituye por la categoría de mensajes equivalente, que contiene todos los mensajes de todas las transacciones a las que hace referencia la categoría de transacción.

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.

Si se especifica -part, se pueden crear varios archivos .mxsd, si:
  • El número de mensajes, elementos y tipos compuestos del archivo excede de 1000 y
  • El archivo .mrp se puede particionar en subconjuntos completamente desunidos.

En la Versión 2.1, todos los elementos y tipos compuestos son globales. En la Versión 6.0, xsd:elements y xsd:complex types 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.

Existen dos razones por las que puede que desee alterar temporalmente este comportamiento:
  • Prefiere la organización de la Versión 2.1 para el conjunto de mensajes, en la que todos los objetos son globales. Si especifica el parámetro -g, esta organización se conservará mientras sea práctica.
  • Utiliza el tipo compuesto Contenido de tipo con un valor de Abierto definido.

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 se producía, vuelva a ejecutar el mandato mqsimigratemsgsets con el parámetro -g.

Identificadores con prefijo

En la Versión 2.1, un identificador con prefijo tenía la finalidad de indicar que un elemento era 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, ejecute el mandato mqsimigratemsgsets otra vez, especificando 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 .

Tipo simple incorporado

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, sustitúyalos 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 que estaban 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).

Tipo compuesto con un tipo base MRM

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, sustituya el uso de elementos compuestos por el uso de elementos normales que hagan referencia al xsd:complexType global, como se describe en el apartado 1 siguiente, y aproveche 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 sólo entre) elementos hijo. No implica nada sobre la ubicación o el tipo de datos del texto.

Puesto que no hay ningún equivalente exacto en el esquema XML, se han realizado los pasos siguientes:
  1. Se han creado un xsd:complexType global y un xsd:group global de la forma habitual. El xsd:complexType tiene establecido adicionalmente el atributo mixto y su contenido es sólo una referencia al xsd:group global. Esto modela el contenido complejo, pero pierde la información de tipo base de MRM.
  2. Se ha empezado a utilizar una extensión de esquema específica, el Elemento compuesto. Se trata de una amalgamación de un elemento complejo y un elemento simple. Se implementa en términos de esquema como un elemento con un tipo complejo anónimo, donde el contenido de dicho tipo es:
    • Un xsd:element local del tipo simple apropiado (para modelar la información de tipo base de MRM). El propio tipo es una restricción del tipo xsd:simple real subyacente, con un nombre especial (que empieza por ComIbmMrm_BaseValue).
    • Una referencia de grupo al xsd:group global creado en el punto 1 anterior.

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.

Correlación de tipos simples MRM con tipos simples de esquema

La correlación de tipos simples es la siguiente:
Tipo MRM Tipo de esquema
BINARY xsd:hexBinary
BOOLEAN xsd:boolean
DECIMAL xsd:decimal
DATETIME xsd:dateTime (consulte la tabla siguiente)
FLOAT xsd:float
INTEGER xsd:int
STRING xsd:string
Para el tipo DATETIME, la presencia de una limitación de valor de Plantilla de fecha cambia potencialmente la correlación de tipos simples como se indica a continuación:
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 Valor por omisión, Inclusiva Mín, Inclusiva Máx o Enumeración de la Versión 2.1, los valores de éstas no coincidirán con el espacio léxico de xsd:time o xsd:dateTime y, por consiguiente, la validación fallará. É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 por omisión, Inclusiva Mín, Inclusiva Máx o Enumeración donde no se ha especificado totalmente 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.

Conceptos relacionados
Conceptos de modelado de mensajes
Referencia relacionada
Mandato mqsimigratemsgsets
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
ad15750_