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.
This topic contains the following sections:
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:
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.
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);
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: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.
- Request A, with a request timeout of 1 second
- Request B, with a request timeout of 4 seconds
- Request C, with no request timeout
- 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
- Request A, with an individual request timeout of 10 seconds
- Request B, with no individual request timeout
- Request C, with no individual request timeout
- 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:
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
|
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. |
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. |
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.