The Asynchronous Consumer sample shows how you can use asynchronous nodes to call a web service. The web service Web Services Definition Language (WSDL) is imported into the tooling and used to configure the SOAPAsyncRequest node to call operations exposed by the web service. This sample also demonstrates how existing WebSphere MQ interfaces can be extended to make web service requests.
The sample initially uses an HTTP transport, but it can be modified to use JMS, see Configuring the Asynchronous Consumer sample to use a JMS transport.
In the sample the web service is a simplified ordering service that exposes one operation. The web service is provided as a message flow in the sample. The web service always returns a response indicating that the part ordered is available; an option for extending the web service might be to use a Database node to query a stock database.
The Asynchronous Consumer sample demonstrates the following tasks:
The following diagram shows the web client message flow:
Node type | Node name |
---|---|
MQInput | MQWSInput |
MQOutput | MQWSOutput |
Compute | Compute Request, Format Response |
SOAPAsyncRequest | SOAP Asynchronous Request |
SOAPAsyncResponse | SOAP Asynchronous Response |
A web service request is constructed from a WebSphere MQ message by using the
Compute Request node in the SOAP
domain. The web service operation is called by using the SOAP Asynchronous Request node
and the paired SOAP Asynchronous Response node receives the response.
Finally the Format Response node formats the response as a WebSphere MQ message.
The following diagram shows the web service message flow:
Node type | Node name |
---|---|
SOAPInput | SOAP Input |
RouteToLabel | Route WS Operation |
Label | submitPO |
Compute | Compute Response |
SOAPReply | SOAP Reply |
An incoming SOAP message is routed to the submitPO node by using the Route WS Operation node. In this example, one operation only is exposed by the sample web service. You can use multiple Label nodes to handle the different operations when your web service exposes more than one operation. The SOAP response is generated in the Compute Response node, before the response is sent back to the web client.
The web client message flow is driven by a WebSphere MQ message. A Test Client file is supplied for running the sample, the file uses the message format shown in the following screen capture:
The valid format for a web service request message and response message is shown in the following edited schema extract:
<xsd:element name="submitPORequest"> ... <xsd:complexType> <xsd:sequence> <xsd:element name="partNo" type="xsd:string"/> <xsd:element name="partQuantity" type="xsd:int"/> <xsd:element name="personName"> <xsd:complexType> <xsd:sequence> <xsd:element name="firstName" type="xsd:string"/> <xsd:element name="lastName" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> <xsd:element name="address"> <xsd:complexType> <xsd:sequence> <xsd:element name="street" type="xsd:string"/> <xsd:element name="city" type="xsd:string"/> <xsd:element name="zipCode" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element>
<xsd:element name="submitPOResponse"> ... <xsd:complexType> <xsd:sequence> <xsd:element name="orderStatus" type="xsd:string"/> <xsd:element name="orderAmt" type="xsd:int"/> <xsd:element name="partNo" type="xsd:string"/> <xsd:element name="partQuantity" type="xsd:int"/> </xsd:sequence> </xsd:complexType> </xsd:element>
After running the sample you might want to extend it to send a request message that is not valid. To send a request message that is not valid, you must edit the Compute Request node to add bad elements to the SOAP message body. The Failure terminal on the SOAPAsyncRequest node must be connected because a SOAP fault message is generated by the web service. For more details about SOAP faults, see The SOAP fault in the WebSphere Message Broker documentation.