Notas sobre la migración de conjuntos de mensajes

Este tema proporciona la información que debe conocer para realizar la migración de los conjuntos de mensajes a WebSphere Message Broker Versión 6.0. Contiene las siguientes secciones:

Si está utilizando el Kit de herramientas de Message Brokers Versión 5.1, sustituya todas las referencias en este tema a "Versión 5.0" por "Versión 5.1".

Migración desde 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 para convertir los archivos de exportación de conjunto de mensajes de la Versión 2.1 (.mrp) a los proyectos de conjunto de mensajes de la Versión 6.0. Antes de ejecutar el mandato, consulte el tema Migración de conjuntos de mensajes de la Versión 2.1, que proporciona notas detalladas sobre la operación de dicho mandato.

Migración desde la Versión 5.0

Para migrar conjuntos de mensajes de la Versión 5.0 a la Versión 6.0, no es necesario ningún mandato de migración. El Kit de herramientas de Message Brokers de la Versión 6.0 puede leer el contenido de un proyecto de conjunto de mensajes de la Versión 5.0, y se convierte automáticamente al formato de la Versión 6.0 cuando se modifica y guarda por primera vez.

Información general sobre la migración

La información siguientes es aplicable tanto si ha migrado de la Versión 2.1 como de la Versión 5.0.
  • La propiedad CWF Cuenta de repeticiones se ha sustituido por la propiedad lógica Máx apariciones, acercando el formato físico CWF a los formatos físicos TDS y XML, que ya utilizan Máx apariciones para determinar el número de repeticiones. Aparece un aviso en la vista Problemas del editor de mensajes, para cada elemento o grupo que tenía un valor establecido para CWF Cuenta de repeticiones. Pulse el botón derecho del ratón en el aviso y pulse Quick Fix para resolver este error.
    Nota: En la Versión 5.0, si la propiedad de CWF Cuenta de repeticiones no está establecida y Mín apariciones no es igual a Máx apariciones, se toma el valor uno como número de repeticiones. En la Versión 6.0, para el número de repeticiones se toma el valor de Máx apariciones. No es posible emitir un aviso para esta situación. Un modelo de mensaje de este tipo no lo crean los importadores COBOL o C, por lo que sólo puede producirse si ha creado un modelo de mensaje CWF utilizando el editor de mensajes de la Versión 5.0.
  • El formato físico TDS anterior a la Versión 6.0 incluía la identificación de mensaje incluido mediante Clave de mensaje. La técnica de la Clave de mensaje se ha sustituido por otra técnica denominada Identidad del mensaje. Aparece un aviso en la vista Problemas del editor de mensajes, para cada mensaje que tiene un valor de TDS Clave de mensaje, y para cada elemento o atributo que tiene la propiedad TDS Interpretar valor de elemento establecida en Clave de mensaje. Pulse el botón derecho del ratón en el aviso y pulse Quick Fix para resolver este error.

    Siga utilizando TDS Clave de mensaje si el mensaje va a desplegarse, en alguna ocasión, en un intermediario de la Versión 5.0 o Versión 2.1, porque estos intermediarios no soportan la técnica de Identidad del mensaje para la identificación de un mensaje incorporado.

  • La propiedad de formato físico TDS Patrón de datos ahora la valida el Kit de herramientas de Message Brokers para comprobar que es una expresión regular de esquema XML válida. Los errores aparecen en la vista Problemas del editor de mensajes, y debe corregirlos manualmente utilizando el editor. En particular, ha habido errores de especificación de esquema XML acerca del uso de caracteres de escape con metacaracteres, lo cual puede ocasionar errores de validación. Para corregir los errores, es posible que tenga que utilizar un carácter de escape para los caracteres de guión ("-") o llave ( "{" y "}"), utilizando el carácter de barra inclinada invertida ("\"); por ejemplo, "\{" o "\-". Si recibe este tipo de errores cuando utiliza un conjunto de mensajes proporcionado por IBM, póngase en contacto con IBM para obtener una versión corregida del conjunto de mensajes.
  • El valor por omisión o el valor fijo de un elemento o atributo, y los valores de enumeración de un tipo simple, ahora se comparan con las facetas de longitud, longitud máxima y longitud mínima del tipo simple, si se han proporcionado. Si un valor no satisface las facetas, aparece un error en la vista Problemas del editor de mensajes. Pulse el botón derecho del ratón en el error y pulse Quick Fix para resolverlo, si hay disponible un arreglo rápido. De lo contrario, corrija el problema manualmente utilizando el editor. Lo más probable es que este error se produzca si importa un libro de copias COBOL a un Kit de herramientas de Message Brokers Versión 5.0 Fixpack 2 o anterior.
  • Las propiedades CWF y TDS Codificación de nulo y Valor de codificación de nulo se han eliminado de los atributos locales, los atributos globales y las referencias de atributos. En el esquema XML, sólo los elementos pueden tener una propiedad Nulos permitidos, por tanto, un campo de datos que esté modelado como atributo no puede contener un valor de nulo. Si había especificado valores CWF o TDS Codificación de nulo para atributos en la Versión 5.0, se han ignorado.
  • La propiedad TDS Delimitador de elemento de repetición se ha eliminado de los atributos locales y las referencias de atributo. En el esquema XML, los atributos no se pueden repetir. Si había especificado valores TDS Delimitador de elemento de repetición para atributos en la Versión 5.0, se han ignorado.
  • Para un elemento o atributo con tipo simple xsd:gMonth, el valor por omisión para la propiedad CWF, XML y TDS Formato de fecha y hora es ahora "--MM". En la Versión 5.0, el valor por omisión es "--MM--". Esto se ha corregido para resolver un error de esquema XML.
  • Cuando está migrando, no tiene que volver a desplegar los conjuntos de mensajes porque los diccionarios de mensajes se actualizan en la base de datos de intermediario al formato de la Versión 6.0, mediante el mandato mqsimigratecomponents. Sin embargo, si no vuelve a desplegar un conjunto de mensajes y observa una excepción ParserException como, por ejemplo, "checked vector error" o "access violation", cuando utilice por primera vez un flujo de mensajes que use el conjunto de mensajes, tendrá que volver a desplegar el conjunto de mensajes. Esto puede suceder si el diccionario del mensaje contiene datos erróneos no detectados anteriormente. En la Versión 6.0, se comprueba el diccionario del mensaje la primera vez que se utiliza; en la Versión 2.1 y Versión 5.0, esto no se hacía.

Cambios de comportamiento en el analizador MRM

La información siguientes es aplicable tanto si ha migrado de la Versión 2.1 como de la Versión 5.0:
  • Formato físico XML. La Versión 6.0 ahora es sensible a los atributos xsi:type en el documento XML y modifica su funcionamiento de acuerdo con ellos. Los atributos xsi:type ya no se tratan como atributos autodefinidos, por lo que aparecen en el árbol del mensaje con el nombre ‘type’ en lugar de ‘@type’. Si la lógica de flujo de mensajes es sensible a los atributos xsi:type en el árbol del mensaje, cambie el flujo de mensajes para satisfacer el nuevo comportamiento. Para conservar la lógica anterior a la Versión 6.0 en sus flujos de mensajes, establezca la variable de entorno MQSI_IGNORE_XSI_TYPE en cualquier valor y se adoptará el funcionamiento anterior a la Versión 6.0.
  • Formato físico XML. La información de DOCTYPE en un documento XML no aparece en el árbol lógico del mensaje cuando se analiza, pero se mantiene del documento de entrada al documento de salida, porque MRM guarda una copia del DOCTYPE internamente. Antes de la Versión 6.0, esto era una copia exacta de la corriente de bits. En la Versión 6.0, el proceso de copia hace que se pierda cierto espacio en blanco de formato. Por ejemplo, la declaración de elemento en un DOCTYPE de entrada:
    <!ELEMENT e0 (e1|e2)+ >
    en la salida aparecerá así:
    <!ELEMENT e0 (e1|e2)+>
    El nuevo funcionamiento es coherente con la forma en que el formato físico XML procesa los espacios en blanco en todas las demás construcciones XML.
  • Formato físico TDS. Para un grupo con la propiedad lógica Composición establecida en Elección y la propiedad TDS Separación de elementos de datos establecida en Longitud fija, el analizador siempre supone que la longitud de los datos de elección es la del hijo más largo del grupo, y siempre leerá y escribirá ese número de caracteres. Asegúrese de que sus mensajes satisfacen esta condición, de lo contrario, el analizador tratará como parte de la elección, los datos que van detrás de ella. Antes de la Versión 6.0, el analizador no implementaba esta norma.
  • Formato físico TDS. Si la propiedad de elemento TDS Codificación de nulo está establecida en NullPadFill, sólo se actúa de acuerdo a este valor si la propiedad Longitud correspondiente se utiliza activamente al analizar o escribir. Antes de la Versión 6.0, se actuaba de acuerdo con NullPadFill tanto si se utilizaba activamente la propiedad Longitud como si no.
  • Formato físico TDS. La propiedad TDS Separación de elementos de datos está establecida en Todos los elementos delimitados o Elementos de longitud variable delimitados. Ahora, un elemento complejo siempre se trata como si tuviera una longitud variable, independientemente de su propio valor de Separación de elementos de datos. Esto significa que en la corriente de bits del mensaje, se espera un Delimitador entre el elemento complejo y cualquier elemento siguiente, y se espera un Delimitador de elemento de repetición entre todas las instancias de un elemento complejo, aunque el elemento complejo tenga una longitud fija. Antes de la Versión 6.0, el analizador no implementaba esta norma, y para Elementos de longitud variable delimitados, el autor no ponía delimitadores cuando se conocía la longitud del elemento complejo.
  • Formato físico TDS. La propiedad TDS Separación de elementos de datos está establecida en Utilizar patrón de datos. Si la expresión regular que se especifica para un patrón de datos devuelve una coincidencia de longitud cero, ahora esto se trata como un elemento que está presente con un valor de longitud cero. Antes de la Versión 6.0, una coincidencia de longitud cero se trataba como un elemento que se omitía.
  • Formato físico TDS. La propiedad TDS Separación de elementos de datos está establecida en Codificado delimitado. Un delimitador no pertinente que tiene lugar cuando ya no se tolera el último hijo del grupo en una corriente de bits y se produce una excepción de análisis. Antes de la Versión 6.0, el analizador no implementaba esta norma. Si esto es un problema, considere modelar el delimitador no pertinente utilizando la propiedad TDS Terminador de grupo.
  • Formato físico TDS. La propiedad TDS Separación de elementos de datos está establecida en Codificado delimitado. En la Versión 6.0, al analizar un grupo Codificado delimitado, el analizador intenta aceptar los grupos en los que los miembros parecen estar sin orden en la corriente de bits del mensaje, aunque la propiedad Composición del grupo esté establecida en Secuencia o Conjunto ordenado. Sin embargo, si el grupo contiene un mensaje incorporado o un elemento o grupo complejo que no se puede identificar a partir de la corriente de bits, todos los miembros del grupo deben aparecer en la corriente de bits en el mismo orden en que están definidos en el modelo. Si aparecen desordenados, el grupo no se analizará correctamente y el resultado será imprevisible. Un síntoma de esto es la aparición de elementos autodefinidos en el árbol del mensaje, ocasionada por no encontrar una coincidencia de un elemento en el modelo.

    Un ejemplo específico de esto es cuando el mensaje contiene un mensaje incorporado y utiliza la técnica de Clave del mensaje o Identidad del mensaje para identificar el mensaje incorporado. Si el elemento que está proporcionando el valor de la clave del mensaje o de la identidad del mensaje no coincide con el modelo, el analizador no sabrá si debe interpretar su valor como una clave del mensaje o una identidad del mensaje.

    Antes de la Versión 6.0, el analizador intentaba aceptar todos los grupos Codificado delimitado desordenados, con la consiguiente reducción de rendimiento. En la Versión 6.0, si esto es un problema, considere modelar el contenido desordenado del grupo como un grupo hijo incorporado con Composición establecido en Conjunto no ordenado.

    A partir de la corriente de bits se puede identificar un elemento o grupo complejo si esa corriente de bits proporciona un indicador de grupo, un patrón de datos o código, o si sus miembros hijo proporcionan un indicador de grupo, un patrón de datos o código.

    A pesar de su nombre, hay circunstancias en las que los miembros de un grupo Codificado delimitado no necesitan proporcionar un código; en concreto, si el miembro es un mensaje incorporado o un grupo o elemento complejo.

  • Formato físico TDS. La propiedad TDS Separación de elementos de datos está establecida en Longitud codificada. Al escribir, la salida de la longitud codificada es el número de caracteres en los datos, para que coincida con la interpretación al analizar. Antes de la Versión 6.0, la salida de la longitud codificada era el número de bytes en los datos, que no coincidía con la interpretación al analizar, si los datos no eran SBCS.
  • Formato físico TDS. Al escribir, si el número de repeticiones de un elemento o grupo es fijo en el modelo pero las apariciones reales en el árbol lógico de mensajes exceden el número de repeticiones, y la propiedad Separación de elementos de datos no es una de las separaciones "Codificadas", las apariciones sobrantes se eliminan y no aparecen en la salida. Antes de la Versión 6.0, las apariciones sobrantes aparecían en la salida. Si se espera que las repeticiones sobrantes aparezcan en la salida, especifique maxOccurs=-1 para indicar que el número de repeticiones es ilimitado.
  • Todos los formatos físicos. Al escribir campos dateTime a los que se ha asignado una propiedad Formato de I, el formato de salida depende del tipo lógico del campo, tal como se describe en Fecha y hora como datos de serie de caracteres. Antes de la Versión 6.0, el formato de salida era, incorrectamente, el formato completo aaaa-MM-dd'T'HH:mm:ssZZZ.
  • Se ha mejorado la validación de los mensajes de entrada y salida, para proporcionar una mayor detección de mensajes no válidos. Por lo tanto, en la Versión 6.0, es posible que un mensaje lleve el indicador no válido cuando, incorrectamente, no llevaba indicador alguno en versiones anteriores.
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
ah20250_