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 success. If you want a different status code to be returned, then either:
  • Set your status code in the field Destination.HTTP.ReplyStatusCode in the LocalEnvironment (correlation name OutputLocalEnvironment). This overrides any status code set in an HTTPResponseHeader as described below.
  • If an HTTPRequest node precedes the HTTPReply node in your flow, then an HTTPResponseHeader will have been created in the logical tree, representing the HTTP headers in the response from another Web service. For convenience, if the HTTPReply node property Generate default HTTP headers from reply or response is selected, then values from this header are used as defaults in creating the reply message, allowing you to set your status code in the field X-Original-HTTP-Status-Code in the HTTPResponseHeader. You can also set this field in an HTTPReplyHeader, but you are recommended to use the LocalEnvironment instead as described above.
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.
If 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.

The 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.

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.
If 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.
The 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.

If an HTTPRequestHeader exists in the received message, the HTTPRequestHeader is updated with any changed or added values.

Start of changeCollecting HTTPListener trace if you have problems with HTTPEnd of change
Start of changeIf you have problems with HTTP, you can trace the HTTPListener:
  1. Start trace using the mqsichangetrace command.
  2. View the HTTPListener trace log using the mqsireadlog command with the HTTPListener qualifier for the -b parameter.
End of change
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