Nodos de flujo mensajes

Un nodo de flujo de mensajes es un paso de proceso de un flujo de mensajes.

Un nodo de flujo de mensajes recibe un mensaje, efectúa un conjunto de acciones en el mensaje y opcionalmente pasa el mensaje al nodo siguiente del flujo de mensajes. Un nodo de flujo de mensajes puede ser un nodo incorporado, un nodo definido por el usuario o un nodo de subflujo.

Un nodo de flujo de mensajes tiene un número fijo de puntos de entrada y salida que se conocen como terminales. Puede efectuar las conexiones entre los terminales para definir las rutas que puede tomar un mensaje a través de un flujo de mensajes.

Nodo incorporado
Un nodo incorporado es un nodo de flujo de mensajes que proporciona WebSphere Message Broker. Los nodos incorporados proporcionan funciones de entrada y salida, manipulación y transformación, toma de decisiones, clasificación de peticiones, manejo e informe de errores.

Para obtener información sobre todos los nodos incorporados suministrados por WebSphere Message Broker, consulte Nodos incorporados.

Nodo definido por el usuario
Un nodo definido por el usuario es una extensión del intermediario que proporciona un nuevo nodo de flujo de mensajes además de los que se proporcionan con el producto. Debe escribirse en la API del nodo definido por el usuario proporcionada por WebSphere Message Broker para los lenguajes C y Java. El siguiente ejemplo muestra cómo se pueden escribir nodos propios en los lenguajes C y Java. Los ejemplos sólo pueden verse cuando se utiliza el centro de información que está integrado en el Kit de herramientas de Message Brokers.
Subflujo
Un subflujo es un gráfico dirigido que consta de nodos de flujo de mensajes y conectores y está diseñado para intercalarlo en un flujo de mensajes o en otro subflujo. Un subflujo debe incluir al menos uno nodo de Input o un nodo Output. Un subflujo lo puede ejecutar un intermediario sólo como parte de un flujo de mensajes en el que está incorporado y, por lo tanto, no se puede desplegar de forma independiente.

Un nodo de Input recibe un mensaje y se procesa de acuerdo con la definición del subflujo. Esto podría incluir su almacenamiento a través de un nodo Warehouse o su entrega en otro destino de mensaje, por ejemplo a través de un nodo MQOutput. Si es necesario, el mensaje se puede pasar a través de un nodo Output para devolverlo al flujo principal para procesarlo posteriormente.

Cuando se intercala en un flujo principal, el subflujo se representa mediante un nodo de subflujo que tiene un icono exclusivo. El icono se muestra con el número correcto de terminales para representar los nodos de Input y de Output que se hayan incluir en la definición del subflujo.

El uso más común de un subflujo es proporcionar un proceso necesario en muchos lugares de un flujo de mensajes o compartirlo entre varios flujos de mensajes. Por ejemplo, puede codificar algún proceso de errores en un subflujo o crear un subflujo que proporcione un seguimiento de auditoría (almacenando todo el mensaje y escribiendo una entrada de rastreo).

El uso de subflujos se muestra en los siguientes ejemplos: El ejemplo de manejador de errores utiliza un subflujo para atrapar información sobre errores y almacenar la información en una base de datos. El ejemplo de Respuesta de petición coordinada utiliza un subflujo para encapsula el almacenamiento de los valores ReplyToQ y ReplyToQMgr en un mensaje de WebSphere MQ para que la lógica de proceso puede reutilizarse en otros flujos de mensajes y permitir la sustitución de implementaciones alternativas. Los ejemplos sólo pueden verse cuando se utiliza el centro de información que está integrado en el Kit de herramientas de Message Brokers.

Un nodo no siempre genera un mensaje de salida para cada terminal de salida: a menudo, genera un nodo de salida para un solo terminal basándose en el mensaje recibido o en el resultado de la operación del nodo. Por ejemplo, habitualmente, un nodo Filter envía un mensaje al terminal True (verdadero) o al terminal False (falso), pero no a ambos.

Si se conecta más de un terminal, el nodo envía el mensaje de salida en cada terminal pero sólo envía al terminal siguiente cuando el proceso ha terminado para el terminal actual. Las actualizaciones efectuadas en un mensaje no se propagan nunca a nodos ejecutados anteriormente, sólo a nodos que van a continuación del nodo en el que se ha efectuado la actualización. El orden en el que se propaga el mensaje a los diferentes terminales de salida lo determina el intermediario y este orden no se puede modificar. La única excepción a esta norma es el nodo FlowOrder, en el que los terminales indican el orden en el que se propaga el mensaje a cada uno de ellos.

El flujo de mensajes puede aceptar un mensaje nuevo para su proceso sólo cuando se han completado todas las rutas a través del flujo de mensajes (es decir, todos los nodos conectados de todos los terminales de salida).

El siguiente ejemplo utiliza variables de entorno en el ejemplo XML_Reservation para almacenar información que se ha tomado de una tabla de base de datos y pasar dicha información a un nodo en sentido descendente en el flujo de mensajes. Los ejemplos sólo pueden verse cuando se utiliza el centro de información que está integrado en el Kit de herramientas de Message Brokers.
Conceptos relacionados
Proyectos de flujo de mensajes
Conexiones de flujo de mensajes
Modelado de mensajes
Tareas relacionadas
Desarrollar flujos de mensajes
Referencia relacionada
Proyectos y archivos de flujo de mensajes
Nodos incorporados
Información relacionada
API de extensiones Java definidas por el usuario
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión

Copyright IBM Corporation 1999, 2009Copyright IBM Corporation 1999, 2009.
Última actualización : 2009-02-16 13:53:54

ac12640_