RESTAsyncRequest node

Use the RESTAsyncRequest node with the RESTAsyncResponse node to construct a pair of message flows that interact asynchronously with an external REST API.

Purpose

You can use a RESTAsyncRequest node in a message flow to issue a REST request to an external REST API, and return control to the flow without waiting for a response. The response is received by a RESTAsyncResponse node, which can be in a separate message flow but must be in the same integration server. The nodes are used as a pair, and correlate responses against the original requests by using a unique identifier, which is specified on both nodes.

The RESTAsyncRequest node uses an imported Swagger document or an imported OpenAPI 3.0 document, in either JSON or YAML format. You can import the document from the toolkit workspace, the file system, or from a URL.

If you created a REST API from scratch in the IBM® App Connect Enterprise Toolkit, a Swagger document or an OpenAPI 3.0 document was created. You can import the document and use with the RESTAsyncRequest node. For more information about creating REST APIs, see Creating a REST API.

The RESTAsyncRequest node handles messages in the following message domains:

  • DFDL
  • XMLNSC
  • JSON
  • BLOB
  • MIME
  • XMLNS
  • MRM

The RESTAsyncRequest node is contained in the REST drawer of the palette, and is represented in the IBM App Connect Enterprise Toolkit by the following icon:

RESTAsyncRequest node icon

Using the RESTAsyncRequest node in a message flow

The RESTAsyncRequest node can be used in a message flow to invoke a REST API. Use this node together with a RESTAsyncResponse node, which handles the response to the request asynchronously. For more information about how to use these nodes, see Interacting asynchronously with REST APIs by using the RESTAsyncRequest and RESTAsyncResponse nodes.

You can store context data in the local environment, which can be retrieved later by the RESTAsyncResponse node. By using the RESTAsyncRequest and RESTAsyncResponse nodes, you can store a subtree of data under UserContext, and set a name-value pair. For example, to set the values by using an ESQL expression:
SET OutputLocalEnvironment.Destination.REST.Request.UserContext = 'Some important information';
SET OutputLocalEnvironment.Destination.REST.Request.UserContext.Name.FirstName = 'Fred';
SET OutputLocalEnvironment.Destination.REST.Request.UserContext.Name.Surname = 'Bloggs';
SET OutputLocalEnvironment.Destination.REST.Request.UserContext.MyData.Binary = CAST('A piece of data' AS BLOB CCSID 1208);
You can use a Mapping node to set a value, by mapping to the mixed child element OutputLocalEnvironment.Destination.REST.Request.UserContext.mixed. To use a Mapping node to create sub-elements, use user-defined elements or cast xsd:any and map to them. For example:
Using a Mapping node to set a user context value

To access the user context data after a RESTAsyncResponse node, read the value or children of the LocalEnvironment.REST.Response.UserContext environment variable.

Behavior of a node that adds a request to a group

When a supported node successfully processes a message for output, it adds the information about the request that was just sent to the group that was most recently created in the message flow. The reply ID that the group expects is determined automatically from the transport, and the folder name is taken from the Request folder property.

Overrides

By default, the output node adds the request to the most recently created group. If multiple groups are being constructed in the same thread, a local environment override can be used to specify the group ID of the target group: LocalEnvironment.Destination.GroupScatter.RequestNode.GroupId. Requests can be added only to a group that is in construction in the current message flow thread. An exception is issued if no such group is available.

Transactions

Where a transport is transactional, the message obeys the usual transactional rules for the given transport. However, the group information is updated outside of the scope of the transaction. Therefore, if the transaction and output message are rolled back, the request is still added to the group.

Errors

If the Add Request to Group property is set to true, and the Request folder property is blank, a configuration exception is issued. The thread context is used to determine which group to add a request to.

If the Add Request to Group property is set to true, but no group is in construction in this thread, an exception is issued.

If a group ID override is specified and the ID is invalid or does not correspond to a group that is in construction in the current thread, an exception is issued.

Request timeouts

You can use the Request timeout (secs) property to specify a timeout for an individual request that is part of a group, which is separate from the base timeout that is set on the group. If timeouts are set for individual requests, the timeout value for the group becomes the same as the timeout value of the individual request with the shortest timeout that has not yet received a reply.

For example, you might have a group with a base timeout of 5 seconds, and the following requests:
  • Request A, with a request timeout of 1 second
  • Request B, with a request timeout of 4 seconds
  • Request C, with no request timeout
The group will time out at the following times in the following circumstances:
  • After 1 second if no reply for request A is received, regardless of whether replies for request B or C are received
  • After 4 seconds if a reply for request A is received within 1 second, but no reply for request B is received, regardless of whether a reply for request C is received
  • After 5 seconds if a reply for request A is received within 1 second for request A, a reply for request B was received within 4 seconds, but no reply is received for request C
If any in-flight request has a request timeout, it takes priority over the group timeout. For example, you might have a group with a base timeout of 5 seconds and the following individual request timeouts:
  • Request A, with an individual request timeout of 10 seconds
  • Request B, with no individual request timeout
  • Request C, with no individual request timeout
This group will timeout in the following circumstances:
  • After 10 seconds if no response for request A is received, regardless of the status of requests B and C
  • After 5 seconds if a response for request A is received within those 5 seconds and no response for requests B or C are received (because the reply from request A removes the 10 seconds timeout and reverts to the 5 second timeout)
  • Immediately after the response for request A is received, if the response for request A is received after 5 seconds but before 10 seconds, and either request B or C has not replied. Note that if request A is received after 7 seconds and request C is received after 6 seconds, request C would still be marked as a completed request even though it was received after its default 5 seconds.

Terminals and properties

The RESTAsyncRequest 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 submission of the REST API request, and if further processing is required within this message flow.

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 BAR file to deploy it).

The RESTAsyncRequest node Description properties are described in the following table.

Property M C Default Description
Node name No No The node type, RESTAsyncRequest 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 RESTAsyncRequest node Basic properties are described in the following table.

Property M C Default Description mqsiapplybaroverride command property
Unique identifier Yes Yes   The unique identifier that links a pair of RESTAsyncRequest and RESTAsyncResponse nodes. asyncResponseCorrelator
Definitions file Yes No   The name of a file that contains the definitions for the REST API that you want to invoke. This file must be a valid Swagger 2.0 document or a valid OpenAPI 3.0 document. The document can be in either JSON or YAML format.  
REST API Specification version Yes No   Read only display of the specification version of the configured definitions file, which is shown as "swagger_2" for Swagger v2.0 or "openapi_3" for OpenAPI 3.0."  
Operation Yes No   The name of the operation in the REST API that you want to invoke.  
Security identity No Yes   The name of the security identity object that contains the user ID, password, and API key to be used by the integration server to authenticate to the REST API.
Use the mqsisetdbparms command to create and configure the security identity object, and to set the user ID, password, and API key to be accessed by the integration server . The credentials can be specified in the security identity in any one of the following combinations:
  • User ID and password
  • User ID, password, and API key
  • API key only

The default value for this property is an empty string, which signifies that the RESTAsyncRequest node does not attempt to authenticate to the REST API. For more information about REST API security identity support, see mqsisetdbparms command.

securityIdentity
Request timeout (sec) Yes Yes 120 The time in seconds that the node waits for a response from the REST API. 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
Base URL override No Yes   The base URL to use when you make an HTTP request to the REST API. By default, the base URL from the REST API definitions file is used. baseURL

The RESTAsyncRequest 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 https://hostname:port.

If the configured proxy server requires authentication, the credentials must be set by using the mqsisetdbparms command with the resource name httpproxy, or provided in the message flow. For more information, see Routing requests through an HTTP proxy server that has authentication enabled.

httpProxyLocation
Follow HTTP(S) redirection No No Cleared If you select the checkbox, redirections are followed. If you clear this checkbox, redirections are not followed.  
Enable HTTP/1.1 keep-alive No Yes Selected Use HTTP/1.1 Keep-Alive. enableKeepAlive
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 RESTAsyncRequest 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 you make an HTTPS request. protocol
Allowed SSL ciphers No Yes   A comma-separated list of ciphers to use when you make 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 hostname of the server that is receiving the request must match the hostname 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
Enable certificate revocation list checking No Yes Not selected This property specifies whether CRL checking should be enabled for SSL connections enableCRLCheck

The RESTAsyncRequest node Request properties are described in the following table.

Property M C Default Description
Parameters No No   The parameters table displays the current list of parameters for the operation that is selected on the Basic panel. For each parameter shown, you can specify an XPath or ESQL expression in the Expression column to specify a value (either a literal or a message tree path) for that parameter. Alternatively, the values for parameters can be provided in the LocalEnvironment.
Content-Type No No   The value of the Content-Type header to send in the request to the REST API. By default, the RESTAsyncRequest node determines a Content-Type to use based on the input message. For example, if the input message contains an XMLNSC message, the Content-Type header in the request is application/xml. You can select a Content-Type from the REST API definitions file, or you can specify your own Content-Type.
Input body location Yes No $Body The location in the incoming message tree from which data is retrieved to form the HTTP request body that is sent from the RESTAsyncRequest node to the REST API. The default value, $Body, represents the incoming message body. You can enter any XPath or ESQL expression that defines the location of the message tree to serialize and send to the REST API.

The RESTAsyncRequest node Response properties are described in the following table.

Property M C Default Description
Accept No No   The value of the Accept header to send in the request to the REST API. By default, the RESTAsyncRequest node sends an accept anything value of */*. You can select an Accept from the REST API definitions file, or you can specify your own Accept.
Accept compressed responses by default No Yes Selected This property specifies 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 RESTAsyncRequest node includes an Accept-Encoding header, the message flow or client application should handle any compressed response, in which case this property has no effect.

The RESTAsyncRequest node Security properties are described in the following table.

Property M C Default Description
Security profile No No None This property specifies the name of the security profile that defines the security operations that are completed by the node in the message flow.

For more information, see Security profiles and Creating a security profile.

If the configured REST API operation contains multiple "securityDefinitions" each of which requires a different set of credentials, you must create a separate "Security Profile" for each "securityDefinition". This can only be achieved by using LocalEnvironment overrides for ""Security Profile" as detailed in Using local environment variables with REST nodes.

The Group properties of the node are described in the following table:
Property M C Default Description
Add request to group No No False If selected, this property causes the request or output node to add the request to a group that is being built, and generate group information in the environment tree.
Request folder No (See note) No   The folder name in the group for the request that this node will make.
Request timeout (secs) No No   Use this property to specify a timeout for an individual request that is part of a group, which is separate from the base timeout that is set on the group.

If timeouts are set for individual requests, the timeout value for the group becomes the same as the timeout value of the individual request with the shortest timeout that has not yet received a reply.

Note: The Request folder is a mandatory property only if the Add Request to Group property is selected.
The Monitoring properties of the node are described in the following table.
Property M C Default Description
Events No No None Events that you define 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.

Local environment overrides

You can dynamically override the values that are configured on the RESTAsyncRequest node by using a compute node to set values in the local environment in the same way as setting values in other elements of a message. For more information, see Using local environment variables with REST nodes.