Rational Developer para System z, Versión 7.6

Formatos físicos para mensajes

Cada archivo de mensaje describe la estructura lógica de los mensajes y los formatos físicos que describen la apariencia exacta de la corriente de bits de mensaje durante la transmisión. En el dominio MRM, debe proporcionarse la información de formato físico, ya que indica exactamente al analizador cómo debe analizar la corriente de bits de los mensajes.

Visión general de los formatos físicos

Un mensaje puede interpretarse como un paquete de datos que se envía de un lugar a otro. El emisor y el receptor del mensaje deberán haberse puesto de acuerdo sobre la estructura del mensaje y sobre lo que significa cada campo del mensaje. Se trata de la estructura lógica independiente de la plataforma y del protocolo.

El emisor y el receptor también deberán haberse puesto de acuerdo sobre la representación física del mensaje, cómo se disponen físicamente los datos en el cable. Por ejemplo, si define un mensaje que transmite información sobre un débito de la cuenta bancaria de una persona, el mensaje puede representarse en diferentes formatos físicos (por ejemplo XML o una estructura fija, como puede ser un libro de copia COBOL). El significado y los datos son los mismos en ambos casos; sólo cambia el diseño físico.

En el dominio MRM, puede modelar diversas representaciones físicas diferentes utilizando formatos físicos con nombre.
  • Utilice el formato físico CWF (formato físico personalizado) para modelar mensajes de formato fijo de aplicaciones existentes escritas en C, COBOL, PL/I y otros lenguajes. Este soporte incluye la capacidad de crear un modelo de mensaje directamente de un archivo de cabecera C o un libro de copia COBOL.
  • Utilice el formato físico XML para modelar mensajes XML, incluidos los que utilizan espacios de nombres XML. Este soporte incluye la capacidad de crear un modelo de mensaje directamente de un archivo de esquema XML o DTD XML.
  • Utilice el formato físico TDS (Tagged Delimited String) para modelar mensajes de texto formateados, quizás con el contenido del campo identificado mediante códigos o separado con delimitadores o ambos. Este soporte es lo suficientemente amplio como para modelar estándares de la industria como, por ejemplo, SWIFT, EDIFACT y X12.
  • Utilice el formato DBCS cuando importe artefactos de terminal de host que contienen el campo G de doble byte, o los tipos de datos G o N, y necesite especificar el atributo NSymbol en el editor de definición de mensajes.
  • Utilice el formato BMS Terminal para anotar las propiedades adicionales de BMS que se necesitarán para el 3270 Link Bridge.
  • Utilice el formato Terminal para describir las características físicas de un terminal 3270.
  • Utilice el modelo CICSAdapter para alterar temporalmente las propiedades de mensaje antes de generar el código de tiempo de ejecución (consulte la sección Cómo alterar temporalmente el nombre predeterminado dado a un archivo de libro de copia generado).

Diferentes representaciones físicas

El ejemplo siguiente muestra cómo un mensaje lógico muy simple puede tener diferentes representaciones físicas.

El modelo lógico define la estructura y el orden del mensaje. En el ejemplo siguiente, los tres campos son enteros simples, donde C sigue a B, que sigue a A.
int A;
int B;
int C;
  • Una representación típica del formato físico personalizado para este mensaje lógico sería 12 bytes de datos, donde los campos A, B y C ocupan 4 bytes cada uno. Como alternativa, quizás A tiene 4 bytes de longitud, pero B y C sólo tienen 2 bytes de longitud. La información física exacta para cada campo del mensaje se proporciona como propiedades CWF.
  • Una representación XML típica de este modelo es la siguiente:

    <Msg><A><xxxxxxxx></A><B><xxxxxxxx></B><C>xxxxxxxx</C></Msg>

    donde xxxxxxxx es el valor del entero representado en forma de serie (XML sólo maneja series).

    Una representación alternativa podría ser:

    <Msg> A = "xxxxxxxx" B="xxxxxxxx" C="xxxxxxxx"</Msg>

    donde los valores de los enteros se almacenan como atributos XML y no como elementos XML. Especifique la representación XML exacta para cada campo del mensaje como propiedades XML.

  • TDS permite modelar varias representaciones diferentes. Cada entero puede ir precedido por un código para identificarlo y un delimitador para terminarlo, como se indica a continuación:

    {A_código:xxxxxxxx;B_código:xxxxxxxx;C_código:xxxxxxxx}

    Una alternativa podría basarse en los datos que se están ordenando, de modo que sólo debe especificarse el delimitador de terminación, como se indica a continuación:

    [xxxxxxxx;xxxxxxxx;xxxxxxxx]

    El régimen de identificación exacto se proporciona como propiedades TDS.

Esto demuestra que el modelo lógico no cambia. Permanece constante, independientemente de la representación física que elija modelar encima del mismo, utilizando el soporte de formato físico que proporciona el dominio MRM. El analizador MRM puede transformar el mensaje desde la representación física de entrada a cualquier número de representaciones de salida, en función de las capas de formato físico que se hayan definido.

Crear formatos físicos

Una vez que haya creado el conjunto de mensajes, puede crear formatos físicos. Para ello, utilice el editor de conjunto de mensajes. La próxima vez que guarde el archivo messageSet.sfmset, cualquier formato físico nuevo se añadirá a todos los objetos de todos los archivos de mensaje de ese conjunto de mensajes.

La próxima vez que edite un objeto de un archivo de mensaje, verá los formatos físicos del panel de la jerarquía de propiedades de la pestaña Propiedades. Si pulsa un formato físico de un objeto, aparecerá una hoja de propiedades donde podrá especificar la información para el formato físico de ese objeto.

Tenga en cuenta que no todos los objetos tienen propiedades en todos los formatos físicos. Por ejemplo:
  • Las propiedades CWF sólo se aplican a los elementos y propiedades locales, y a las referencias de elemento y atributo.
  • Los grupos y tipos complejos sólo tienen propiedades TDS.
  • Los mensajes sólo tienen propiedades XML.

Esto se debe a la diferente naturaleza de cada formato físico; estas diferencias se explican de forma más detallada en la sección correspondiente de cada formato físico.

No hay ningún límite para el número de formatos físicos que se pueden crear en un determinado conjunto de mensajes. Sin embargo, existen algunas recomendaciones que se aplican si se desean mezclar formatos físicos de diferentes tipos en el mismo conjunto de mensajes.

Para obtener más información, consulte la sección Conjuntos de mensajes. Los formatos físicos pueden suprimirse si ya no son necesarios.


Términos de uso | Comentarios

Este Information Center está basado en tecnología Eclipse. (http://www.eclipse.org)