Working with HTTP flows

This topic provides information which may be useful if you are using HTTP message flows to interact with Web services. You may find it useful to read this in conjunction with the subsequent Web services scenarios section.

HTTPS
For help with using HTTPS see Implementing SSL authentication.
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 Broker calls existing Web service), 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 reply or response for the HTTPReply node
If you select the Generate default HTTP headers from reply 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.
Start of changeIf you want to set any headers explicitly, create them in an HTTPReplyHeader. For example, a Compute node propagating a message in the XMLNS domain and wishing to modify the Content-Type could do so as follows:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPReplyHeader."Content-Type" = 'text/xml';
SET OutputRoot.XMLNS = InputRoot.XMLNS;
In the particular case of Content-Type, do not set this header using the ContentType property unless you are working in the MIME domain. The ContentType property is specifically intended to set the value of Content-Type used in MIME.End of change
Start of changeThe full set of HTTP headers used in the request is built by selecting the headers using the following algorithm:
  1. Select any headers in an HTTPReplyHeader.
  2. If no Content-Type header is defined so far, create one using any non-empty value in the ContentType property.
  3. Select any headers in an HTTPResponseHeader (an HTTPResponsHeader is propagated on return from an HTTPRequest node).
  4. If no Content-Type header is defined so far, create one with the default value text/xml; charset=utf-8
  5. Create or overwrite the Content-Length header.
Attention: The HTTPReply node always rewrites the Content-Length header, even if you have cleared the Generate default HTTP headers from reply or response check box. This is to ensure that the content is correct.
End of change

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.
Start of changeIf you want to set any headers explicitly, create them in an HTTPRequestHeader. For example, a Compute node propagating a message in the XMLNS domain and wishing to modify the Content-Type could do so as follows:
CALL CopyMessageHeaders();
SET OutputRoot.HTTPRequestHeader."Content-Type" = 'text/xml';
SET OutputRoot.XMLNS = InputRoot.XMLNS;
In the particular case of Content-Type, do not set this header using the ContentType property unless you are working in the MIME domain. The ContentType property is specifically intended to set the value of Content-Type used in MIME.End of change
Start of changeThe full set of HTTP headers used in the request is built by selecting the headers using the following algorithm:
  1. Set the Host header, based on either the request URL or the incoming HTTPRequestHeader section of the message.
  2. Select any headers in an HTTPRequestHeader.
  3. If no Content-Type header is defined so far, create one using any non-empty value in the ContentType property.
  4. Select any headers in an HTTPInputHeader (an HTTPInputHeader is created automatically by an HTTPInput node).
  5. If no Content-Type header is defined so far, create one with the default value text/xml; charset=utf-8
  6. If no SOAPAction header is defined so far, create one with the default value ''
  7. Create or overwrite the Content-Length header.
Attention: The HTTPRequest node always rewrites the Content-Length header, even if you have cleared the Generate default HTTP headers from input or request check box. This is to ensure that the content is correct.
End of change

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 WSDL
Related tasks
Creating a message flow
Deploying
Checking the results of deployment
Related reference
HTTPInput node
HTTPReply node
HTTPRequest node