WebSphere Message Broker, Versión 8.0.0.5 Sistemas operativos: AIX, HP-Itanium, Linux, Solaris, Windows, z/OS

Consulte la información sobre la última versión del producto en IBM Integration Bus, Versión 9.0

Decidir los nodos a utilizar

WebSphere Message Broker incluye muchos nodos de proceso de mensajes que puede utilizar en sus flujos de mensajes.

Antes de empezar:

Consulte el tema de concepto, Nodos de flujo mensajes.

WebSphere Message Broker también ofrece una interfaz que puede utilizar para definir los nodos propios, que se conocen como nodos definidos por el usuario.

La modalidad en la que trabaja el intermediario puede afectar a los tipos de nodo que puede utilizar; consulte Restricciones que se aplican en cada modalidad de operación.

La decisión sobre qué nodos utilizar depende del proceso que desee realizar en los mensajes.

Nodos de entrada, salida y solicitud
Los nodos de entrada y salida definen puntos en el flujo de mensajes a los que las aplicaciones cliente envían mensajes (nodos de entrada, como MQInput) y desde los cuales las aplicaciones cliente reciben mensajes (nodos de salida, como MQOutput). Las aplicaciones cliente interaccionan con estos nodos poniendo mensajes, u obteniendo mensajes, de los recursos de E/S que el nodo especifica como origen o destino de los mensajes. Aunque un flujo de mensajes debe incluir al menos un nodo de entrada, no tiene por qué incluir un nodo de salida o de solicitud.

Un nodo de entrada es diferente de otros nodos, porque controla cuando el resto del flujo de mensajes se desencadena para realizar su proceso. El nodo de entrada está diseñado para comprobar si existen datos para que el flujo de mensajes los procese, lea esos datos del transporte o el servidor y presente dichos datos al resto del flujo para su proceso. Los otros nodos realizan proceso pero no controlan cuándo se invoca el flujo.

También puede utilizar nodos de respuesta y de solicitud para interactuar con otras aplicaciones desde dentro de un flujo de mensajes; estos tipos de nodos se proporcionan solamente para un subconjunto de protocolos.

  • Si está creando un flujo de mensajes para desplegarlo en un intermediario, debe incluir al menos un nodo de entrada para recibir mensajes. El nodo de entrada que seleccione dependerá del origen de los mensajes de entrada y del lugar del flujo en el que desee recibir los mensajes.
  • Si desea enviar los mensajes generados por el flujo de mensajes a una aplicación de destino, puede incluir uno o más nodos de salida. El nodo de salida que elija dependerá del transporte a través del cual la aplicación de destino espere recibir estos mensajes.
  • Si desea realizar una solicitud, en medio del flujo, a un sistema externo, y colocar el resultado en el árbol de mensaje, utilice un nodo de solicitud.
Nodos para manipular, mejorar y transformar mensajes

La mayoría de empresas tienes aplicaciones que se han desarrollado a lo largo de muchos años, en distintos sistemas, utilizando lenguajes de programación distintos y métodos de comunicación también distintos. WebSphere Message Broker elimina la necesidad de que las aplicaciones entiendan estas diferencias ya que proporciona la posibilidad de configurar flujos de mensajes que transforman los mensajes de un formato a otro.

Por ejemplo, los nombres de las personas están en distintos formatos en las distintas aplicaciones. El primer o segundo apellido, con o sin iniciales del segundo apellido, en mayúsculas o minúsculas son solo algunas de las permutaciones. Puesto que puede configurar el flujo de mensajes según los requisitos de cada aplicación, cada mensaje puede transformarse al formato correcto sin modificar la aplicación que lo envía ni la que lo recibe.

Puede trabajar con el contenido del mensaje para actualizarlo de diversas maneras. La elección dependerá de si el flujo de mensajes debe manejar mensajes predefinidos (con modelo), mensajes autodefinidos (por ejemplo, XML), o ambos.

Un flujo de mensajes puede reconstruir completamente un mensaje, convertirlo de un formato a otro (por ejemplo, cambiando el orden de los campos, el orden de los bytes o el idioma), eliminar contenido del mensaje o colocar datos específicos en él. Por ejemplo, un nodo puede interactuar con una base de datos para recuperar información adicional, o para almacenar una copia del mensaje (total o parcial) en la base de datos para su proceso fuera de línea.

Los ejemplos siguientes muestran la importancia de la transformación de mensajes:
  • Una aplicación de entrada de pedidos tiene un ID de pieza en el cuerpo del mensaje, pero la aplicación de almacenamiento asociada espera que este ID se encuentre en la cabecera del mensaje. El mensaje se dirige a un flujo de mensajes que conoce los dos formatos distintos y, por tanto, puede volver a formatear la información según sea necesario.
  • Una aplicación de entrada de datos crea mensajes que contienen información de transacciones de acciones. Algunas de las aplicaciones que reciben este mensaje necesitan la información tal como se proporciona, pero otras necesitan que se añada información adicional sobre la relación PE (precio-beneficio). Los mensajes de transacciones de acciones se dirigen a un flujo de mensajes que pasa los mensajes sin modificar a algunos nodos de salida, pero calcula y añade la información adicional para los otros. El flujo de mensajes realiza este cálculo buscando el precio actual de las acciones en una base de datos y, a continuación, utilizando este valor y la información de las transacciones en el mensaje original para calcular el valor de PE antes de pasar el mensaje actualizado.

También puede crear flujos de mensajes que utilizan estos nodos para interactuar entre sí. Aunque el funcionamiento predeterminado de un flujo de mensajes no afecta al funcionamiento de otro flujo de mensajes, puede forzar esta acción configurando sus flujos de mensajes de forma que almacenen y recuperen información en una fuente externa como, por ejemplo, una base de datos.

Estos nodos se proporcionan para transformar mensajes.

Nodos para la toma de decisiones

Puede utilizar nodos que determinen el orden y el flujo de control en el flujo de mensajes de varias formas para decidir cómo el flujo procesa los mensajes. También puede utilizar nodos (TimeoutControl y TimeoutNotification) que determinen la hora y la frecuencia de aparición de sucesos dentro del flujo de mensajes. El direccionamiento es independiente de la transformación de mensajes, aunque la ruta que toma un mensaje puede determinar con exactitud la transformación que se efectúa en el mismo.

Por ejemplo, una aplicación de transferencia de dinero siempre envía mensajes a otra aplicación. Puede decidir que cada mensaje con un valor de transferencia superior a los 10.000 euros también debe enviarse a una segunda aplicación, para que se registren todas las transacciones de gran valor.

En otro ejemplo, un club automovilístico nacional ofrece un servicio 'premier' a miembros específicos por pedidos superiores a un cierto valor. 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 ciertos criterios, el pedido recibe un tratamiento especial.

También puede establecer una opción de direccionamiento más dinámica creando información adicional de direccionamiento en el mensaje cuando éste se procesa. Se establecen conjuntos de normas opcionales para recibir mensajes según los valores (destinos) establecidos en el mensaje. Puede establecer estas reglas que indican que un mensaje sea procesado por uno o más conjuntos de reglas opcionales, en el orden que determine el contenido del mensaje añadido.

Estos nodos se proporcionan para decidir la ruta que sigue un mensaje a través del flujo de mensajes.

Nodos para controlar operaciones sensibles al tiempo
Es posible que desee que un proceso de aplicaciones por lotes se ejecute cada día a una hora específica o puede que desee que la información se procese y publique a intervalos fijos (por ejemplo, los tipos de cambio de moneda se calculan y se envían a los bancos) o es posible que desee realizar una acción de recuperación especificada si determinadas acciones no se completan en un tiempo definido. Para todos estos casos, se proporcionan dos nodos de tiempo de espera (TimeoutControl y TimeoutNotification); consulte Nodos para controlar operaciones sensibles al tiempo.
Nodos varios
Existen otros nodos para realizar las tareas siguientes:
  • Clasificar solicitudes
  • Crear colecciones de mensajes
  • Controlar la secuencia de mensajes
  • Manejar y notificar errores
  • Invocar el gestor de seguridad de flujos de mensajes
Consulte el apartado Nodos varios para obtener información detallada.
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Comentarios

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        Última actualización:
        
        Última actualización: 2015-02-28 16:58:13


Tema de tareaTema de tarea | Versión 8.0.0.5 | ac00330_