Information about the key points of the message flows and message sets that are used in the Web Service Aggregation sample.
An aggregation fan-out message flow has one or more output nodes, each upstream of an AggregateRequest node. When all messages to be fanned out have been through an output node and an AggregateRequest node, the message flow commits the unit of work. If the output node is transactional, output messages are sent at this commit point. If the nodes are not transactional, (for example, if they use HTTP), the messages are sent when the node is exited. This behavior can affect aggregation because, if the target web service runs quickly, the reply can arrive before the aggregation commit completes. The reply is then treated as an unknown message in the aggregate response, and is processed after a specified timeout. To avoid this problem, use a transactional output node for fan-out in aggregation message flows. MQOutput nodes support transactionality.
In the Web Service Aggregation sample, a vital aspect of processing is storing the reply identifier of the overall SOAP request safely. For each message flow, an explanation is given about how this behavior is achieved.
The Web Service Aggregation sample contains six message flows. Five flows are used for the aggregation of the web services. These flows are run in the sequence indicated in the following table (click each flow for more details). The sixth message flow processes flow monitoring data.
| Sequence | Message flow name | Description |
|---|---|---|
| 1 | WSAggregationFanOut.msgflow | Calls (fan-out) a number of web services SOAP requests through WebSphere MQ |
| 2 | WSAggregationMQtoSOAP.msgflow | Converts the WebSphere MQ SOAP messages to HTTP |
| 3 | WSAggregationTargetWS.msgflow | Runs the web services and produces responses |
| 4 | WSAggregationSOAPtoMQ.msgflow | Converts the HTTP responses to WebSphere MQ |
| 5 | WSAggregationFanIn.msgflow | Receives (fan-in) the replies from the web services and produces a consolidated SOAP reply |
| WSAggregationReadMonitordata.msgflow | Processes the messages that are produced by Message flow monitoring |
The WSAggregationFanOut.msgflow message flow has MQOutput nodes upstream of AggregateRequest nodes. By using WebSphere MQ nodes, the fan-out is transactional. To specify transactionality in the MQOutput nodes, set Transaction Mode to Yes.
The flow has two AggregateRequest nodes with associated MQOutput nodes upstream. You can add more pairs of nodes if required.
When the WSAggregationFanOut.msgflow flow is run, one or more messages can be put to each queue. The number of messages put to a queue is determined by the value of a field in the input message.
The flow stores the original SOAP reply identifier in the MQMD.CorrelId field of every output message.
Each WebSphere MQ message has a unique MQMD.MsgId field, which is a requirement for aggregation.
The WSAggregationMQtoSOAP.msgflow message flow has two similar parts. The two MQInput nodes serve the two WebSphere MQ queues written to by WSAggregationFanOut.msgflow.
The web service that is called by each part is identical. You can change this behavior so that you can call separate web services if required. For instructions about how to change the behavior, see Extending the sample.
The WSAggregationMQtoSOAP.msgflow message flow stores the original SOAP reply identifier in the UserContext field of the SOAP local environment.
For the web service that is about to run, the flow creates a new SOAP reply identifier from the MQMD.MsgId.
The WSAggregationTargetWS.msgflow message flow creates a web service response message. The flow can be cloned to represent different web services, for example, if each part of WSAggregationMQtoSOAP.msgflow calls different web services.
The web service keeps a count of the number of times it has been called. This number value is returned in the <orderAmt> field of the response message. If <partNo> equals ABC1234, the <orderStatus> field is set to confirmed, otherwise it is set to rejected.
The WSAggregationSOAPtoMQ.msgflow message flow stores the original SOAP reply identifier (from SOAP UserContext in the local environment) in the MQMD.MsgId field of the output message.
The flow stores the SOAP reply identifier of the web service that was previously called in Properties.ReplyIdentifier. When the WebSphere MQ message is produced, it contains this value in MQMD.CorrelId.
The flow sets MQMD.MsgType to MQMT_REPLY.
The WSAggregationFanIn.msgflow message flow restores the original SOAP reply identifier from the aggregated reply message.
The <AMT> field of the aggregated reply message contains the value of the <orderAmt> field of the web service that was called last.
The WSAggregationReadMonitordata.msgflow message flow takes as its input the publish/subscribe messages that are emitted by flow monitoring relevant to that data.
In the WSAggregationReadMonitordata.msgflow message flow, the Collector node creates separate collections for each piece of business data. Because it is not known in advance how many monitor event messages will be produced for each piece of business data, the Collector node times out on its Input terminal after 10 seconds. A (nominal) maximum of 100 events is specified. If more than 100 events are collected, the data will be in more than one collection. When the collection is complete, or a 10-second timeout has elapsed, a summary of the monitor events is written to the Businessdata.xml file.
The FileOutput node specifies that, in the event of a duplicate filename, a timestamp is added to the output file, the file is archived and the existing file replaced. This behavior ensures that no monitoring data is lost if more than one collection with the same business data has been gathered.
The WSAggregationMessages message set contains definitions that are derived from two sets of WSDL definitions:
The message set also contains message definitions that are used by flow monitoring. These are generated from an XML schema that is supplied by IBM Integration Bus.