This topic describes four scenarios in which Web service clients interact with WebSphere Business Integration Message Broker. These do not comprise a definitive list, but represent some of the options that are supported for Web services applications.
In this scenario, you typically clear the Replace input message with web service response check box in the HTTPRequest node properties, and place the response from the corporate directory server in a temporary location in the message tree specified in the Response message location in tree property in the same node. In Compute2, you code ESQL to unpack the result, and augment the final message as appropriate.
Code ESQL in Compute1 to map the client request to a server request, and in Compute2 to map the server response to the client reply. You could define these request, reply, and response messages in the MRM domain to simplify the transformation from one format to another.
You can configure the HTTPRequest node to generate HTTP headers from the headers that are received by the HTTPInput node, which allows for cookies and other application-specific headers to be passed through. The HTTPReply node can provide an equivalent task to extract headers from the response from the Web service to return to the originating client. If you want this to be done, select the appropriate Generate default HTTP headers from..... check box on both the HTTPRequest and HTTPReply nodes.
In most scenarios, the original request is of no value, and you need only the response from the service to be able to generate the client reply message. If so, select the property Replace input message with web service response on the HTTPRequest node. If you do want to preserve any data from the input request, you can store this in the LocalEnvironment in Compute1 and retrieve it in Compute2 for inclusion in the reply.
Most message flows that currently use WebSphere MQ for input or output can be adapted to use HTTP as a replacement or additional protocol.
You can model the input message in the MRM domain and generate WSDL from the model, or you could process a generic XML or XMLNS domain message. If you have defined the message in the MRM domain, you can configure the HTTPInput node to validate the input message. The node generates an exception if the message does not conform to the model.
You can configure the HTTPReply node to generate a set of default HTTP headers for the reply message sent to the client. This reduces the modifications that you must make to convert the message flow from one that processes WebSphere MQ messages to a flow that processes HTTP messages.
The first message flow receives inbound requests from Web service clients in an HTTPInput node. It includes a Compute node to transform request in some way and an MQOutput node to send the modified request to the WebSphere MQ application.
The second message flow receives the response from that application in an MQInput node. The message is passed to a Compute node that transforms the message and propagates it to an HTTPReply node that sends it as a reply to the original Web service client.
Although the transformations completed by each Compute node might be trivial, the ESQL code in the first must save HTTP state information that is retrieved by the second to ensure that the replies from the WebSphere MQ application are returned to the client that sent the original request.
The first message flow receives the message, does whatever transformations are needed, and encodes the HTTP request identifier in the outbound message. (The request identifier could also be stored in a database if you prefer). The HTTPInput node provides the request identifier as a field in the LocalEnvironment tree called Destination.HTTP.RequestIdentifier and Compute1 can read and store this value.
The second message flow receives the reply message and transforms it back into the client message format. Compute2 reads the HTTP request identifier from the message, and sets LocalEnvironment.Destination.HTTP.RequestIdentifier using this value. The HTTPReply node uses the request identifier to ensure that the message reaches the correct HTTP client.
The implementation of this scenario requires correct handling of the MQMD. Messages that come into a message across HTTP must have an MQMD added before they are sent to an MQOutput node. Also, any messages coming in across WebSphere MQ must have the MQMD removed before proceeding out an HTTPReply or HTTPRequest node (unless including an MQMD in the HTTP stream is desired).
In the ESQL module for Compute1, include a statement like this:
SET OutputRoot.XML.A.MessageID = CAST(InputLocalEnvironment.Destination.HTTP.RequestIdentifier AS CHARACTER);
In the ESQL module for Compute2, code a statement like this:
SET OutputLocalEnvironment.Destination.HTTP.RequestIdentifier = CAST(InputRoot.XML.A.MessageID AS BLOB);
Related concepts
WebSphere MQ Web Services Transport
Generate Web Services Description Language (WSDL)
Related tasks
Creating a message flow
Configuring nodes for particular Web Services scenarios
Deploying message flow applications
Checking the results of deployment
Related reference
HTTPInput node
HTTPReply node
HTTPRequest node
Notices |
Trademarks |
Downloads |
Library |
Support |
Feedback
![]() ![]() |
ac20440_ |