HTTPReply node
Use the HTTPReply node to return a response from the message flow to an HTTP client. This node generates the response to an HTTP client from which the input message was received by the HTTPInput node, and waits for confirmation that it has been sent.
- Developer
- Application Integration Suite
- Standard
- Advanced
- Express
- Scale
- Adapter
This topic contains the following sections:
Purpose
The HTTPReply node can be used in a message flow that sends a response to an inbound HTTP or HTTPS messages. The most common example of this scenario is a message flow that implements a web service.
For more information about web services, see Processing web service messages.
By default, HTTP messages are handled by the integration node listener, which is started when a message flow that includes HTTP nodes is started. All inbound and outbound HTTP messages are routed through this listener, for all HTTP nodes deployed to all message flows in all integration servers on the integration node.
You can configure the integration server to use its embedded listener to service the HTTP nodes in all message flows that are deployed to that integration server. The embedded listener communicates directly with the client and the nodes.
For further information about using the embedded listener, see HTTP listeners.
You cannot use an HTTPReply node to respond to a web service request that is received by a SOAPInput node; the integration node generates an exception when the reply is attempted.
If you have configured the integration server to use its embedded listener for HTTP nodes, you must deploy the flow that includes the HTTPReply node to the same integration server as the message flow that includes the HTTPInput node. If your integration node is configured to start the integration node listener to support HTTP nodes, you must deploy the reply flow to the same integration node, but the integration server is not significant, because the listener is shared.
The HTTPReply node constructs a reply message for the web service client from the entire input message tree, and returns it to the requester. If the message was initially received by an HTTPInput node in another message flow, the response is associated with the reply by a request identifier that is stored in the local environment of the message by the HTTPInput node.
The HTTPReply node is contained in the HTTP drawer of the palette, and is represented in the IBM Integration Toolkit by the following icon:
Connecting the output terminals to another node
Connect the Out or Failure terminal of this node to another node in this message flow if you want to process the message further, process errors, or send the message to an additional destination.
Terminals and properties
When you have put an instance of the HTTPReply node into a message flow, you can configure it; see Configuring a message flow node. The properties of the node are displayed in the Properties view. All mandatory properties for which you must enter a value (those that do not have a default value defined) are marked with an asterisk.
The HTTPReply node terminals are described in the following table.
| Terminal | Description |
|---|---|
| In | The input terminal that accepts a message for processing by the node. |
| Failure | The output terminal to which the message is routed if a failure is detected when the message is propagated. |
| Out | The output terminal to which the message is routed if it has been propagated successfully, and if further processing is required in this message flow. |
The following tables describe the node properties. The column headed M indicates whether the property is mandatory (marked with an asterisk if you must enter a value when no default is defined); the column headed C indicates whether the property is configurable (you can change the value when you add the message flow to the BAR file for deployment).
The HTTPReply node Description properties are described in the following table.
| Property | M | C | Default | Description |
|---|---|---|---|---|
| Node name | No | No | HTTPReply | The name of the node. |
| Short description | No | No | A brief description of the node. | |
| Long description | No | No | Text that describes the purpose of the node in the message flow. |
The HTTPReply node Basic properties are described in the following table.
| Property | M | C | Default | Description |
|---|---|---|---|---|
| Ignore transport failures | Yes | No | Selected | Select Ignore transport failures if you want transport-related failures to be ignored (for example, if the client is disconnected). If you clear the check box, and a transport-related error occurs, the input message is propagated to the Failure terminal. If you clear the check box, you must supply a value for Reply send timeout (sec). |
| Reply send timeout (sec) | Yes | No | 120 | Set the Reply
send timeout (sec) value if you are not ignoring transport
failures. This property specifies the length of time, in seconds,
that the node waits for an acknowledgment that the client has received
the reply. If the acknowledgment is received within this time, the
input message is propagated through the Out terminal to the rest of
the message flow, if it is connected. If an acknowledgment is not
received within this time, the input message is propagated through
the Failure terminal, if it is connected. If the Failure terminal
is not connected, and an acknowledgment is not received in time, an
exception is generated. The valid range is zero (which means an indefinite wait) to (231)-1. This property is valid only if Ignore transport failures is cleared. |
| Generate default HTTP headers from reply or response | Yes | No | Selected | Select Generate
default HTTP headers from reply or response if you want the
default web service headers to be created using values from the HTTPReplyHeader
or the HTTPResponseHeader. If the appropriate header is not present
in the input message, default values are used. The node always includes, in the HTTPReplyHeader, a Content-Length header, which is set to the correct calculated value, even if this header was not included in the original request. |
The Validation properties of the HTTPReply node are described in the following table.
If a message is propagated to the Failure terminal of the node, it is not validated. For a full description of these properties, see Validation properties.
| Property | M | C | Default | Description | mqsiapplybaroverride command property |
|---|---|---|---|---|---|
| Validate | No | Yes | Inherit | This property controls whether validation takes place. Valid values are None, Content and Value, Content, and Inherit. | validateMaster |
| Failure action | No | No | Exception | This property controls what happens if validation fails. You can set this property only if you set Validate to Content or Content and Value. Valid values are User Trace, Local Error Log, Exception, and Exception List. |
| Property | M | C | Default | Description |
|---|---|---|---|---|
| Events | No | No | None | Events that you have defined for the node are
displayed on this tab. By default, no monitoring events are defined
on any node in a message flow. Use Add, Edit,
and Delete to create, change or delete monitoring
events for the node; see Configuring monitoring event sources by using monitoring properties for details. You can enable and disable events that are shown here by selecting or clearing the Enabled check box. |