Modificaciones a los formatos de los mensajes de WebSphere MQ durante la mensajería y queuing (cola)

En este artículo se describen las diferencias de formato de los mensajes entre las distintas versiones de WebSphere MQ y se analizan las modificaciones a los mensajes de WebSphere MQ durante el proceso de queuing del mensaje. El artículo está dirigido a desarrolladores que trabajan con WebSphere MQ y desean comprender la evolución de los formatos de los mensajes de MQ y las modificaciones que se realizan a los mensajes a medida que atraviesan la infraestructura de WebSphere MQ.

Ya Xiao, Software Engineer, OMEGAMON XE messaging team, IBM

Photo of Ya XiaoYa Xiao trabaja en el equipo de mensajería OMEGAMON XE en el China Development Lab de IBM en Beijing. Desarrolla agentes que monitorean y configuran WebSphere MQ.



01-08-2011

Introducción

IBM®WebSphere® MQ es el middleware premiado de IBM para queuing y mensajería comercial. El queuing de mensajería es un método de comunicación de programa a programa en el cual las aplicaciones se comunican enviando y recuperando datos específicos de la aplicación en los mensajes a través de las colas sin necesidad de contar con una conexión estructurada de manera lógica, específica y privada. Un mensaje es simplemente una cadena de bytes significativa para las aplicaciones que la utilizan y una cola es un recipiente de mensajes.

En este artículo se describe la evolución de los formatos de los mensajes de WebSphere MQ y las modificaciones realizadas de manera automática a los mensajes por medio de WebSphere MQ durante el proceso de queuing del mensaje. Es necesario que usted tenga conocimientos sobre el desarrollo de aplicaciones basadas en WebSphere MQ.

Evolución del formato de los mensajes de WebSphere MQ

Un mensaje de WebSphere MQ tiene el formato típico "encabezado-cuerpo del mensaje". El encabezado y el cuerpo pueden variar en el contenido y concepto según la versión de WebSphere MQ. No obstante, desde la primera versión hasta WebSphere MQ V6 (desde ahora denominado simplemente V6), el formato de mensajes tuvo pocas modificaciones. Con el fin de incrementar la compatibilidad con las aplicaciones de Java Message Service (JMS), el formato de los mensajes se modificó de manera significativa en ™WebSphere MQ V7 (desde ahora, V7).

El formato de mensajes a través de WebSphere MQ V6

En V6, los dos componentes de los mensajes de WebSphere MQ eran:

  • Descriptor del mensaje (Encabezado del mensaje)
  • Datos de la aplicación (Cuerpo del mensaje)

La figura 1 muestra el formato de mensajes en V6:

Figura 1. Formato de mensajes en V6
Formato de mensajes en V6

Un descriptor de mensajes se asocia con todos los mensajes que se encuentran en un gestor de colas. Identifica el mensaje y contiene información de control, por ejemplo, el tipo de mensaje y su prioridad según lo indique la aplicación de envío. La sección de datos de la aplicación contiene todos los datos reales del mensaje (payload / carga útil) y cualquier encabezado adicional, por ejemplo, el encabezado de transmisión o el encabezado de información IMS. WebSphere MQ no impone restricción alguna sobre el contenido de los datos de la aplicación, excepto una extensión máxima, que varía entre 4 y 100 MB según la versión de WebSphere MQ. La extensión máxima del mensaje también se puede definir para un gestor de colas, un canal o una cola individual.

Los mensajes en diferentes versiones hasta la V6 tienen la misma estructura de composición, excepto que:

  • Los atributos del descriptor del mensaje se modificaron a partir de V5 – ver detalles a continuación.
  • Los tipos de encabezados adicionales que se colocan como prefijos a los datos del mensaje se enriquecieron. Por ejemplo, a partir de V5 se agregó la extensión del descriptor del Mensaje (MQMDE) y, a partir de V6, el Embedded PCF header (Encabezado PCF Incrustado) (MQEPH).

1. Descriptor del mensaje

El descriptor del mensaje se define por una estructura MQMD que contiene una cantidad de campos que proporcionan información sobre el mensaje. Las siguientes secciones describen en detalle dos de estos atributos.

  • Version (Versión)

    Existen dos versiones del descriptor del mensaje. A partir de V5, los mensajes se pueden segmentar o agrupar. Para esta nueva función, se necesitaron campos adicionales en el descriptor del mensaje para guardar la información necesaria para la segmentación y el agrupamiento. Esta estructura ampliada es V2, que es la versión actual del descriptor del mensaje. El descriptor del mensaje V2 es el mismo que V1, pero tiene campos adicionales definidos por una estructura MQMDE: GroupId, MsgSeqNumber, Offset, MsgFlags y OriginalLength.

    Otros gestores de colas que no soportan estas funciones (denominados gestores de colas V1) tratan la información adicional como datos. Un descriptor del mensaje V2 en general es equivalente a utilizar un descriptor del mensaje V1 y a colocar como prefijo los datos del mensaje con una estructura MQMDE. Los gestores de colas que dan soporte a la segmentación y agrupamiento se denominan gestores de colas V2. La figura 2 muestra la relación entre la MQMD de V1 y V2:

    Figura 2. Relación entre la MQMD de V1 y V2
    Relación entre la MQMD de V1 y V2
  • Format (Formato)

    Format es un nombre que el remitente del mensaje utiliza para indicar al receptor, la naturaleza de los datos de ese mensaje. El gestor de colas tiene una cantidad de formatos incorporados con nombres que comienzan con MQ, por ejemplo MQFMT_STRING. Format también se utiliza para indicar que hay un encabezado adicional (extensión). Por ejemplo, si el valor del campo Format de un descriptor del mensaje es MQFMT_CICS, indica que los datos del mensaje comienzan con el encabezado de información CICS MQCIH, seguido de los datos de carga útil. La naturaleza de los datos de carga útil se indica por medio del campo Format del encabezado MQCIH. La figura 3 muestra este uso de Format:

    Figura 3. Utilización de Format para indicar la naturaleza de los datos de un mensaje.
    Utilización de Format para indicar la naturaleza de los datos de un mensaje.

2. Datos de la aplicación

La sección datos de la aplicación contiene los datos reales enviados de un programa al otro y su contenido y estructura se definen por las aplicaciones que la utilizan. En general, los datos de la aplicación solamente contienen información que es significativa para las aplicaciones, ya que la información de control del descriptor del mensaje no es suficiente. No obstante, en determinadas circunstancias se necesita más información de control y se coloca como prefijo a los datos de carga útil en forma de encabezados adicionales, como se muestra más arriba, en la Figura 1. Los encabezados adicionales se pueden agregar por medio de las aplicaciones para un uso específico, por ejemplo, agregar un encabezado de información IMS (MQIIH) a los datos de aplicación cuando se envía un mensaje a un puente IMS. En algunas ocasiones, los encabezados se agregan también por medio de WebSphere MQ, según se describe a continuación.

La tabla 1 lista los encabezados definidos de WebSphere MQ que se pueden colocar como prefijos en los datos de la aplicación, con sus nombres de formato.

Tabla 1. Estructuras de encabezados adicionales definidas por WebSphere MQ
EncabezadoDescripción del EncabezadoNombre del formato
MQCIHEncabezado de información CICSMQFMT_CICS
MQDLHEncabezado con problemas de entregaMQFMT_DEAD_LETTER_HEADER
MQDHEncabezado de la lista de distribuciónMQFMT_DIST_HEADER
MQEPHEmbedded PCF header (Encabezado PCF incrustado)MQFMT_EMBEDDED_PCF
MQIIHEncabezado de información IMSMQFMT_IMS
MQMDEExtensión del descriptor del mensajeMQFMT_MD_EXTENSION
MQCFHEncabezado PCFMQFMT_ADMIN / MQFMT_EVENT / MQFMT_PCF
MQRMHEncabezado del mensaje de referenciaMQFMT_REF_MSG_HEADER
MQRFHEncabezado de formateoMQFMT_RF_HEADER
MQRFH2Normas y encabezado de formateo de la versión 2MQFMT_RF_HEADER_2
MQWIHEncabezado de información del trabajoMQFMT_WORK_INFO_HEADER
MQXQHEncabezado de cola de transmisiónMQFMT_XMIT_Q_HEADER

Los encabezados adicionales se pueden encadenar, es decir, los datos de la aplicación pueden contener de manera optativa uno o más encabezados antes que los datos de carga útil. Tomemos como ejemplo el mensaje de las aplicaciones publish/subscribe (publicar/suscribir) antes de WebSphere MQ V7 – los datos del mensaje pueden comenzar con los encabezados MQRFH1 y MQRFH2 juntos. Si se coloca más de un encabezado como prefijo a los datos de carga útil, se encadenan de la misma manera, como se muestra más arriba en el campo Format de la Figura 3.

Formato de mensajes en WebSphere MQ V7

WebSphere MQ V7 (desde ahora denominado V7) introdujo el concepto de propiedades del mensaje (de JMS) y, por lo tanto, los dos componentes de un mensaje WebSphere MQ se convierten en:

  • Propiedades del mensaje (Encabezado del mensaje)
  • Datos de la aplicación (Cuerpo del mensaje)

El formato de mensajes de V7 se muestra en la Figura 4, así como las correspondencias entre las propiedades del mensaje y el descriptor del mensaje:

Figura 4. Formato de mensajes desde V7
Formato de mensajes desde V7

1. Message Properties (Propiedades del mensaje)

Message Properties es ahora una nueva característica de V7 que forma parte de Message Queue Interface (Interfaz de cola de mensajes – MQI). Las nuevas llamadas de la función MQI se utilizan para configurar, preguntar y eliminar propiedades de los mensajes (MQSETMP, MQINQMP y MQDLTMP). También puede utilizar las propiedades del mensaje para incluir datos de negocios o para confirmar información sin tener que guardarla en los datos de la aplicación. La utilización de las propiedades del mensaje en WebSphere MQ imita el uso de las propiedades en JMS, que posibilitan configurar las propiedades en una aplicación JMS y recuperarlas en una aplicación WebSphere MQ de procedimiento o viceversa.

Las propiedades del mensaje sirven para cualquier mensaje en un gestor de colas WebSphere MQ y cada una consiste en un nombre textual y un valor de un tipo particular. El tamaño de las propiedades del mensaje no puede exceder la configuración MaxPropertiesLength para un gestor de colas. Las propiedades del mensaje no se consideran para la extensión del mensaje para la cola y el gestor de colas, pero sí se consideran para la extensión de las propiedades que percibe el gestor de colas. Existe un límite de extensión de 100 MB para las propiedades del mensaje, sin considerar el descriptor o la extensión del mensaje para cada mensaje.

2. Propiedades del mensaje representadas como MQRFH2

Las propiedades del mensaje se pueden representar como elementos MQRFH2. La figura 5 muestra la estructura de un encabezado MQRFH2:

Figura 5. Estructura del encabezado MQRFH2
Estructura del encabezado MQRFH2

La cadena ubicada en el campo NameValueData consiste en una carpeta única que contiene cero o más propiedades. El contenido de la carpeta es considerado como propiedades del mensaje si se incluye el elemento content=properties (contenido=propiedades) en la carpeta start tag. Si todas las carpetas del encabezado contienen propiedades, los campos del encabezado MQRFH2 se agregan a la extensión de las propiedades del mensaje y pertenecen a la sección de propiedades del mensaje. De lo contrario, los campos del encabezado se consideran en la extensión del mensaje y son parte de los datos de la aplicación. Por lo tanto, una aplicación puede colocar un mensaje con un buffer más grande que el valor de MaxMsgLength cuando el buffer incluye las propiedades.

3. Campos descriptores del mensaje como propiedades

La mayoría de los campos descriptores del mensaje, excepto StructId y Version, se pueden considerar propiedades. El nombre de la propiedad se construye agregando un prefijo al nombre del campo del descriptor del mensaje, como en el ejemplo Root.MQMD.Priority. Aquí, Priority es un campo del descriptor del mensaje. Los campos del descriptor del mensaje nunca se representan en un encabezado MQRFH2 como se hace con otras propiedades. Si los datos del mensaje comienzan con un MQMDE que tiene prioridad en el gestor de colas, entonces se puede acceder a los campos MQMDE utilizando la misma sintaxis que se describió anteriormente. En este caso, los campos MQMDE se tratan de manera lógica como parte del MQMD desde la perspectiva de las propiedades.

4. Mensaje que se dirige a una versión anterior

Cuando un mensaje se dirige a un gestor de colas anterior a V7, sus propiedades, excepto las del descriptor del mensaje, se tratan como datos del mensaje y se cuentan en la extensión del mensaje:

Figura 6. Relaciones correspondientes entre los mensajes en V7 y en V6
Relaciones correspondientes entre los mensajes en V7 y en V6

Por lo tanto, se debe aumentar el valor del atributo de canales MaxMsgLength que se dirige hacia un sistema anterior a V7 para compensar el posible envío de más datos para cada mensaje.

Modificaciones a los mensajes durante el queuing de mensajes

Mientras el mensaje viaja de un programa a otro a través de WebSphere MQ, se le pueden realizar modificaciones para transportarlo a su destino. En esta sección se analizan diferentes maneras en las que WebSphere MQ puede modificar un mensaje durante la transmisión. Los gestores de colas, los agentes de canal de mensajes u otras infraestructuras de WebSphere MQ realizan las modificaciones de manera automática, las cuales son transparentes a las aplicaciones.

Como usted ya sabe, un mensaje de WebSphere MQ se puede dividir en un encabezado de mensaje que contiene información de control y datos del mensaje que contienen los datos de carga útil. Un gestor de colas no modifica los datos de carga útil a menos que se realice una conversión de datos. En la mayoría de los casos, las modificaciones a los mensajes se hacen en la información de control (encabezados), por ejemplo se agregan encabezados adicionales o se modifican los existentes.

Agregar información adicional de control

En ciertas circunstancias, WebSphere MQ agrega información adicional de control a un mensaje colocando como prefijos encabezados adicionales a los datos del mensaje y modificando el campo Format del descriptor del mensaje. WebSphere MQ agrega información de encabezado a los mensajes en las cuatro situaciones siguientes:

Situación 1. Cuando un mensaje se coloca en una cola remota

Cuando un mensaje se coloca en una cola remota, WebSphere MQ agrega una estructura de encabezado de transmisión (MQXQH) al mensaje antes de colocarlo en la cola de transmisión. El encabezado de transmisión contiene el nombre de la cola de destino (RemoteQName) y del gestor de colas (RemoteQMgrName), es decir, la información de direccionamiento. Esta información se utiliza para rutear el mensaje a su destino correcto en la red. La Tabla 2 lista algunos campos principales en MQXQH:

Tabla 2. Campos principales en MQXQH
CampoDescripción
RemoteQNameNombre de la cola de destino
RemoteQMgrNameNombre de gestor de colas de destino
MsgDescDescriptor del mensaje original (Incrustado)

Además de la información de direccionamiento, se guarda un descriptor incrustado del mensaje (MsgDesc) dentro de la estructura MQXQH como parte de los datos del mensaje. Es el que vino con el envío original de la aplicación al finalizar el envío. El gestor de colas genera otro descriptor del mensaje cuando el mensaje se coloca en la cola de transmisión y se guarda separado de los datos del mensaje y se lo denomina descriptor de mensaje por separado. Por lo tanto, un mensaje que se encuentra en una cola de transmisión tiene dos descriptores del mensaje, como se muestra en la Figura 7:

Figura 7. Estructura de los mensajes que se encuentran en una cola de transmisión
Estructura de los mensajes que se encuentran en una cola de transmisión

El descriptor incrustado del mensaje siempre es una estructura V1 MQMD. Si el mensaje enviado por la aplicación no tiene valores predeterminados para uno o más de los campos V2 en MQMD, una estructura MQMDE sigue al MQXQH y, a su vez, es seguida por los datos del mensaje de la aplicación, como se muestra más arriba en la Figura 7.

Cuando el mensaje llegue a su cola de destino, se quitan el encabezado de transmisión y el descriptor del mensaje separado y el descriptor incrustado del mensaje se convierte en el único descriptor del mensaje. Ya no es parte de los datos del mensaje.

Situación 2. Cuando un gestor de colas no puede entregar un mensaje.

En este caso, WebSphere MQ agrega una estructura de encabezado con problemas de entrega (MQDLH) al mensaje y lo coloca en la cola con problemas de entrega (mensaje no entregado). También se modifica el campo Format del descriptor del mensaje (MQMD) para indicar que el mensaje contiene una estructura MQDLH. Esta estructura incluye el nombre de la cola de destino y el motivo por el cual el mensaje fue colocado en la cola con problemas de entrega. La Tabla 3 lista los campos principales en MQDLH:

Tabla 3. Campos principales en MQDLH
CampoDescripción
MotivoMotivo por el cual el mensaje llegó en la cola con problemas de entrega
DestQNameNombre de la cola original de destino
DestQMgrNameNombre del gestor de colas original de destino
FormatNombre del formato de los datos que siguen a MQDLH
PutApplTypeTipo de aplicación que envió el mensaje a la cola con problemas de entrega
PutApplNameNombre de la aplicación que envió el mensaje a la cola con problemas de entrega

Los gestores de colas, los agentes de canal de mensajes (MCAs) y las aplicaciones pueden enviar los mensajes a la cola con problemas de entrega. Todos los mensajes que se encuentran en esa cola, deben tener el prefijo MQDLH y los mensajes se pueden truncar si son demasiado extensos para esta cola debido a que se agregó el encabezado MQDLH.

Las aplicaciones que reciben mensajes de la cola con problemas de entrega deben verificar que los mensajes comiencen con una estructura MQDLH. La aplicación puede determinar si hay una estructura MQDLH, examinando el campo Format en el descriptor del mensaje. Si el campo tiene el valor MQFMT_DEAD_LETTER_HEADER, los datos del mensaje comienzan con una estructura MQDLH.

Situación 3. Cuando se envía un mensaje a colas de destinos múltiples

En este caso, WebSphere MQ agrega una estructura de encabezado de distribución (MQDH) al mensaje y lo coloca en la cola relevante de transmisión. Por lo tanto, los datos del mensaje de la aplicación se colocan como prefijo con las estructuras MQXQH y MQDH. MQDH describe los datos adicionales en un mensaje cuando ese mensaje es de la lista de distribución y está guardado en una cola de transmisión. Un mensaje de la lista de distribución es un mensaje enviado a colas de destinos múltiples. Los datos adicionales consisten en la estructura MQDH seguida por un conjunto de registros MQOR y un conjunto de registros MQPMR. La Tabla 4 lista los campos principales en MQDH:

Tabla 4. Campos principales en MQDH
CampoDescripción
StrucLengthExtensión de la estructura MQDH y los registros siguientes
FormatNombre del formato de los datos que sigue el conjunto de los registros MQPMR
PutMsgRecFieldsIndicadores de qué campos MQPMR están presentes.
RecsPresentCantidad de registros de objetos que están presentes
ObjectRecOffsetOffset del registro del primer objeto desde el comienzo de MQDH
PutMsgRecOffsetOffset del registro del mensaje que primero se envió desde el comienzo de MQDH

Los datos del mensaje de un mensaje de la lista de distribución en una cola de transmisión tiene la siguiente secuencia:

  • estructura MQXQH
  • estructura MQDH y conjuntos de registros MQOR y MQPMR
  • Datos del mensaje de la aplicación (datos de carga útil)

La estructura de un mensaje de la lista de distribución en una cola de transmisión se muestra en la Figura 8:

Figura 8. Estructura de los mensajes de la lista de distribución en una cola de transmisión
Estructura de los mensajes de la lista de distribución en una cola de transmisión

StrucLength es la cantidad de bytes que existen desde el comienzo de la estructura MQDH hasta comienzo de los datos del mensaje que sigue los conjuntos de los registros MQOR y MQPMR. ObjectRecOffset brinda el offset en bytes del primer registro del conjunto de los registros de los objetos de MQOR que contienen los nombres de las colas de destino. PutMsgRecOffset brinda el offset en bytes del primer registro del conjunto de los registros de envío del mensaje MQPMR, que contienen las propiedades del mensaje.

Situación 4. Cuando el mensaje es un segmento o un mensaje en un grupo

En esta situación, WebSphere MQ puede agregar una estructura de la del descriptor del mensaje (MQMDE).

La segmentación del mensaje puede ser transparente a las aplicaciones. Si está permitido, el gestor de colas segmenta un mensaje de gran tamaño cuando su espacio excede el de una cola. Si en la aplicación está utilizando un V1 MQMD, el gestor de colas agregará de manera automática una estructura MQMDE a los datos del mensaje. Como se mencionó anteriormente, la estructura MQMDE contiene los campos MQMD que existen en el V2 MQMD, pero no en el V1 MQMD, donde está guardada la información de segmentación y agrupamiento.

Modificaciones en los campos de encabezados existentes

Además de agregar encabezados adicionales a un mensaje, WebSphere MQ también puede alterar algunos campos específicos de encabezados existentes en un mensaje durante sus viajes entre las aplicaciones de envío y las de recepción:

1. Campo Format en todos los encabezados precedentes

Como ya se mencionó, WebSphere MQ agrega información del encabezado al mensaje en circunstancias específicas. Una vez que se agrega un encabezado adicional, el campo Format de la estructura de su encabezado precedente también se actualiza por medio de WebSphere MQ para indicar el tipo del encabezado nuevo. Por ejemplo, cuando WebSphere MQ agrega un encabezado de transmisión después dell descriptor del mensaje de un mensaje, el campo Format de MQMD se modifica a MQFMT_XMIT_Q_HEADER.

2. Campos que contienen información de direccionamiento en el encabezado de transmisión

Durante la intercomunicación (en WebSphere MQ, intercomunicación significa enviar mensajes de un gestor de colas al otro), cuando un gestor de colas pasa un mensaje, puede alterar la información de direccionamiento (RemoteQName, RemoteQMgrName) del encabezado de transmisión transmitido junto con el mensaje, si se utiliza un alias del gestor de colas.

Los mensajes que llegan del sistema adyacente contienen el nombre físico (después de la resolución del nombre) del gestor de colas de destino y de la cola del encabezado de transmisión. Si existe una definición de alias del gestor de colas que tiene el mismo nombre del gestor de colas que el referenciado en el encabezado de transmisión, entonces el gestor local de colas, a través del cual se pasa el mensaje, sobreescribe el campo RemoteQMgrName con el RQMNAME de esa definición de alias.

3. ReplyToQ, ReplyToQMgr en el descriptor del mensaje

En realidad, las modificaciones de estos dos campos se realizan antes de las aplicaciones coloquen un mensaje en una cola. Si una aplicación coloca un mensaje en una cola, proporcionando el nombre de un reply-to queue (ReplyToQ) para los mensajes de respuesta pero con el nombre del gestor de colas (ReplyToQMgr) en blanco, el gestor local de colas responde al nombre del gestor de colas que está en blanco verificando la existencia de una definición de una cola remota con el mismo nombre que el alias reply-to queue (reply-to queue alias):

  • Si no se halló ninguno, el gestor de colas coloca su propio nombre en el campo ReplyToQMgr del descriptor del mensaje con ReplyToQ sin modificaciones.
  • Si existe la definición, el gestor de colas extrae el nombre de la cola y los nombres de los gestores de cola de la definición y los coloca dentro de los campos reply-to del descriptor del mensaje -- es decir, reemplaza los valores de ReplyToQ y ReplyToQMgr.

4. Los campos de Contexto en el descriptor del mensaje.

La información de contexto del mensaje se guarda en los campos de contexto del descriptor del mensaje. Hay dos tipos de contexto del mensaje: contexto de identidad y contexto de origen. Se agrega un nuevo tipo de información de contexto en V7 para las propiedades del mensaje: contexto del usuario. La Tabla 5 lista los campos de contexto en el descriptor del mensaje:

Tabla 5. Los campos de contexto del descriptor del mensaje
Tipo de ContextoCampos y Descripción
Contexto de identidad

UserIdentifier: Identificador del usuario de la aplicación que originó el mensaje.

AccountingToken: Accounting token

ApplIdentityData: Datos de la aplicación que se relacionan con la identidad.

Contexto de origen

PutApplType: Tipo de aplicación que envió / ubicó el mensaje.

PutApplName: Nombre de la aplicación que envió / ubicó el mensaje.

PutDate: Fecha en que se envió el mensaje.

PutTime: Hora en que se envió el mensaje.

ApplOriginData: Datos de la aplicación que se relacionan con el origen.

Contexto del usuario

Cualquier propiedad que las aplicaciones identifican como contexto del usuario.

En general la mayoría de los campos del contexto de identidad y de origen son suministrados por el gestor de colas. Por supuesto, las aplicaciones que tienen la autoridad que corresponde pueden proporcionar su propio contexto:

  • La información del contexto de identidad especifica quién es el usuario de la aplicación que primero envió el mensaje a una cola. El gestor de colas completa los campos UserIdentifier y AccountingToken basados en el entorno en el cual se está ejecutando la operación.
  • La información del contexto de origen describe la aplicación que envió el mensaje a la cola en la cual se encuentra actualmente guardado el mensaje. En general el gestor de colas especifica los siguientes campos: PutApplType, PutApplName, PutDate, PutTime.
  • El contexto del usuario no es configurado por el gestor de colas de manera automática.

5. Campos de Segmentación/Agrupamiento en el descriptor del mensaje (V2)

Si está permitido, el gestor de colas segmenta un mensaje que es demasiado extenso para enviar en mensajes más pequeños. Mientras, el gestor de colas configura los siguientes campos de segmentación/agrupamiento del descriptor del mensaje si se trata de V2: GroupId, MsgSeqNumber, Offset, MsgFlags, OriginalLength. Como ya se mencionó, el gestor de colas agrega una estructura MQMDE si el descriptor del mensaje es V1.

Modificaciones causadas por la conversión de datos

Si los formatos de datos entre las aplicaciones de envío y de recepción difieren, es necesario realizar una conversión de datos. Como WebSphere MQ debe tener la capacidad de comprender los contenidos del descriptor del mensaje (MQMD), independientemente de la plataforma sobre la que se creó, el sistema convierte MQMD de manera automática. No obstante, para la sección de datos de la aplicación del mensaje, es un poco complicado:

  • Los datos que están en formatos definidos por WebSphere MQ (formatos builtin) -- Los formatos mencionados en la Tabla 1 constituyen un subconjunto de todos los formatos builtin. El gestor de colas puede convertir los datos del mensaje que se encuentran en estos formatos de manera automática de un conjunto de caracteres codificados a otro, siempre que ambos conjuntos de caracteres se relacionen con un lenguaje único o un grupo de lenguajes similares.
  • Los datos que se encuentran en formatos definidos por el usuario -- El gestor de colas no puede convertir datos en formatos definidos por el usuario. Las aplicaciones tienen que proporcionar una salida de conversión de datos para dichos formatos.

En resumen, solamente los datos del mensaje que se encuentran en formatos builtin se pueden convertir de manera automática por medio de WebSphere MQ cuando la conversión de datos es necesaria.

Conclusión

En este artículo se describió el formato de mensajes de WebSphere MQ y las modificaciones realizadas a los mensajes por WebSphere MQ durante el queuing de mensajes. Se mostró cómo los formatos de WebSphere MQ en diferentes versiones son muy diferentes en concepto, pero similares en composición, con una estructura de encabezado-cuerpo que presenta dos componentes:

  • Descriptor del mensaje y datos de la aplicación (hasta la versiónV6).
  • Propiedades del mensaje y datos de la aplicación (en V7).

WebSphere MQ puede modificar un mensaje viaja de una aplicación a otra de tres maneras:

  • Se pueden agregar encabezados adicionales (que incluyan más información de control).
  • Se pueden alterar los campos de los encabezados existentes en el mensaje.
  • Se puede realizar la conversión de datos.

Recursos

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere
ArticleID=469852
ArticleTitle=Modificaciones a los formatos de los mensajes de WebSphere MQ durante la mensajería y queuing (cola)
publish-date=08012011