Cómo decidir los nodos que utilizar

WebSphere Business Integration Message Broker incluye muchos nodos de proceso de mensajes que se pueden utilizar en los flujos de mensajes. También proporciona una interfaz que puede utilizar para definir sus propios nodos, denominados nodos definidos por el usuario.

Su decisión sobre los nodos que va a utilizar depende del proceso que realice en los mensajes. Los nodos incorporados se pueden dividir en varias categorías y se muestran en el área de trabajo agrupados por categorías (aunque esta agrupación no afecta a su funcionamiento). Los nodos definidos por el usuario también se pueden dividir en categorías. Las categorías son las siguientes:

De entrada y de salida
Los nodos de entrada y de salida definen puntos en el flujo de mensajes a los que los clientes envían mensajes (nodos de entrada como, por ejemplo, MQInput) y desde los que los clientes reciben mensajes (nodos de salida como, por ejemplo, MQOutput). Las aplicaciones cliente interactúan con estos nodos al transferir u obtener mensajes de los mismos. El nodo especifica el recurso de E/S como origen o destino de los mensajes. Aunque un flujo de mensajes debe incluir, como mínimo, un nodo de entrada, no es necesario que incluya un nodo de salida.
  • Si va a crear un flujo de mensajes que desea difundir a un intermediario, debe incluir, como mínimo, un nodo de entrada para recibir mensajes. (Si desea ver más información, consulte el apartado Utilización de más de un nodo de entrada). El nodo de entrada que elija depende del origen de los mensajes de entrada:
    MQInput
    Si el mensaje llega al intermediario en una cola de WebSphere MQ.
    MQeInput
    Si el mensaje llega al intermediario desde clientes de WebSphere MQ Everyplace.
    SCADAInput
    Si un dispositivo de telemetría envía los mensajes.
    HTTPInput
    Si un cliente de servicios web envía los mensajes.
    Real-timeInput o Real-timeOptimizedFlow
    Si una aplicación multidifusión o JMS envía los mensajes.
    Nodo de entrada definido por el usuario
    Si el origen de mensajes es un cliente o aplicación que utiliza un transporte o protocolo diferente.
    Nodo Input
    Si va a crear un flujo de mensajes que desea intercalar en otro flujo de mensajes (un subflujo) que no va a difundir como un flujo de mensajes autónomo, debe incluir, como mínimo, un nodo Input para recibir mensajes en el subflujo.

    Una instancia del nodo Input representa un terminal de entrada. Por ejemplo, si incluye una instancia del nodo Input, el icono de subflujo muestra un terminal de entrada que se puede conectar a otros nodos del flujo principal del mismo modo que se conecta cualquier otro nodo.

    Sólo puede difundir flujos de mensajes que tengan, como mínimo, un nodo de entrada. Si el flujo de mensajes no contiene ningún nodo de entrada, se impide que se pueda añadir al archivo de datos antiguos de intermediario. El nodo de entrada puede encontrarse en el flujo principal o en un flujo de mensajes intercalado en el flujo principal.
  • Si desea enviar los mensajes que crea el flujo de mensajes a una aplicación destino, puede incluir uno o más nodos de salida. El nodo de salida que elija depende del transporte a través del cual la aplicación destino espera recibir dichos mensajes:
    Publication
    Si desea distribuir los mensajes utilizando la red de publicación/suscripción para las aplicaciones suscritas al intermediario a través de todos los protocolos soportados. Un nodo Publication es un nodo de salida que utiliza destinos de salida que identifican los suscriptores cuyas suscripciones coinciden con las características del mensaje actual.
    MQOutput
    Si la aplicación destino espera recibir mensajes en una cola de WebSphere MQ, o bien, en la cola de respuestas de WebSphere MQ que se ha especificado en el MQMD de mensajes de entrada.
    MQReply
    Si la aplicación destino espera recibir mensajes en la cola de respuestas de WebSphere MQ que se ha especificado en el MQMD de mensajes de entrada.
    MQeOutput
    Si la aplicación destino espera recibir mensajes a través de WebSphere MQ Everyplace
    SCADAOutput
    Si el destino de los mensajes de salida es un dispositivo de telemetría, y el nodo Publication no es adecuado.
    HTTPReply
    Si los mensajes son para un cliente de servicios web.
    HTTPRequest
    Si el flujo de mensajes interactúa con un cliente de servicios web.
    Real-timeOptimizedFlow
    Si la aplicación destino es una aplicación de multidifusión o JMS.
    Nodo de salida definido por el usuario
    Si el destino es un cliente o aplicación que utiliza un transporte o protocolo diferente.

    El nodo UDPSend es un ejemplo de trabajo de un nodo definido por el usuario que proporciona esta función.

    Nodo Output
    Si va a crear un flujo de mensajes que desea intercalar en otro flujo de mensajes (un subflujo) que no va a difundir como un flujo de mensajes autónomo, debe incluir, como mínimo, un nodo Output para propagar mensajes a nodos subsiguientes que se hayan conectado al subflujo.

    Una instancia del nodo Output representa un terminal de salida. Por ejemplo, si ha incluido dos instancias del nodo Output, el icono de subflujo muestra dos terminales de salida que puede conectar a otros nodos del flujo principal del mismo modo que conecta cualquier otro nodo.

Manipulación, mejora y transformación de mensajes

Muchas empresas tienen aplicaciones que se han ido desarrollando a lo largo de varios años en sistemas diferentes, utilizando distintos lenguajes de programación y diferentes métodos de comunicación. Con WebSphere Business Integration Message Broker ya no es necesario que las aplicaciones comprendan estas diferencias, puesto que ofrece la posibilidad de configurar flujos de mensajes que transforman mensajes de un formato a otro.

Por ejemplo, los nombres del personal se mantienen en varios formatos en aplicaciones diferentes. El apellido en primer lugar o en último, con o sin las iniciales del nombre, en mayúsculas o en minúsculas: éstos son sólo algunos cambios. Puesto que puede configurar el flujo de mensajes de modo que conozca los requisitos de cada aplicación, cada mensaje se puede transformar al formato correcto sin modificar los aplicaciones de envío o de recepción.

Puede trabajar con el contenido del mensaje para actualizarlo de varios modos. Sus opciones pueden variar en función de si el mensaje debe manejar mensajes predefinidos (modelados) o mensajes autodefinidos (por ejemplo, XML), o ambos.

Un flujo de mensajes puede reconstruir completamente un mensaje, convertirlo de un formato a otro (si format significa orden de campos, orden de bytes o idioma, entre otros) eliminar contenido del mensaje o entrar datos específicos en el mismo. Por ejemplo, un nodo puede interactuar con una base de datos para recuperar información adicional o para almacenar una copia del mensaje (completo o una parte de éste) en la base de datos para el proceso fuera de línea.

En los ejemplos siguientes se muestra la importancia de la transformación de los mensajes:

  • Una aplicación de entrada de pedidos tiene un ID de componente en el cuerpo del mensaje, pero la aplicación de valores de su asociado lo espera en la cabecera del mensaje. El mensaje se dirige a un flujo de mensajes que conoce ambos formatos y, por consiguiente, puede volver a dar formato a la información, según sea necesario.
  • Una aplicación de entrada de datos crea mensajes que contienen información comercial de valores. Algunas aplicaciones que reciben este mensaje necesitan la información tal como se proporciona, pero otras necesitan que se añada información adicional al mensaje sobre la relación precio/beneficio (P/B). Los mensajes comerciales de valores se dirigen a un flujo de mensajes que pasa el mensaje sin modificaciones a algunos nodos de salida, pero calcula y añade información adicional para los demás. El flujo de mensajes lo lleva a cabo al consultar el precio actual de los valores en una base de datos, utiliza este valor y la información comercial del mensaje original para calcular el valor P/B antes de pasarlo al mensaje actualizado.

También puede crear flujos de mensajes que interactúen entre sí utilizando estos nodos. Aunque el funcionamiento por omisión de un flujo de mensajes no influye en el funcionamiento de otro flujo de mensajes, puede forzarlo si configura los flujos de mensajes para almacenar y recuperar información de un origen externo como, por ejemplo, una base de datos.

Compute
Puede manipular el contenido del mensaje, transformar el mensaje de algún modo e interactuar con una base de datos para modificar el contenido del mensaje o de la base de datos y pasar uno o más mensajes nuevos utilizando el nodo Compute. Puede utilizar este nodo para manipular mensajes autodefinidos y predefinidos.

Utilice el editor ESQL para crear un módulo ESQL, específico de este nodo, que contenga las sentencias que definen las acciones que deben llevarse a cabo en relación al mensaje o la base de datos. El código ESQL que desarrolla para utilizarlo en el nodo Compute no se debe usar en ningún otro tipo de nodo.

Puede controlar el modo de acceso de este nodo a la base de datos especificando la información de usuario y contraseña para el origen de datos que se especifica en la propiedad del nodo. En sistemas distribuidos, utilice el mandato mqsisetdbparms para inicializar y mantener estos valores.

En z/OS, utilice el ID de tarea iniciada del intermediario para acceder a la base de datos.

Si los requisitos de manipulación de mensajes son complejos, deben completarse dentro de un único nodo Compute. Algunos pocos nodos Compute más complejos se ejecutan mejor que muchos nodos más sencillos, puesto que el intermediario analiza el mensaje cuando entra en cada nodo Compute.

Mapping
Utilizando el nodo Mapping, puede crear un nuevo mensaje del mensaje de entrada correlacionando el contenido de elementos del mensaje de salida con elementos del mensaje de entrada, o bien, con contenido de la base de datos. También puede extraer partes del mensaje y, si lo desea, cambiar su contenido, para crear un nuevo mensaje de salida que sea una copia parcial del mensaje que ha recibido el nodo. El nodo Mapping sólo maneja mensajes predefinidos.

Puede controlar el modo de acceso de este nodo a la base de datos especificando la información de usuario y de contraseña para el origen de datos que se especifica en la propiedad del nodo. En sistemas distribuidos, utilice el mandato mqsisetdbparms para inicializar y mantener estos valores.

En z/OS, utilice el ID de tarea iniciada del intermediario para acceder a la base de datos.

Utilizando el editor de correlaciones, puede desarrollar correlaciones para realizar manipulaciones sencillas en mensajes predefinidos en el nodo Mapping. Las correlaciones que se desarrollan para utilizarlas en un nodo Mapping no se deben usar en ningún otro nodo.

Extract
Puede utilizar el nodo Extract para crear un nuevo mensaje de salida a partir de elementos especificados en el mensaje de entrada. Puede extraer partes del mensaje y, si lo desea, cambiar su contenido, para crear un nuevo mensaje de salida que sea una copia parcial del mensaje que ha recibido el nodo. El nodo Extract sólo maneja mensajes predefinidos.

Utilizando el editor de correlaciones, puede desarrollar correlaciones para realizar manipulaciones sencillas en mensajes predefinidos en el nodo Extract. Las correlaciones que se desarrollan para utilizarlas en un nodo Extract no se deben usar en ningún otro nodo.

Database
Utilice el nodo Database para interactuar con una base de datos que identifiquen las propiedades del nodo. El nodo Database maneja mensajes predefinidos y autodefinidos. Utilizando un editor ESQL, puede codificar funciones ESQL para actualizar el contenido de la base de datos del mensaje, insertar nueva información en la base de datos y suprimir información de la base de datos, que puede basarse en información del mensaje. El código ESQL que desarrolla para utilizarlo en el nodo Database no se debe usar en ningún otro tipo de nodo.

Este nodo proporciona una interfaz sumamente flexible con una gran variedad de funciones. También tiene propiedades que se pueden utilizar para controlar el modo en el que la interacción participa en las transacciones.

Puede controlar el modo de acceso de este nodo a la base de datos especificando la información de usuario y contraseña para el origen de datos que se especifica en la propiedad del nodo. En sistemas distribuidos, utilice el mandato mqsisetdbparms para inicializar y mantener estos valores.

En z/OS, utilice el ID de tarea iniciada del intermediario para acceder a la base de datos.

Sólo puede actualizar una base de datos desde este nodo; no puede actualizar el contenido de ningún mensaje. Si desea actualizar el contenido de los mensajes, utilice el nodo Compute o el nodo Mapping.

DataDelete, DataInsert, DataUpdate
Los nodos DataDelete, DataInsert y DataUpdate son formatos especializados del nodo Database que proporcionan una sola modalidad de interacción (supresión de una o más filas, inserción de una o más filas o actualización de una o más filas existentes, respectivamente). Los nodos DataDelete, DataInsert y DataUpdate sólo manejan mensajes predefinidos. Utilice el editor de correlaciones para desarrollar correlaciones que permitan ejecutar estas funciones. Las correlaciones que se desarrollan para estos nodos no se deben usar en ningún otro tipo de nodo. Estos nodos también permiten controlar las características transaccionales de las actualizaciones que se llevan a cabo.

Puede controlar el modo de acceso de estos nodos a la base de datos especificando la información de usuario y contraseña para el origen de datos que se especifica en la propiedad del nodo. En sistemas distribuidos, utilice el mandato mqsisetdbparms para inicializar y mantener estos valores.

En z/OS, utilice el ID de tarea iniciada del intermediario para acceder a la base de datos.

Sólo puede actualizar bases de datos desde este nodos: no puede actualizar el contenido de ningún mensaje. Si desea actualizar el contenido de los mensajes, utilice el nodo Compute o el nodo Mapping.

Warehouse
El nodo Warehouse proporciona una interfaz de almacén que se puede utilizar para almacenar todo o parte del mensaje en una base de datos, por ejemplo, para realizar una auditoría. El nodo Warehouse sólo maneja mensajes predefinidos. Utilice un editor de correlaciones para desarrollar correlaciones que permitan ejecutar esta acción. Las correlaciones que se desarrollan para un nodo Warehouse no se pueden utilizar en ningún otro tipo de nodo.

Puede controlar el modo de acceso de este nodo a una base de datos especificando la información de usuario y contraseña para el origen de datos que se especifica en la propiedad del nodo. En sistemas distribuidos, utilice el mandato mqsisetdbparms para inicializar y mantener estos valores.

En z/OS, utilice el ID de tarea iniciada del intermediario para acceder a la base de datos.

Sólo puede actualizar una base de datos desde este nodo; no puede actualizar el contenido de ningún mensaje. Si desea actualizar el contenido de los mensajes, utilice el nodo Compute o el nodo Mapping.

Definido por el usuario
Puede incluir un nodo definido por el usuario para interactuar con una base de datos.

Puede controlar el modo de acceso de este nodo a la base de datos especificando la información de usuario y contraseña para el origen de datos que se especifica en la propiedad del nodo. En sistemas distribuidos, utilice el mandato mqsisetdbparms para inicializar y mantener estos valores.

En z/OS, utilice el ID de tarea iniciada del intermediario para acceder a la base de datos.

En la tabla siguiente se resume qué se puede actualizar en estos nodos.

Nodo ¿Actualizar la base de datos? ¿Actualizar el mensaje? ¿Actualizar el entorno local? ¿Se necesita conjunto de mensajes?
Compute No
Database No No
DataDelete No
DataInsert No
DataUpdate No
Extract
Mapping
Warehouse No
Toma de decisiones

Puede utilizar nodos que determinen el orden del proceso y el flujo de control dentro del flujo de mensajes utilizando varios procedimientos para la toma de decisiones relacionados con el modo en que el flujo debe procesar los mensajes. El direccionamiento es independiente de la transformación de mensajes, aunque el direccionamiento que sigue un mensaje puede determinar exactamente la transformación que se lleva a cabo en el mismo.

Por ejemplo, una aplicación de transferencia de dinero siempre envía mensajes a otra aplicación. Es posible que decida que cada mensaje con un valor de transferencia de más de 10.000 dólares se debe enviar a una segunda aplicación, a fin de permitir el registro de todas las transacciones de cantidades elevadas.

En otro ejemplo, un club de vehículos nacionales ofrece un servicio especial para miembros específicos cuyos pedidos se sitúen por encima del valor de umbral. La mayor parte de los pedidos se direccionan a través de los canales habituales pero, si el número de miembro y el valor del pedido cumplen determinados criterios, el pedido obtiene un trato especial.

También puede establecer una opción de direccionamiento más dinámica al crear información de direccionamiento adicional en el mensaje cuando se procesa. Se establecen conjuntos de normas opcionales para recibir mensajes en función de los valores (destinos) establecidos en el mensaje. Puede establecer normas como, por ejemplo, que uno o más conjuntos de normas opcionales procesen un mensaje en un orden que determine el contenido añadido al mensaje.

Utilice los nodos siguientes para tomar decisiones acerca del direccionamiento que sigue un mensaje a través del flujo de mensajes:

Check
Puede inspeccionar las características del mensaje para determinar su estructura y direccionarlo según si cumple las características necesarias.
Filter
Puede codificar una sentencia ESQL para determinar el siguiente nodo al que este nodo va a enviar el mensaje. El código ESQL que desarrolle para utilizarlo en un nodo Filter no se debe usar en ningún otro tipo de nodo.

Los terminales del nodo son verdadero (true), falso (false), desconocido (unknown) y anomalía (failure); el mensaje se propaga al terminal verdadero si la prueba se ejecuta correctamente y al terminal falso si da error. Si la sentencia no se puede resolver (por ejemplo, si prueba el valor de un campo que no aparece en el mensaje de entrada), el mensaje se propaga al terminal desconocido. Si se detecta cualquier otro error, el mensaje se propaga al terminal de anomalías.

La prueba de la sentencia ESQL puede variar en función del contenido del mensaje, el contenido de la base de datos o una combinación de ambos.

Si hace referencia a una base de datos, puede controlar el modo de acceso de este nodo a la base de datos especificando la información de base de datos y contraseña para cada origen de datos definido en el registro del sistema del intermediario. En sistemas distribuidos, utilice el mandato mqsisetdbparms para inicializar y mantener estos valores.

En z/OS, utilice el ID de tarea iniciada del intermediario para acceder a la base de datos.

Utilice, preferentemente, este nodo al nodo Compute para disponer de esta función; aunque puede configurar el nodo Compute para controlar la selección y el direccionamiento de mensajes, el funcionamiento del nodo Filter es mejor.

FlowOrder
Puede conectar los terminales de este nodo para forzar que una secuencia de nodos, seguida de una segunda secuencia de nodos procese el mensaje.
RouteToLabel y Label
Puede definir una lista de destinos en un nodo Compute sobre los que se actúa en el nodo RouteToLabel, que interroga los destinos y pasa el mensaje al nodo Label correspondiente.
ResetContentDescriptor
Puede establecer nuevas propiedades de mensajes que se utilicen cuando un nodo subsiguiente del flujo de mensajes vuelva a analizar la corriente de bits de mensajes.
Colación de peticiones

Puede colacionar peticiones y respuestas relacionadas utilizando los nodos AggregateControl, AggregateReply y AggregateRequest. Utilice estos nodos para generar varias peticiones como respuesta a un mensaje de entrada, para controlar y coordinar los respuestas que se reciban como respuesta a estas peticiones y para combinar la información que proporcionan las respuestas para continuar el proceso.

Manejo e informe de errores

Puede utilizar nodos que influyan en el manejo e informe de errores:

Trace
Cuando incluye un nodo Trace, puede generar una o más entradas de rastreo para registrar lo que sucede en el flujo de mensajes en este punto.
TryCatch
Cuando incluye un nodo TryCatch, puede controlar el proceso de errores cuando se emiten excepciones.
Throw
Cuando incluye un nodo Throw, puede forzar que se emita una excepción y especificar la identidad de ésta a fin de simplificar el diagnóstico del problema.

Excepto para los nodos Compute, Extract y Mapping, los mensajes de entrada que recibe un nodo y el mensaje de salida que envía el nodo son idénticos.

Conceptos relacionados
Flujos de mensajes
Soporte para aplicaciones de usuario final
Árbol LocalEnvironment

Tareas relacionadas
Configuración de DB2
Diseño de un flujo de mensajes
Acceso a bases de datos desde flujos de mensajes
Creación de un flujo de mensajes
Definición del contenido del flujo de mensajes
Utilización de nodos para la toma de decisiones
Difusión de aplicaciones de flujos de mensajes

Referencia relacionada
Mandato mqsisetdbparms
Nodos incorporados
Soporte de aplicaciones de usuario final