See information about the latest product version
HTTPRequest node
Use the HTTPRequest node to interact with a web service.
This topic contains the following sections:
Purpose
The HTTPRequest node interacts with a web service, using all or part of the input message as the request that is sent to that service. You can also configure the node to create an output message from the contents of the input message, augmented by the contents of the web service response, before you propagate the message to subsequent nodes in the message flow.
Depending on the configuration, this node constructs an HTTP or an HTTP over SSL (HTTPS) request from the specified contents of the input message, and sends this request to the web service. The node receives the response from the web service, and parses the response for inclusion in the output tree. The node generates HTTP headers if they are required by your configuration.
You can use this node in a message flow that does or does not contain an HTTPInput or HTTPReply node.
The HTTPRequest node handles messages in the following message domains:
- DFDL
- XMLNSC
- JSON
- BLOB
- MIME
- MRM
- XMLNS
The HTTPRequest node is contained in the HTTP drawer of the palette, and is represented in the WebSphere® Message Broker Toolkit by the following icon:

Using the HTTPRequest node to issue a request to a web service
- The URL of a service.
- A stream of data that the remote server processes, then sends back a response, which is often a SOAP or other web service message in XML.
The URL is of the format http://<address>[:<port>]/<function>; for example, http://localhost:7080/request. This URL can be specified statically in the HTTPRequest node parameters as a field in the message itself, or as a field in the local environment. The data to be sent to the web service can be the whole, or a portion of, the message tree, as specified in the HTTPRequest node properties.
The data must be in CCSID 1208 format for most requests. The reply can replace the input message, or be inserted into the message tree; the location is specified in the HTTPRequest node parameters. The domain for the reply is XMLNS. If the request is successful, the HTTPResponse is inserted into the front of the message tree, the reply placed in the specified location in the tree, and the request propagated to the Out terminal. If the HTTPRequest node is not able to issue the request, an ExceptionList is inserted into the message tree and the tree is propagated to the Failure terminal.
Set OutputRoot.XMLNS.error850 = CAST(InputRoot.XMLNS.error.BLOB as CHAR CCSID 850);
For
information about HTTP, see Hypertext Transfer Protocol - HTTP/1.1.
For more information about HTTP return codes, see HTTP Response codes.You can specify a timeout interval, so that if the request takes longer than the specified duration, the request is propagated to the Failure terminal with an appropriate message. For each request that the HTTPRequest node processes, it opens a connection, and then closes it when the response is returned. If the timeout interval is specified, the socket is closed after the interval. This closure ensures that a request gets only the correct response, and any response data for a request that has timed out is discarded.
You can use the HTTP proxy to route a request through an intermediate site. You can run tools as a proxy to see the request and the response, and therefore debug your flows. The HTTP destination is as seen by the proxy; if you specify the HTTP destination of localhost, and the HTTP proxy is running on a different computer, the request is routed to the remote proxy computer, not the computer from which the original request was issued.
Using the HTTPRequest node in a message flow
The HTTPRequest node can be used in any message flow that must send an HTTP request. The most common example is a message flow that calls a web service.
For more information about web services, see Processing Web service messages.
Handling errors
The node interacts directly with an external service using TCP/IP; it can, therefore, experience the following types of error:
- Errors that are generated by TCP/IP, for example no route
to host or connection refused.
If the node detects these errors, it generates an exception, populates the exception list with the error information that is received, and routes the input message unchanged to the Failure terminal.
- Errors that are returned by the web server. These errors are represented
by HTTP status codes that are outside the range 100 - 299. If the
node detects these errors, it routes the reply to the Error terminal
while following the properties specified on the Error tab.
The reply is produced as a BLOB message because the node cannot determine in what format the reply will be. If you have not configured this node to handle redirection, messages with a redirection status code (3xx) are also handled in the same way.
HTTP Response Codes
The HTTPRequest node treats the 100 series status codes as a 'continue' response, discards the current response, and waits for another response from the web server.
The 200 series status codes are treated as success, the settings on the various tabs on the node determine the format of the output message that is generated, and the response is routed to the Out terminal of the node.
The 300 series status codes are for redirection. If the Follow HTTP(s) Redirection property is selected, the node resends the request to the new destination that is specified in the response that is received. If the Follow HTTP(s) Redirection property is not selected, the codes are treated as an error, as described in Using the HTTPRequest node to issue a request to a web service. For more information about HTTP return codes, see HTTP Response codes.
The 400 and 500 series status codes are errors, and are treated as described in Using the HTTPRequest node to issue a request to a web service. For more information about HTTP return codes, see HTTP Response codes.
Manipulating headers
If you select Replace input message with web-service response or Replace input with error, the header for the input message (the header that belongs to the message when it arrives at the In terminal of the HTTPRequest node) is not propagated with the message that leaves the HTTPRequest node. However, if one of the properties that specify a location in the message tree is specified, the input message headers are propagated.
The HTTPResponse header, which contains the headers that are returned by the remote web service, is the first header in the message (after Properties) that is propagated from the node. This action is taken regardless of the options that are selected. Therefore, for the reply from the HTTPRequest node to be put to a WebSphere MQ queue, manipulate the headers so that an MQMD is the first header (after Properties).
If you are replacing the input message with a response, you can copy the input message MQMD to the Environment tree before the HTTPRequest node, and then copy it back into the message tree after the HTTPRequest node. If you are specifying a location for the response, in order to maintain existing input message headers, you must move or remove the HTTP Response header so that the MQMD is the first header.
SET OutputRoot = InputRoot;
SET OutputRoot.HTTPResponseHeader = NULL;
SET OutputRoot = InputRoot;
DECLARE HTTPHeaderRef REFERENCE TO OutputRoot.HTTPResponseHeader;
DETACH HTTPHeaderRef;
ATTACH HTTPHeaderRef TO OutputRoot.MQMD AS NEXTSIBLING;
Configuring the HTTPRequest node
When you have put an instance of the HTTPRequest node into a message flow, you can configure the node; 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, are marked with an asterisk.
Configure the HTTPRequest node:
- Optional: On the Description tab, enter a Short description, a Long description, or both. You can also rename the node on this tab.
- On the Basic tab:
- The HTTPRequest node
determines the URL for the web service to which it sends a request.
Select one of the following three options; the node checks these in
the order shown (that is, the first always overrides the second, the
second overrides the third):
- X-Original-HTTP-URL in the HTTPRequest header in the input message
- LocalEnvironment.Destination.HTTP.RequestURL in the input message
- The Web service URL property
The first two options provide dynamic methods to set a URL for each input message as it passes through the message flow. To use either of these options, include a Compute node in the message flow, before the HTTPRequest node, to create and initialize the required value.
The third option provides a value that is fixed for every message that is received in this node. Set this property to contain a default setting that is used if the other fields have not been created, or contain a null value. If either field contains a value, the setting of this property is ignored. The Web service URL property must contain a valid URL or the deployment fails. Ensure that the value that you set in X-Original-HTTP-URL or the LocalEnvironment.Destination.HTTP.RequestURL is also a valid URL; if it is not, the node uses the default setting from the Web service URL property.
If a URL begins http://, the request node makes an HTTP request to the specified URL. If the URL begins https://, the request node makes an HTTP over SSL (HTTPS) request to the specified URL, using the parameters that are specified on the SSL tab for the node.
- Set the value of the Request timeout (sec) property, which is the length of time, in seconds, that the node waits for a response from the web service. If a response is received within this time, the reply is propagated through the Out terminal to the rest of the message flow. If a response 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 a response is not received in this time, an exception is generated.
- The HTTPRequest node
determines the URL for the web service to which it sends a request.
Select one of the following three options; the node checks these in
the order shown (that is, the first always overrides the second, the
second overrides the third):
- On the HTTP Settings tab:
- In HTTP(S) proxy location, set the location of the proxy server to which requests are sent.
- Select Follow HTTP(S) redirection to
specify how the node handles web service responses that contain an
HTTP status code of 300 to 399:
- If you select the check box, the node follows the redirection that is provided in the response, and reissues the web service request to the new URL (included in the message content).
- If you clear the check box, the node does not follow the redirection provided. The response message is propagated to the Error terminal.
- Select one of the options for the HTTP
version property. Valid values are: 1.0 or 1.1.
If you select the HTTP version property value 1.1, you can also select Enable HTTP/1.1 keep-alive.
- Select one of the options for the HTTP method property. Valid values are: POST, GET, PUT, DELETE, and HEAD.
- Select one of the options for the Use compression property to specify the compression of the content of the HTTP request. You can select gzip, zlib (deflate), deflate or none. The value zlib (deflate) represents RFC 1950 and RFC 1951 combined, and deflate represents RFC 1951 only. The default value is none, meaning that the content of the request is not compressed.
- On the SSL tab, if you want to use HTTP
over SSL (HTTPS) requests, set the values for HTTPS requests:
- Specify the Protocol property
that you want to use to make the request. Both ends of an SSL connection
must agree on the protocol to use. Therefore, the selected protocol
must be one that the remote server can accept. The following options
are available:
- SSL. This option tries to connect using the SSLv3 protocol first, but enables the handshake to fall back to the SSLv2 protocol where the SSLv2 protocol is supported by the underlying JSSE provider.
- SSLv3. This option tries to connect with the SSLv3 protocol only. Fallback to SSLv2 is not possible.
- TLS. This option is the default. This option tries to connect with the TLS protocol only. Fallback to SSLv3 or SSLv2 is not possible.
- TLSv1.0. This option attempts to connect with the TLS v1.0 protocol only. Fallback to SSLv3 or SSLv2 is not allowed.
- TLSv1.1. This option attempts to connect with the TLS v1.1 protocol only. Fallback to SSLv3, SSLv2, or TLSv1.0 is not allowed.
- TLSv1.2. This option attempts to connect with the TLS v1.2 protocol only. Fallback to SSLv3, SSLv2, TLSv1.0, or TLSv1.1 is not allowed.
- SSL_TLS. This option enables all SSL v3.0 and TLS v1.0 protocols. Fallback to SSLv2 is not allowed.
- SSL_TLSv2. This option enables all SSL v3.0 and TLS v1.0, v1.1, and v1.2 protocols. Fallback to SSLv2 is not allowed.
- Set the Allowed SSL ciphers property. Use this setting to specify a single cipher (such as SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA) or a list of ciphers that are the only ones used by the connection. This set of ciphers must include one or more that are accepted by the remote server. A comma is used as a separator between the ciphers. The default value is an empty string, which enables the node to use any, or all, of the available ciphers during the SSL connection handshake. This method gives the greatest scope for making a successful SSL connection.
- Use the SSLKeyAlias property to specify a SSL authentication alias for the client-side of an HTTP connection. The server checks an access control list for this client-side key. The key alias that identifies the key in the broker or execution group keystore that is to be used for the SSL connection. Set this optional property if your keystore contains more than one key. The default value "" (or none), means that an SSL key alias is not used. Any other string value identifies the alias.
- Specify the Protocol property
that you want to use to make the request. Both ends of an SSL connection
must agree on the protocol to use. Therefore, the selected protocol
must be one that the remote server can accept. The following options
are available:
- On the Response Message Parsing tab, set
values for the properties that describe the message domain, message
set, message type, and message format that the node uses to determine
how to parse the response message returned by the web service. If
an error message is returned by the web service, the values of these
properties are ignored, and the message is parsed by the BLOB parser.
- In Message domain, select
the name of the parser that you are using from the list. If
the field is blank, the default value is BLOB. Choose from the following
options:
- DFDL
- XMLNSC
- JSON
- BLOB
- MIME
- MRM
- XMLNS
You can also specify a user-defined parser, if appropriate.
- If you are using the DFDL parser, the MRM parser or the XMLNSC parser in validating mode, select the relevant Message model from the list. This list is populated with available message sets when you select MRM or XMLNSC as the Message domain, or with available DFDL schema files when you select DFDL as the Message domain.
- If you are using the DFDL or MRM parsers, select the correct message from the list in Message. This list is populated with messages that are defined in the Message model that you have selected.
- If you are using the MRM parser, select the format of the message from the list in Physical format. This list includes all the physical formats that you have defined for this Message model.
- In Message domain, select
the name of the parser that you are using from the list. If
the field is blank, the default value is BLOB. Choose from the following
options:
- On the Parser Options subtab:
- Parse timing is, by default, set to On Demand, which causes parsing of the message to be delayed. To cause the message to be parsed immediately, see Parsing on demand.
- If you are using the XMLNSC parser, set values for the properties that determine how the XMLNSC parser operates. For more information, see Manipulating messages in the XMLNSC domain.
- On the Error Handling tab, set values for
the properties that determine how an error message returned by the
web service is handled:
- For the whole web service error message to be propagated as the
output message, leave Replace input
with error selected (the default setting).
For the web service error message to be included in the output message with part of the input message content, clear Replace input with error and set the Error message location property. If you clear this property, the node copies the input message to the output message and writes the web service error message over the output message content at the specified location (the input message itself is not modified).
- In the Error message location field,
enter the start location (within the output message tree) at which
the parsed elements from the web service error message bit stream
are stored. This property is required only if you have cleared Replace input with error.
You can enter any valid ESQL field reference, including expressions within the reference and new field references (to create a node in the message tree for the response). For example, enter:
orOutputRoot.XMLNSC.ABC.DEF
Environment.WSError
If you select Replace input with error, this property is ignored.
- For the whole web service error message to be propagated as the
output message, leave Replace input
with error selected (the default setting).
- On the Advanced tab, set values for the
Advanced properties that describe the structure and content of the
web service request and response:
- Specify the content of the request message that is sent to the
web service:
- For the request message to be the whole input message body, leave Use whole input message as request selected
(the default setting).
For the request message to contain a subset of the input message, clear Use whole input message as request and set the Request message location in tree property.
- In the Request message location
in tree field, enter the start location from which the content
of the input message tree is copied to the request message. This property
is required only if you have cleared Use
whole input message as request. The node creates a request
message and copies the specified parts of the input message (the input
message itself is not modified).
You can enter any valid ESQL field reference, including expressions within the reference. For example, enter:
InputRoot.XMLNSC.ABC
If you select Use whole input message as request, this property is ignored.
When the appropriate message tree content is parsed to create a bit stream, the message properties (Message domain, Message set, Message type, and Message format) that are associated with the input message body and stored in the Properties folder are used.
- For the request message to be the whole input message body, leave Use whole input message as request selected
(the default setting).
- Specify the content of the output message that is propagated to
the next node in the message flow:
- For the whole web service response message to be propagated as
the output message, leave Replace
input message with web-service response selected (the default
setting).
For the web service response message to be included in the output message with part of the input message content, clear Replace input message with web-service response and set the Response message location in tree property. If you clear this property, the node copies the input message to the output message and writes the web service response message over the output message content at the specified location (the input message itself is not modified).
- In the Response message location
in tree field, enter the start location (within the output
message tree) at which the parsed elements from the web service response
message bit stream are stored. This property is required only if you
have cleared Replace input message
with web-service response.
You can enter any valid ESQL field reference, including expressions within the reference, and including new field references (to create a node in the message tree for the response). For example, enter:
orOutputRoot.XMLNSC.ABC.DEF
Environment.WSReply
If you select Replace input message with web-service response, this property is ignored.
When the response bit stream is parsed to create message tree contents, the message properties (Message domain, Message set, Message type, and Message format), that you have specified in the Response Message Parsing properties of the node, are used.
- For the whole web service response message to be propagated as
the output message, leave Replace
input message with web-service response selected (the default
setting).
- For the node to generate an HTTPRequestHeader for the request
message, leave Generate default HTTP
headers from input selected (the default setting).
If you do not want the node to generate an HTTPRequestHeader for the request message, clear Generate default HTTP headers from input. To control the contents of the HTTPRequestHeader that is included in the request message, include a Compute node that adds an HTTPRequestHeader to the input message before this HTTPRequest node in the message flow, and clear this check box.
- If you have selected Generate
default HTTP headers from input and the input message includes
an HTTPRequestHeader, the HTTPRequest node extracts web
service headers from the input HTTPRequestHeader and adds any unique
web service headers, except Host (see the following table), that are
present in an HTTPInputHeader, if one exists in the input message.
(An HTTPInputHeader might be present if the input message has been
received from a web service by the HTTPInput node.)
The HTTPRequest node also adds the web service headers shown in the following table, with default values, if these are not present in the HTTPRequestHeader or the HTTPInputHeader.
Header Default value SOAPAction "" (empty string) Content-Type text/xml; charset=ccsid of the message body Unless the input message is in the JSON domain, where the default is:
application/json; charset=ccsid of the message body
Host The host name to which the request is to be sent. The HTTPRequest node also adds the optional header Content-Length with the correct calculated value, even if this value is not present in the HTTPRequestHeader or the HTTPInputHeader.
- If you have selected Generate default HTTP headers from input and the input message does not include an HTTPRequestHeader, the HTTPRequest node extracts web service headers, except Host, from the HTTPInputHeader (if it is present in the input message). The HTTPRequest node adds the required web service headers with default values, if these values are not present in the HTTPInputHeader.
- If you have cleared Generate default HTTP headers from input and the input message includes an HTTPRequestHeader, the node extracts all web service headers present in the input HTTPRequestHeader. The node does not check for the presence of an HTTPInputHeader in the input message, and it does not add the required web service headers if they are not supplied by the input HTTPRequestHeader.
- If you have cleared Generate default HTTP headers from input and the input message does not include an HTTPRequestHeader, no web service headers are generated. The HTTPRequest node does not check for the presence of an HTTPInputHeader in the input message and does not add any required web service header. The request message is propagated to the web service without an HTTPRequestHeader. This action typically causes an error to be generated by the web service, unless the web service is configured to handle the message contents.
If you have selected Use compression or Accept compressed responses by default, the Content-Encoding and Accept-Encoding HTTP header fields are populated regardless of whether you have selected Generate default HTTP headers from input:- If the value of Use compression is not the default of None, the Content-Encoding HTTP header is populated with this value, and the bit stream is compressed. If the Content-Encoding header is already present in an existing HTTP header, this field is updated with the value of the Use compression property. If the existing Content-Encoding header already starts with the named compression function, then no further compression takes place. If the Content-Encoding header starts with deflate, then no compression takes place irrespective of whether ZLIB (deflate)or deflate is selected.
- If you have selected Accept compressed responses, the Accept-Encoding field is populated. If this field is already present in an existing HTTP header, the existing value overrides the property on the node. However, if a compressed response is received, it is not decompressed.
- If you have selected Generate
default HTTP headers from input and the input message includes
an HTTPRequestHeader, the HTTPRequest node extracts web
service headers from the input HTTPRequestHeader and adds any unique
web service headers, except Host (see the following table), that are
present in an HTTPInputHeader, if one exists in the input message.
(An HTTPInputHeader might be present if the input message has been
received from a web service by the HTTPInput node.)
- Select the Accept compressed responses by default property to indicate whether the request accepts compressed responses. If you select this option, the request can receive responses with a Content-Encoding of gzip or deflate. If such a response is received, the content is decoded and the Content-Encoding header is removed. If the Request Header does not contain an Accept-Encoding header then selecting this option sets the Accept-Encoding header to "gzip, deflate".
- Specify the content of the request message that is sent to the
web service:
- On the Validation tab, set Validation properties
if you want the parser to validate the body of response messages against
the Message set. (If a message
is propagated to the Failure terminal of the node, it is not validated.)
These properties do not cause the input message to be validated. It
is expected that, if such validation is required, the validation has
already been performed by the input node or a preceding validation
node.
For more details see Validating messages and Validation properties.
Connecting the output terminals to another node
Connect the Out, Error, or Failure terminal of this node to another node in this message flow to process the message further, to process errors, or to send the message to an additional destination. If you do not connect the Error terminal, the message is discarded. If you do not connect the Failure terminal, the broker provides default error processing, see Handling errors in message flows.
Terminals and properties
The HTTPRequest 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 during processing in the node. |
Out | The output terminal to which the message is routed if it represents successful completion of the web service request, and if further processing is required within this message flow. |
Error | The output terminal to which messages that include an HTTP status code that is not in the range 200 through 299, including redirection codes (3xx) if you have not set the property Follow HTTP(s) redirection property, is routed. |
The following tables describe the node properties. The column headed M indicates whether the property is mandatory (marked with an asterisk on the panel 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 broker archive file to deploy it).
The HTTPRequest node Description properties are described in the following table.
Property | M | C | Default | Description |
---|---|---|---|---|
Node name | No | No | The node type, HTTPRequest | 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 HTTPRequest node Basic properties are described in the following table.
Property | M | C | Default | Description | mqsiapplybaroverride command property |
---|---|---|---|---|---|
Web service URL | Yes | Yes | The URL for the web service. You must provide
this in the form http://hostname[:port]/[path] where
|
URLSpecifier | |
Request timeout (sec) | Yes | Yes | 120 | The time in seconds that the node waits for a response from the web service. The valid range is 1 through (231)-1. You cannot enter a value that represents an unlimited wait. The timeout might take up to one second longer than the specified value. | timeoutForServer |
The HTTPRequest node HTTP Settings properties are described in the following table.
Property | M | C | Default | Description | mqsiapplybaroverride command property |
---|---|---|---|---|---|
HTTP(S) proxy location | No | Yes | The proxy server to which requests are sent. This value must be in the form hostname:port. | httpProxyLocation | |
Follow HTTP(S) redirection | No | No | Cleared | If you select the check box, redirections are followed. If you clear this check box, redirections are not followed. | |
HTTP version | No | Yes | 1.0 | The HTTP version to use for requests. Valid values are 1.0 and 1.1. | httpVersion |
Enable HTTP/1.1 keep-alive | No | Yes | Selected (if HTTP version is 1.1) | Use HTTP/1.1 Keep-Alive. | enableKeepAlive |
HTTP method | No | No | POST | The HTTP method. Valid values are POST, GET, PUT, DELETE, and HEAD. By default, the HTTPRequest node uses the HTTP POST method when it connects to the remote web server. HEAD is used to determine whether a service is available - for example, by a Network Dispatcher trying to work out which servers are available - and sends back the correct headers (including content-length) but no body data. | |
Use compression | No | Yes | None | This property controls whether the content of
the HTTP request is compressed. You can choose a value from none, gzip, zlib (deflate), and deflate. If the request is compressed,
the Content-Encoding header is set to indicate that the content is
compressed. zlib (deflate) represents RFC 1950 + RFC 1951 combined. deflate represents RFC 1951 only. |
requestCompressionType |
The HTTPRequest node SSL properties are described in the following table.
Property | M | C | Default | Description | mqsiapplybaroverride command property |
---|---|---|---|---|---|
Protocol | No | Yes | TLS | The SSL protocol to use when making an HTTPS request. | protocol |
Allowed SSL ciphers | No | Yes | A comma-separated list of ciphers to use when making an SSL request. The default value of an empty string means use all available ciphers. | allowedCiphers | |
Enable SSL certificate hostname checking | No | Yes | No | This property specifies whether the host name of the server that is receiving the request must match the host name in the SSL certificate. | hostnameChecking |
SSL client authentication key alias | No | Yes | "" (empty string) | This property specifies an SSL authentication alias for the client-side of an HTTP connection. Taking the default value means that the first appropriate key is chosen for you automatically. | keyAlias |
The HTTPRequest node Response Message Parsing properties are described in the following table.
Property | M | C | Default | Description |
---|---|---|---|---|
Message domain | No | No | BLOB | The domain that is used to parse the message. If the field is blank then the default is BLOB. |
Message model | No | No | Cleared | The name or location of the message model schema file in which the message is defined. This list is populated with all available message model schema files for the Message domain that you have selected. |
Message | No | No | Cleared | The name or location of the message root within your message model schema file. This list is populated with all available messages that are defined in the Message model that you have selected. |
Physical format | No | No | Cleared | The name of the physical format of the message. If you are using the MRM or IDOC parser, select the physical format of the incoming message from the list. This list includes all the physical formats that you have defined for the selected message model. If you set the Message domain property to DataObject, you can set this property to XML or SAP ALE IDoc. Set this property to SAP ALE IDoc when you have to parse a bit stream from an external source and generate a message tree. |
The HTTPRequest node Parser Options properties are described in the following table.
Property | M | C | Default | Description |
---|---|---|---|---|
Parse timing | No | No | On Demand | This property controls when a response message
is parsed. Valid values are On
Demand, Immediate,
and Complete. For a full description of this property, see Parsing on demand. |
Build tree using XML schema data types | No | No | Cleared | This property controls whether the XMLNSC parser creates syntax elements in the message tree with data types taken from the XML schema. You can select this property only if you set the Validate property on the Validation tab to Content or Content and Value. |
Use XMLNSC compact parser for XMLNS domain | No | No | Cleared | This property controls whether the XMLNSC Compact Parser is used for messages in the XMLNS Domain. If you set this property, the response message data is displayed under XMLNSC in nodes that are connected to the output terminal when the input MQRFH2 header or Response Message Parsing properties Domain is XMLNS. |
Retain mixed content | No | No | Cleared | This property controls whether the XMLNSC parser creates elements in the message tree when it encounters mixed text in a response message. If you select the check box, elements are created for mixed text. If you clear the check box, mixed text is ignored and no elements are created. |
Retain comments | No | No | Cleared | This property controls whether the XMLNSC parser creates elements in the message tree when it encounters comments in a response message. If you select the check box, elements are created for comments. If you clear the check box, comments are ignored and no elements are created. |
Retain processing instructions | No | No | Cleared | This property controls whether the XMLNSC parser creates elements in the message tree when it encounters processing instructions in a response message. If you select the check box, elements are created for processing instructions. If you clear the check box, processing instructions are ignored and no elements are created. |
Opaque elements | No | No | Blank | This property is used to specify a list of elements in the response message that are to be opaquely parsed by the XMLNSC parser. Opaque parsing is performed only if validation is not enabled (that is, if the Validate property is set to None); entries that are specified in Opaque Elements are ignored if validation is enabled. |
The HTTPRequest node Error Handling properties are described in the following table.
Property | M | C | Default | Description |
---|---|---|---|---|
Replace input with error | No | No | Selected | If you select this check box, the input message content is replaced by the error message content. If you clear this check box, you must specify Error message location. |
Error message location | Yes | No | OutputRoot | The start location at which the parsed elements from the web service error bit stream are stored. This property takes the form of an ESQL field reference. |
The HTTPRequest node Advanced properties are described in the following table.
Property | M | C | Default | Description | mqsiapplybaroverride command property |
---|---|---|---|---|---|
Use whole input message as request | No | No | Selected | If you select this check box, the whole input message body is to be passed to the web service. If you clear this check box, you must select Request message location in tree. | |
Request message location in tree | Yes | No | InputRoot | The start location from which the bit stream is created for sending to the web service. This property takes the form of an ESQL field reference. | |
Replace input message with web-service response | No | No | Selected | If you select this check box, the web service response message replaces the copy of the input message as the content of the output message that is created. If you clear this check box, you must select Response message location in tree. | |
Response message location in tree | Yes | No | OutputRoot | The start location at which the parsed elements from the web service response bit stream are stored. This property takes the form of an ESQL field reference. | |
Generate default HTTP headers from input | No | No | Selected | If you select this check box, an HTTPRequestHeader is generated. If you clear this check box, a valid HTTPRequestHeader must exist in the input message. | |
Accept compressed responses by default | No | Yes | Cleared | This property indicates whether the request
node handles compressed responses by default. If the request header
does not contain an Accept-Encoding header and this option is selected,
the node sets the Accept-Encoding header to "gzip, deflate", and any
compressed response that is received is decompressed by the node.
If the message propagated to the Request node includes an Accept-Encoding header, the message flow or client application should handle any compressed response. Therefore selecting this option has no effect in that case. |
acceptCompressedResponses |
The HTTPRequest node Validation properties are described in the following table.
For a full description of these properties see Validation properties.
Property | M | C | Default | Description | mqsiapplybaroverride command property |
---|---|---|---|---|---|
Validate | No | Yes | None | 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 using monitoring properties for details. You can enable and disable events that are shown here by selecting or clearing the Enabled check box. |
Local environment overrides
Setting | Description |
---|---|
RequestURL | Overrides the Web
service URL property on the node. For example:
|
Timeout | Overrides the Request
timeout (sec) property on the node. For example:
|
TimeoutMillis | Overrides the Request
timeout (sec) property on the node. For example:
This
property defines the timeout in milliseconds. The value of TimeoutMillis
overrides the value for Timeout if both values are set. |
ProxyURL | Overrides the HTTP(S)
proxy location property on the node. For example:
|
RequestLine.RequestURI | Overrides the RequestURI, which
is the path after the URL and port. For example:
|
RequestLine.HTTPVersion | Overrides the HTTP
version property on the node. For example:
|
KeepAlive | Overrides the Enable
HTTP/1.1 keep-alive property on the node. For example:
|
RequestLine.Method | Overrides the HTTP
method property on the node. For example:
|
SSLProtocol | Overrides the SSLProtocol. For example:
Valid values are: SSL, SSLv3, TLS, TLSv1, TLSv1.1, TLSv1.2, SSL_TLS, and SSL_TLSv2 |
SSLCiphers | Overrides the Allowed
SSL Ciphers property on the node. For example:
|
ProxyConnectHeaders | Specifies
additional headers that are used if the outbound request is an SSL
connection through a proxy. These additional headers are sent with
the initial CONNECT request to the proxy. For example, you can send
proxy authentication information to a proxy server when you are using
SSL. You can send multiple headers but each one must be separated
by a carriage return and a line feed (ASCII 0x0D 0x0A), in accordance
with RFC2616; for example:
This setting is used only if the request is an SSL request
through a proxy server. To send proxy authentication information for
a non-SSL request, specify the individual headers in the HTTPRequestHeader
folder, as shown in the following example:
|
UseFolderMode | Sets the UseFolderMode. Use
for bitstream generation; for certain parsers this changes the output
bitstream. For example:
|
QueryString | Allows the setting of outbound query string
parameters. Each parameter must be set individually. For example:
The
above ESQL results in the following query string being encoded (according
to http://tools.ietf.org/html/rfc3986) and sent
with the outbound request:
If
the destination URL already has one or more query parameters, additional
parameters specified here are appended to the existing list. |
QueryStringCCSID | Specifies that, before encoding, the query string
parameters must be converted into a character set other than the default,
which is UTF-8. Any query string parameters are first converted into
the specified CCSID before the resulting string is encoded, according
to RFC3986.
For example:
The
above ESQL results in any QueryString parameters being converted to
the 943 code page before they are encoded. Note: Any query string
parameters must contain the data in unicode. |
Compression | Overrides the Use
compression property on the node. For example:
To set a minimum size (in bytes)
at which compression is applied, use the following override:
|
Working with WrittenDestination data
WrittenDestination = (
HTTP = (
RequestURL = 'http://127.0.0.1:7800/HTTPFLOW' (CHARACTER)
Compression = (
OriginalSize = 53 (INTEGER)
CompressedSize = 71 (INTEGER)
)
)
)