Acerca del ejemplo Petición síncrona IMS

El ejemplo Petición síncrona IMS Synchronous utiliza el nodo IMSRequest. Para obtener una visión general de cómo funciona y cómo está configurado este nodo, consulte IBM Information Management System (IMS) en la documentación de WebSphere Message Broker.

El ejemplo utiliza la transacción DSPALLI (Display All Invoices - Mostrar todas las facturas) que es una transacción de ejemplo de IMS que se instala generalmente en un sistema IMS. Consulte al administrador del sistema si está instalada antes de intentar utilizar este ejemplo. La transacción DSPALLI se puede configurar para que ejecute un programa REXX (DFSSAM07) o un programa COBOL (DFSSAM7) para recuperar detalles acerca de las facturas. Aunque estos programas realizan la misma función y generan los mismos datos lógicos, tienen formatos físicos diferentes en la conexión, por ejemplo, campos de tamaño diferentes y segmentos adicionales. De forma predeterminada, DSPALLI se configura para que utilice REXX. Puede cambiare DSPALLI para que utilice COBOL, pero también debe compilar y enlazar el programa COBOL ya que no se entrega incorporado previamente. Este ejemplo funciona con ambos programas. Utilice la versión REXX para comenzar y para comprender cómo diseñar los flujos de mensajes que utilizan el nodo de petición. No obstante, la versión COBOL se ejecuta con más rapidez que la versión REXX.

El flujo de ejemplo muestra cómo se puede diseñar un flujo de mensajes WebSphere Message Broker para que interactúe con un sistema IMS. Es importante tener en cuenta los siguientes dos elementos durante la interacción con IMS: Es importante comprender la diferencia entre estos dos elementos debido a que el mensaje IMS propiamente dicho no contiene simplemente datos a procesar sino también información estructural acerca del tamaño de los datos (los datos LLZZ al principio de cada segmento del mensaje) y los metadatos acerca de cómo se han de procesar los datos (el nombre de la transacción o del mandato es la primera parte de los datos). Para obtener una explicación de la estructura de estos mensajes, consulte Sistema de gestión de información de IBM (IMS).

El nodo IMSRequest proporciona conectividad con IMS Connect y contiene la opción de la modalidad de confirmar y de nivel de sincronización bajo las que se ejecuta la transacción. En el ejemplo, estas propiedades se establecen en los valores predeterminados: la modalidad de confirmación es send_then_commit y el nivel de sincronización es confirm. Estos valores se utilizan generalmente cuando se realiza una petición síncrona. El nodo espera recibir un árbol de mensajes que se puede serializar en un mensaje IMS teniendo ya establecido LLZZ y direcciona la corriente de bits de respuesta desde IMS al analizador que se ha configurado en el separador Análisis de mensaje de respuesta del nodo Request.

Estructuras de mensajes que utiliza DSPALLI

La transacción DSPALLI que se utiliza en este ejemplo requiere un mensaje de entrada de un solo segmento y crea un mensaje de salida de varios segmentos. El número de mensajes que se generan en la salida puede variar dependiendo del proceso del programa. Cuando se utiliza la versión REXX del programa, un mensaje de ejecución correcta tiene cinco segmentos al principio del mensaje que forman una cabecera y un segmento por factura visualizada. La versión COBOL tiene tres segmentos seguidos de las facturas. Puede diferenciar entre los dos formatos debido a que el tercer segmento del formato REXX no tiene datos y el formato COBOL contiene datos. La información de este tema sólo hace referencia a la versión COBOL, a menos que se especifique la versión REXX, debido a que la mayor parte de las aplicaciones se escriben en COBOL y no en REXX, y debido a que WebSphere Message Broker da soporte a la importación de libros de copia COBOL, lo que facilita el desarrollo del conjunto de mensajes necesario. Cuando se produce un error, sólo existe un mensaje en la respuesta de DSPALLI, el cual contiene la causa del error.

Las estructuras COBOL de la versión COBOL están contenidas en el programa SRC DFSSAM7. Las estructuras se definen aquí para cada segmento que utiliza el programa. Los tres segmentos principales que utiliza este ejemplo son:

Las estructuras de datos de los otros segmentos también existen en este programa pero son estructuras de cabecera que no son relevantes para este ejemplo y, por lo tanto, no es necesario importarlas. Estos segmentos pueden permanecer sin analizar, simplemente como LL más el resto de los datos.

El segmento TERM-IN-AREA es similar a muchos otros segmentos de entrada de transacciones a los que la transacción les añade un prefijo:

006010 01 TERM-IN-AREA.                                               00350000
006020 02 CHAR-COUNT PICTURE S99 COMPUTATIONAL. 00360000
006030 02 FILLER PICTURE S99 COMPUTATIONAL. 00370000
006040 02 TRANS-CODE PICTURE X(7). 00380000
006050 02 MESSAGE-TEXT-START PICTURE X(125). 00380000

Las estructuras clave son:

El mensaje de salida de ejecución correcta consta de tres secciones de cabecera y de una sección detallada repetitiva:

El ejemplo analiza únicamente la sección de detalles y deja las secciones de cabecera sin analizar. La sección siguiente, Construcción de un conjunto de mensajes MRM para DSPALLI, muestra cómo se puede realizar este análisis en MRM. El ejemplo siguiente muestra algunas de las primeras líneas del segmento DETAIL-OUT. Para ver la estructura completa, consulte DFSSAM7.
010010 01 DETAIL-OUT.                                                 00900000
010020 02 DO-CHAR-CNT PICTURE S99 VALUE +84 COMP. 00910000
010030 02 FILLER PICTURE S99 VALUE +0 COMP. 00920000
010050 02 DO-LINE-CNT PICTURE Z9. 00930000
010055 02 FILLER PICTURE X VALUE '.'. 00940000
010060 02 FILLER PICTURE XX VALUE SPACES. 00950000
Las estructuras clave son: El segmento final que el ejemplo utiliza es REJECT-MESSAGE, que ocurre cuando la transacción tiene un problema para obtener los detalles de la factura (generalmente debido a un número de pieza no válido):
015010 01 REJECT-MESSAGE.                                              01450000
015020 02 REJ-CHAR-CNT PICTURE S99 COMPUTATIONAL. 01460000
015030 02 FILLER PICTURE S99 COMPUTATIONAL VALUE +0. 01470000
015050 02 FILLER PICTURE X(8) VALUE '.PART = '. 01480000
015060 02 REJ-PN PICTURE X(16) VALUE SPACES. 01490000
015070 02 REJECT-REASON PICTURE X(110). 01500000
Las estructuras clave son:

Construcción de un conjunto de mensajes para DSPALLI

Todas las estructuras de datos que no requiere DSPALLI están contenidas en el programa DFSSAM7. El primer paso de la construcción de un conjunto de mensajes MRM es importar las estructuras necesarias en un conjunto de mensajes utilizando el importador COBOL. Los pasos son:

  1. Crear un conjunto de mensajes nuevo con un formato físico binario denominado COBOL.
  2. Expandir el nuevo conjunto de mensajes, pulsando con el botón derecho del ratón la carpeta Definición de mensaje y pulse Nuevo > Archivo de definición de mensajes desde > Archivo COBOL.
  3. Examine para encontrar el archivo DFSSAM7.cbl (que se puede obtener desde el propio sistema o se puede extraer desde DFSSAM7).
  4. Pulse Siguiente para visualizar la pantalla Selección de estructura y mensaje. Añada las tres estructuras TERM-IN-AREA, DETAIL-OUT y REJECT-MESSAGE a la sección Estructuras importadas.
  5. Seleccione los recuadros de selección junto a TERM-IN-AREA y REJECT-MESSAGE, de modo que se creen los tipos de mensajes para estos elementos. DETAIL-OUT no es un tipo de mensaje propiamente dicho sino que únicamente se trata de una parte del mensaje de respuesta. No cambie ninguna otra opción.
  6. Pulse Siguiente y luego pulse Finalizar. Se crea una nueva definición de mensaje DSPALLI que contiene dos tipos de mensajes: msg_TERMINAREA y msg_TERMINAREA.
La transacción DSPALLI puede devolver varias estructuras basándose en lo que sucede en el programa, por ejemplo, si se produce un error. Para manejar esta situación, en primer lugar, el ejemplo analiza la respuesta con una estructura general, que se divide en segmentos, luego vuelve a analizarla con la estructura correcta cuando ha identificado la estructura que se ha de utilizar. Para crear la estructura de finalidad general (que se puede utilizar para cualquier respuesta de una transacción IMS), realice los pasos siguientes:
  1. Abra la DSPALLI de la definición del mensaje en el editor, pulse con el botón derecho Mensajes y pulse Añadir mensaje.
  2. Asigne el nombre msg_IMSMessage al nuevo mensaje.
  3. Pulse con el botón derecho del ratón Tipos y luego pulse Añadir tipo complejo.
  4. Asigne al tipo el nombre segmentType.
  5. Añada un elemento nuevo denominado IMSSegment a msg_IMSMessage de tipo segment. Asegúrese de que su valor de Máx apariciones sea -1 (ilimitado).
  6. Añada dos elementos locales al tipo: uno llamado LL y el otro llamado ZZdata. El campo LL debe tener un tipo de datos de int y el campo ZZdata debe tener un tipo de datos de string.
    Estructura de IMSMessage
  7. Seleccione el campo ZZdata y cambie de Visión general a Propiedades.
  8. Cambie la representación física COBOL de Longitud a Referencia de longitud.
  9. Establezca el campo Referencia de longitud en LL.
  10. Seleccione Referencia de longitud incluida ya que el campo LL tiene la longitud de todo el segmento incluido LL y ZZ. Formato físico del mensaje IMS

Ahora puede utilizar el tipo de mensaje msg_IMSMessage para analizar cualquier mensaje de respuesta IMS en segmentos individuales (pero no analice los segmentos propiamente dichos). El ejemplo utiliza este tipo de mensaje para volver a analizar la respuesta desde el sistema IMS y luego, basándose en el número y el tamaño de los segmentos, volver a analizarlo con otro tipo de mensaje.

El tipo de mensaje de error msg_REJECTMESSAGE ya se ha definido para manejar mensajes rechazados. El último tipo de mensaje necesario es el tipo de mensaje de ejecución correcta, que contiene todos los segmentos DETAIL-OUT:

  1. Abra la DSPALLI de la definición del mensaje en el editor, pulse con el botón derecho Mensajes y pulse Añadir mensaje.
  2. Asigne el nombre msg_COBOLRESPONSE al nuevo tipo de mensaje.
  3. Añada dos elementos al nuevo tipo: uno denominado IMSSegment de tipo segmentType y otro denominado msg_DETAILOUT de tipo DETAILOUT.
  4. IMSSegment debe tener un valor para Mín apariciones y para Máx apariciones de 3 (para los tres segmentos de cabecera que no se analizan).
  5. El segmento msg_DETAILOUT debe tener un valor para Mín apariciones de 0 y un valor para Máx apariciones de ilimitado (-1). Estructura de datos de la respuesta COBOL

Se han creado todas las otras estructuras de datos necesarias. El flujo de mensajes de ejemplo muestra cómo se pueden utilizar estas estructuras para correlacionar los documentos XML en peticiones IMS y luego analizar las respuestas IMS, que se pueden volver a correlacionar en documentos XML.

Cómo funciona el flujo de mensajes

La función básica del ejemplo es tomar un mensaje XML de una cola WebSphere MQ, transformarlo en una petición IMS, ejecutar la transacción en IMS y volver a dar formato a la respuesta como un mensaje XML en una cola WebSphere. El diagrama siguiente muestra el aspecto del flujo de mensajes:

Flujo de mensajes de petición IMS

El proceso nodo por nodo se describe en la lista siguiente:

  1. El nodo MQInput toma el mensaje de la cola IMS_SYNC_REQUEST_IN1 y lo analiza con una analizador XML.
  2. El nodo InputMapping correlaciona la estructura XML en msg_TERMINAREA. El nodo también calcula el valor LL, que no se puede generar automáticamente por tipo de mensaje.
  3. El nodo SaveMQMD Compute guarda MQMD de modo que los identificadores de mensaje y los identificadores de correlación quedan guardados. (Este nodo se puede omitir si está utilizando otros transportes o si los identificadores de mensaje y los identificadores de correlación no son necesarios en el mensaje de respuesta).
  4. El nodo IMSRequest serializa los datos y los envía a IMS para que se ejecuten. El nodo analiza la corriente de bits de devolución utilizando el tipo de mensaje genérico msg_IMSMessage, que divide la corriente de bits en segmentos individuales.
  5. El nodo Filter Reject? cuenta el número de segmentos: si hay un segmento, la respuesta es un error; si hay más de uno, es correcto.
  6. El subflujo ProcessSuccessReponse hace que se vuelva a analizar la corriente de bits utilizando el formato msg_COBOLRESPONSE y la correlaciona para crear un formato XML.
  7. El subflujo ProcessRejectResponse hace que se vuelva a analizar la corriente de bits utilizando el tipo de mensaje msg_REJECTMESSAGE y lo correlaciona con una respuesta XML.
  8. El nodo Compute RestoreMQMD añade la MQMD original.
  9. El nodo MQOutput coloca el mensaje XML en la cola IMS_SYNC_REQUEST_OUT1.
La parte más importante del flujo de mensajes es el análisis del mensaje de respuesta. Este análisis se complica por el hecho que las transacciones IMS no presentan un tipo fuerte y pueden devolver cualquier número o combinación de segmentos. El flujo maneja esta situación analizando en primer lugar la respuesta con un tipo de mensaje de segmento genérico, que funciona para todo lo que el nodo IMSRequest puede devolver, a continuación, mediante la lógica de un nodo Filter (o cualquier otro nodo de direccionamiento) direcciona el mensaje a un proceso que se puede volver a analizar con un tipo bien conocido. Aquí se puede utilizar la lógica general con cualquier transacción IMS, siempre que las definiciones de segmentos se puedan importar (o construir manualmente) y existan datos en los segmentos que ayuden a identificar el tipo de mensaje a utilizar. El flujo de mensajes utiliza los nodos ResetContentDescriptor para volver a analizar, pero la repetición del análisis sólo se puede realizar utilizando sentencias ESQL.

Cómo funciona un flujo de mensajes con la versión REXX

La descripción anterior hace referencia en gran parte a COBOL. El flujo de mensajes también funciona con la versión REXX del programa debido a que la versión REXX tiene el mismo mensaje de entrada que el programa COBOL. La diferencia principal está en el mensaje de respuesta. Las dos diferencias principales entre los mensajes de respuesta son:

Por tanto, el ejemplo necesita dos formatos de respuesta: msg_COBOLRESPONSE y msg_REXXRESPONSE. La diferencia principal entre estos formatos es que la versión REXX tiene cinco segmentos de cabecera antes del segmento de detalles. El segmento de detalles es el mismo pero se ha añadido un nuevo formato físico REXX que maneja los diferentes tipos de datos. Cuando se analiza la respuesta REXX, se utiliza el tipo de mensaje msg_REXXRESPONSE con el formato REXX.

Volver a la página inicial del ejemplo