Aquí se ofrece información sobre los puntos clave de los flujos de mensajes y los conjuntos de mensajes que se utilizan en el ejemplo Agregación de servicios web.
Un flujo de mensajes de diseminación de agregación tiene uno o más nodos de salida, cada uno en sentido ascendente en un nodo AggregateRequest. Cuando todos los mensajes que deben diseminarse han pasado por un nodo se salida y un nodo AggregateRequest, el flujo de mensajes confirma la unidad de trabajo. Si el nodo de salida es transaccional, los mensajes de salida se envían en este punto de confirmación. Si los nodos no son transaccionales, por ejemplo, si utilizan HTTP, los mensajes se envían al salir del nodo. Este comportamiento puede afectar a la agregación porque, si el servicio web de destino se ejecuta con rapidez, la respuesta puede llegar antes de que finalice la confirmación de la agregación. La respuesta luego se trata como un mensaje desconocido en la respuesta de agregado y se procesa tras un periodo de espera. Para evitar este problema, utilice un nodo de salida transaccional para una diseminación en los flujos de mensajes de agregación. Los nodos MQOutput dan soporte a la transaccionalidad.
En el ejemplo Agregación de servicios web, un aspecto vital del procesamiento consiste en almacenar el identificador de respuesta de toda la solicitud SOAP de forma segura. Para cada flujo de mensajes, se ofrece una explicación acerca de cómo lograr este comportamiento.
El ejemplo Agregación de servicios web contiene seis flujos de mensajes. Cinco de los flujos se utilizan para la agregación de servicios web. Estos flujos se ejecutan en la secuencia indicada en la tabla siguiente (pulse cada flujo para obtener más detalles). El sexto flujo de mensajes procesa datos de supervisión de flujos.
| Secuencia | Nombre de flujo de mensajes | Descripción |
|---|---|---|
| 1 | WSAggregationFanOut.msgflow | Llama a (disemina) varias solicitudes SOAP de servicios web a través de WebSphere MQ |
| 2 | WSAggregationMQtoSOAP.msgflow | Convierte los mensajes SOAP de WebSphere MQ a HTTP |
| 3 | WSAggregationTargetWS.msgflow | Ejecuta los servicios web y produce respuestas |
| 4 | WSAggregationSOAPtoMQ.msgflow | Convierte las respuestas HTTP en WebSphere MQ |
| 5 | WSAggregationFanIn.msgflow | Recibe (entrada) las respuestas de los servicios web y produce una respuesta SOAP consolidada |
| WSAggregationReadMonitordata.msgflow | Procesa los mensajes que se producen a través de la supervisión de flujos de mensajes |
El flujo de mensajes WSAggregationFanOut.msgflow tiene nodos MQOutput en sentido ascendente en los nodos AggregateRequest. Gracias a los nodos WebSphere MQ, la diseminación es transaccional. Para especificar la transaccionalidad en los nodos MQOutput, establezca Modalidad de transacción en Sí.
El flujo tiene dos nodos AggregateRequest con nodos MQOutput en sentido ascendente asociados. Puede agregar más pares de nodos si es necesario.
Cuando se ejecuta el flujo WSAggregationFanOut.msgflow, pueden colocarse uno o varios mensajes en cada cola. El número de mensajes que se colocan en una cola viene determinado por el valor de un campo del mensaje de entrada.
El flujo almacena el identificador de respuesta SOAP original en el campo MQMD.CorrelId de cada mensaje de salida.
Cada mensaje de WebSphere MQ tiene un campo MQMD.MsgId exclusivo, que es un requisito para la agregación.
El flujo de mensajes WSAggregationMQtoSOAP.msgflow tiene dos partes similares. Los dos nodos MQInput sirven a las dos colas de WebSphere MQ en las que graba el flujo WSAggregationFanOut.msgflow.
El servicio web invocado por cada parte es idéntico. Puede cambiar este comportamiento de modo que pueda llamar a servicios web independientes si es necesario. Para obtener instrucciones sobre cómo cambiar el comportamiento, consulte Ampliar el ejemplo.
El flujo de mensajes WSAggregationMQtoSOAP.msgflow almacena el identificador de respuesta SOAP original en el campo UserContext del entorno SOAP local.
Para el servicio web que se va a ejecutar, el flujo de mensajes crea un nuevo identificador de respuesta SOAP a partir de MQMD.MsgId.
El flujo de mensajes WSAggregationTargetWS.msgflow crea un mensaje de respuesta de servicio web. El flujo se puede clonar para representar distintos servicios web, por ejemplo, si cada parte de WSAggregationMQtoSOAP.msgflow llama a servicios web distintos.
El servicio web mantiene un recuento del número de veces que ha sido invocado. Este valor numérico se devuelve en el campo <orderAmt> del mensaje de respuesta. Si <partNo> es igual a ABC1234, el campo <orderStatus> se establece en confirmed; en caso contrario, se establece en rejected.
El flujo de mensajes WSAggregationSOAPtoMQ.msgflow almacena el identificador de respuesta SOAP original (de SOAP UserContext en el entorno local) en el campo MQMD.MsgId del mensaje de salida.
El flujo almacena el identificador de respuesta SOAP del servicio web invocado previamente en Properties.ReplyIdentifier. Cuando se produce el mensaje de WebSphere MQ, el mensaje contiene este valor en MQMD.CorrelId.
El flujo establece MQMD.MsgType en MQMT_REPLY.
El flujo de mensajes WSAggregationFanIn.msgflow restaura el identificador de respuesta SOAP original del mensaje de respuesta agregado.
El campo <AMT> del mensaje de respuesta agregado contiene el valor del campo <orderAmt> del servicio web invocado en último lugar.
El flujo de mensajes WSAggregationReadMonitordata.msgflow toma como entrada los mensajes de publicación/suscripción emitidos por la supervisión de flujo relevante para dichos datos.
En el flujo de mensajes WSAggregationReadMonitordata.msgflow, el nodo Collector crea colecciones distintas para cada fragmento de datos empresariales. Dado que no se conoce de antemano cuántos mensajes de sucesos de supervisor se producirán para cada fragmento de datos empresariales, el nodo Collector excede el tiempo de espera en su terminal de entrada transcurridos 10 segundos. Se especifica un valor máximo (nominal) de 100 sucesos. Si se recopilan más de 100 sucesos, los datos residirán en más de una colección. Una vez finalizada la colección, o una vez que han transcurrido los 10 segundos, se escribe un resumen de los sucesos de supervisor en el archivo Businessdata.xml.
El nodo FileOutput especifica que, si existe un nombre de archivo duplicado, se añade una indicación de fecha y hora al archivo de salida, se archiva el archivo y se sustituye el archivo existente. Este comportamiento garantiza que los datos de supervisión no se pierdan si se ha recopilado más de una colección con los mismos datos empresariales.
El conjunto de mensajes WSAggregationMessages contiene definiciones que se derivan de dos conjuntos de definiciones WSDL:
El conjunto de mensajes también contiene definiciones de mensaje utilizadas en la supervisión de flujos. Éstas se generan a partir de un esquema XML proporcionado por IBM Integration Bus.