Nodos de flujo mensajes

Un nodo de flujo de mensajes es un paso de proceso de un 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 proporcionados 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 estar escrito con la API del nodo definido por el usuario proporcionada por WebSphere Message Broker para lenguajes C y Java. El El Ejemplo de extensión definida por el usuario muestra cómo puede escribir sus propios nodos en lenguajes C y Java.
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 un nodo de entrada y un nodo de salida. 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 entrada recibe un mensaje y lo procesa siguiendo la definición del subflujo. Esto puede incluir almacenarlo en un nodo Warehouse o entregarlo a 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 otra vez al flujo principal para su proceso adicional.

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 de terminales correcto para representar los nodos de entrada y de salida que ha incluido 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 el Ejemplo Manejador de errores y el Ejemplo de respuesta de petición coordinada. 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 encapsular el almacenamiento de los valores de ReplyToQ y ReplyToQMgr en un mensaje de WebSphere MQ para que la lógica de proceso se pueda volver a utilizar en otros flujos de mensajes y para permitir que se sustituyan implementaciones alternativas.

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, un nodo Filter generalmente envía un mensaje al terminal true o al terminal false 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.

El flujo de mensajes puede aceptar un mensaje nuevo para su proceso sólo cuando se han completado todas las vías de acceso a través del flujo de mensajes, esto es, todos los nodos conectados desde todos los terminales de salida.

El Ejemplo Reserva de vuelos 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.

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
Avisos | Marcas registradas | Descargas | Biblioteca | Soporte | Su opinión
Copyright IBM Corporation 1999, 2006 Última actualización: 22/08/2006
ac12640_