Configuring nodes for particular Web Services scenarios

This topic provides further information about how to configure nodes in a message flow to handle particular situations.

Setting the HTTP Status Code for a reply
The default HTTP Status Code is 200, which means OK. This can be modified in several ways:
  • If the property Generate default HTTP headers from input or response is selected, the HTTPReply node scans the HTTP response headers for a status code to pass on. The response headers are created by the HTTPRequest node, and represent the HTTP headers provided as part of the response from the Web service. The HTTPReply node finds the status code, and sets its own status code to this value.
  • You can set the status code in field Destination.HTTP.ReplyStatusCode in the LocalEnvironment. If you do so, the value that you set overrides any settings retrieved from the response headers.

Although you can also set the reply status in the special header (X-Original-HTTP-Status-Code in the HTTPReplyHeader section of the output message which overrides all other settings) in a Compute node, you are recommended to use the LocalEnvironment content for this purpose.

Using the LocalEnvironment.Destination.HTTP.RequestIdentifier
When the HTTPInput node receives an input request message, it sets the LocalEnvironment field Destination.HTTP.RequestIdentifier to a unique value that identifies the Web service client that sent the request. You can refer to this value and you can save it to another location if appropriate.

For example, if you design a pair of message flows that interact with an existing WebSphere MQ application (as described in Working with Web services example scenarios), you can save this value in the request flow and restore it in the reply flow to ensure that the correct client receives the reply. If you do so, you must not change the data, and you must retain the data as a BLOB.

The HTTPReply node extracts this value from LocalEnvironment and sets up the reply so that it is sent to the specific client.

If you design a message flow that includes both an HTTPInput and an HTTPReply node, the value is set into the LocalEnvironment by the HTTPInput node, but the HTTPReply node does not use it. Therefore if your message flow includes both nodes and a Compute node in the same flow, you do not have to include the LocalEnvironment tree when you specify which components of the message tree are copied from input message to output message by the Compute node (the Compute mode property).

Setting the HTTPRequest node URL dynamically
You can set the property Default Web Service URL on the HTTPRequest node to determine the destination URL for a web-service request. You can configure a Compute node before the HTTPRequest node within the message flow to override the value set in the property. Code ESQL that stores a URL string in LocalEnvironment.Destination.HTTP.RequestURL; this is retrieved by the HTTPRequest node and used in place of the node property value.

Although you can also set the request URL in the special header X-Original-HTTP-URL in the HTTPRequestHeader section of the request message (which overrides all other settings) in a Compute node, you are recommended to use the LocalEnvironment content for this purpose.

Setting Generate default HTTP headers from input or response for the HTTPReply node
If you select the Generate default HTTP headers from input or response check box on the HTTPReply node properties dialog, the node includes a minimum set of headers in the response that is sent to the Web service client. It also includes any headers that are present in the HTTPResponseHeader within the message it receives as input.

The HTTPReply node always rewrites the Content-Length header (even if you have cleared the Generate default HTTP headers from input or response check box) to ensure that its content is correct.

All other headers are copied from the HTTPResponseHeader. After this, if no Content-Type header exists, it is added with a value of text/xml; charset=utf-8.

If an HTTPReplyHeader section existed in the message received by the HTTPReply node, and the Output terminal of the HTTPReply node is connected, the HTTPReplyHeader section is updated with any changed or added values.

Setting Generate default HTTP headers from input for the HTTPRequest node
If you select the Generate default HTTP headers from input check box on the HTTPRequest node properties dialog, the node includes a minimum set of headers in the request that is sent to the server. The node also includes any headers that are present in the HTTPInputHeader within the message it receives as input.

The HTTPRequest node always rewrites the Content-Length header (even if you have cleared the Generate default HTTP headers from input check box), to ensure that its content is correct.

All headers are copied from the HTTPInputHeader except:

  • The Host header, which is set based on either the request URL or the incoming HTTPRequestHeader section of the message
  • The Content-Length header, which is rewritten in all cases

Several headers are generated with default values if they are not found in the incoming HTTPRequest or HTTPInput headers:

  • SOAPAction, which is set to ""
  • Host, which is set based on the request URL to be used for this message. This could be the value
  • Content-Type, which is set to text/xml; charset=utf-8

Any header that is present in an HTTPRequestHeader in the message received by the node overrides a header with the same name that is also present in an HTTPInputHeader in the same message. If an HTTPRequestHeader exists in the received message, the HTTPRequestHeader is updated with any changed or added values.

Related concepts
WebSphere MQ Web Services Transport
Generate Web Services Description Language (WSDL)

Related tasks
Creating a message flow
Working with Web services example scenarios
Deploying message flow applications
Checking the results of deployment

Related reference
HTTPInput node
HTTPReply node
HTTPRequest node