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:
- La conexión e interacción con IMS Connect
- La construcción del mensaje IMS que se utiliza para dirigir una transacción IMS
(o mandato)
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:
- TERM-IN-AREA. El segmento de entrada que contiene el nombre de la transacción y los datos que se han de procesar.
- DETAIL-OUT. El segmento que se repite para cada factura y que contiene los detalles de cada factura.
- REJECT-MESSAGE. El segmento que se utiliza para devolver un mensaje de error cuando la transacción no se ejecuta correctamente.
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:
- CHAR-COUNT: El campo LL. El programa puede asignar cualquier nombre a este campo (en este caso, CHAR-COUNT) y el tipo de datos siempre es S99.
- FILLER: El campo ZZ. El programa no utiliza nunca este campo pero debe incluir el espacio que utiliza el campo en la corriente de bits.
En este caso, el programa lo ha identificado como un campo de relleno.
- TRANS-CODE: La transacción que se ha ejecutado para invocar este programa. Las reglas estándar indican que este campo es el tamaño del código de la transacción más un carácter para un espacio a menos que la transacción contenga ocho caracteres. En el caso de DISAPPI, el campo tiene el tamaño de la transacción sin un espacio. Por lo tanto, MESSAGE-TEXT-START debe comenzar por un espacio.
- MESSAGE-TEXT-START: Los datos de entrada, que tienen una longitud de 125 bytes. Los diferentes programas pueden tener un tamaño diferente para este campo. El tamaño máximo es de
32 KB. Al construir una definición de mensaje en el MRM, puede establecer
la propiedad Unidades de longitud en
Fin de la corriente de bits,
en lugar de establecer un valor específico para la longitud de este campo.
El mensaje de salida de ejecución correcta consta de tres secciones de cabecera y de una sección detallada repetitiva:
- HEADER-1-AREA
- HEADER-2-AREA
- HEADER-3-AREA
- DETAIL-OUT
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:
- DO-CHAR-CNT: El campo LL. No existe ningún convenio de denominación para este campo.
Este es un segmento de tamaño de campo y, por lo tanto, siempre tiene un tamaño de 84, lo que simplifica la construcción de un tipo de mensaje que diseña este formato.
- FILLER: Se utiliza el primer relleno para los datos ZZ. Los otros rellenos existen para dar formato. Muchas transacciones no tienen rellenos de formato debido a que confían en MFS para el formato para un terminal final. El nodo IMSRequest siempre maneja los datos de la transacción que MFS no ha convertido.
- DO-LINE-CNT: Los datos de la primera aplicación DETAIL-OUT estructura. Este campo proporciona le número de línea del segmento de detalle (pueden existir varias instancias de este segmento).
- ...: y así para todos los demás campos de datos de la aplicación.
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:
- REJ-CHAR-CNT: El campo LL.
- FILLER: Se utiliza el primer relleno para los datos ZZ. Los otros rellenos existen para dar formato. Muchas transacciones no tienen rellenos de formato debido a que confían en MFS para el formato para un terminal final. El nodo IMSRequest siempre maneja los datos de la transacción que MFS no ha convertido.
- REJ-PN: El código de razón de la anomalía. Este campo no lo utiliza el ejemplo.
- REJECT-REASON: El texto de la razón del rechazo.
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:
- Crear un conjunto de mensajes nuevo con un formato físico binario denominado COBOL.
- 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.
- Examine para encontrar el archivo DFSSAM7.cbl (que se puede obtener desde el propio sistema o se puede extraer desde DFSSAM7).
- 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.
- 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.
- 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:
- Abra la DSPALLI de la definición del mensaje en el editor, pulse con el botón derecho Mensajes y pulse Añadir mensaje.
- Asigne el nombre msg_IMSMessage al nuevo mensaje.
- Pulse con el botón derecho del ratón Tipos y luego pulse Añadir tipo complejo.
- Asigne al tipo el nombre segmentType.
- 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).
- 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.

- Seleccione el campo ZZdata y cambie de Visión general a Propiedades.
- Cambie la representación física COBOL de Longitud a Referencia de longitud.
- Establezca el campo Referencia de longitud en LL.
- Seleccione Referencia de longitud incluida ya que el campo LL tiene la longitud de todo el segmento incluido LL y ZZ.
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:
- Abra la DSPALLI de la definición del mensaje en el editor, pulse con el botón derecho Mensajes y pulse Añadir mensaje.
- Asigne el nombre
msg_COBOLRESPONSE al nuevo tipo de mensaje.
- Añada dos elementos al nuevo tipo: uno denominado IMSSegment de tipo
segmentType y otro denominado msg_DETAILOUT de tipo
DETAILOUT.
- 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).
- El segmento msg_DETAILOUT debe tener un valor para
Mín apariciones de 0 y
un valor para Máx apariciones
de ilimitado (-1).
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:

El proceso nodo por nodo se describe en la lista siguiente:
- El nodo MQInput toma el mensaje de la cola
IMS_SYNC_REQUEST_IN1 y lo analiza con una analizador XML.
- 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.
- 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).
- 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.
- 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.
- 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.
- 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.
- El nodo Compute RestoreMQMD añade la MQMD original.
- 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:
- REXX tiene cinco segmentos de cabecera antes de la sección de detalles.
- La versión REXX tiene formatos físicos diferentes para cada uno de los campos de datos (pero el mismo número y tipo de campos).
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