Using HTTP asynchronous request-response

You can make HTTP requests and receive a response asynchronously using the HTTPAsyncRequest and HTTPAsyncResponse nodes, or the SOAPAsyncRequest and SOAPAsyncResponse nodes, in your message flow.

The SOAPAsyncRequest node supports two methods of asynchronous requests when using HTTP transport:
  1. Using WS-Addressing to direct the response to the paired SOAPAsyncResponse node. The SOAPAsyncRequest node waits for the HTTP 202 acknowledgment before continuing with the message flow, and the SOAPAsyncRequest node blocks if the acknowledgment is not received. A new HTTP connection is made by the backend server to reply to the SOAPAsyncResponse node. This is the default behavior.
  2. Using HTTP asynchronous request-response. When the SOAPAsyncRequest property Use HTTP asynchronous request-response is selected, the SOAPAsyncRequest node passes the HTTP socket to the paired SOAPAsyncResponse node to allow the backend server to reply using the same socket. When this option is selected, WS-Addressing headers are sent, but are not required to be understood by the backend server. The WS-Addressing headers are not marked as mustUnderstand, and the replyTo header is set to anonymous. The node therefore uses asynchronous HTTP socket handling instead of WS-Addressing to make HTTP requests and receive an asynchronous response.
The HTTPAsyncRequest node always uses asynchronous HTTP socket handling to make asynchronous requests and responses.

The asynchronous request nodes return control to the flow without waiting for a response. This action frees the request thread to handle further requests, while the response is handled by the paired response node on a different thread and in a new transaction. The response node can be in a separate message flow, but it must be in the same integration server as its paired request node.

The HTTP asynchronous request-response behavior is asynchronous only because IBM® App Connect Enterprise treats the request and the response as such, enabling the message flow to retrieve the next message without waiting for the response from the asynchronous request. The backend server sees the request-response as a typical synchronous HTTP request.

Scenarios

You might want to use HTTP asynchronous request-response in the following situations:
  • When interacting with a backend server that has a high latency, using synchronous HTTP requests might result in many outstanding requests which require large numbers of threads to make enough simultaneous connections to the backend server. Using asynchronous HTTP socket handling instead allows the response to be decoupled from the request.
  • Using HTTP asynchronous request-response in the SOAPAsyncRequest is an alternative to using WS-Addressing with a non-anonymous replyTo header.
For information about using HTTP asynchronous request-response with the SOAPAsyncRequest node, see Choosing asynchronous behavior for the SOAPAsyncRequest node.

Limitations

When using the HTTPAsyncRequest node, or the SOAPAsyncRequest node with HTTP asynchronous request-response, the following limitations apply:
  • Redirection is not supported. Messages with a redirection status code (3xx) are treated as an error, and the response is routed to the Error terminal of the response node while following the properties specified on the Error tab.
  • WS-RM is not compatible with using HTTP asynchronous request-response.