Adding an invoke assembly action to retrieve documents
The invoke assembly action retrieves a document from a specified target URL from within the assembly.
About this task
request.headers context. The
set variable action must be before the invoke action. For more information, see Adding a set variable assembly action.After the invoke action receives the response, it stores the response in the variable that is
specified by the Output property. The variable must be a writable variable in
the API context. By default, the response is stored in the message variable. When
an assembly contains multiple invoke actions, you can store the output of each invoke action in a
different variable.
Content-Type: multipart/related. The following excerpt shows an
example of a multipart request. The root part and attachments are separated by boundaries. The root
part contains a JSON document and the two attachments contain the base64-encoded text and
document.POST /mime-test/v1/base HTTP/1.1
Host: localhost:2059
Content-Type: multipart/related; type="application/json"; boundary="----=_boundary"
Content-Length: 417
------=_boundary
Content-Type: application/json
Content-ID: start
{ "message": "hello" }
------=_boundary
Content-Type: text/plain
Content-Id: <secret>
Content-Transfer-Encoding: BASE64
c2VjcmV0IHRleHQgMTIzCg==
------=_boundary
Content-Type: text/xml; charset=utf-8
Content-Id: <data>
<msg>Hello</msg>
------=_boundary--- The assembly includes a parse action.
-
- Attachments in the request or response can be manipulated and sent back to the client.
- By default, the response is sent to the client in multipart format. Alternatively, you can clear
context.message.attachmentsto discard the attachments and send onlymessage.bodyto the client. For more information, see context object for the API gateway.
- The assembly does not include a parse action.
-
- For a multipart request where the
message.bodyvariable is not changed, the invoke action keeps and passes the attachments to the server. - For a multipart request or response where the
message.bodyvariable is not changed, the result API action passes the attachments as the final response. - If the
message.bodyvariable is changed, attachments are discarded.
- For a multipart request where the
- When binary, indicates to package the payload as binary and send, regardless of the message type.
- When detect, indicates to detect the message type and send based on detected type. By default, the message type is detected.
- When GraphQL, indicates to package as GraphQL and send. If the message type is not GraphQL, the action fails.
- When JSON, indicates to package as JSON and send. If the message type is not JSON, the action fails.
- When XML, indicates to package as XML and send. If the message type is not XML, the action fails.
- Detect
- Indicates to detect the message type and send based on detected type. By default, the message type is detected.
- GraphQL
- Indicates to send GraphQL.
- JSON
- Indicates to send JSON.
- You can set whether to enable the Stop on error property.
- When enabled, specify which error conditions stop processing. The following choices are available.
- Connection error
- The action cannot establish a connection to the target URL. For example, the host is not reachable or the service is not available.
- SOAP error
- The action receives a 500 SOAP fault as response.
- Operation error
- The action establishes the connection and receives a non-2xx response.
When one of the selected error conditions occur, the following activities occur.- An error is triggered. A sample error message is as
follows.
{ name: 'ConnectionError', message: 'Invalid URL' } - The error data is written to the
error.variablevariable, where theerror.namevariable is set toConnectionError,SOAPError, orOperationError. - Assembly processing stops.
When enabled but error conditions are not specified or when not enabled, the action completes and continues to process the next action in the assembly. In these situations, the error data is written to theoutput.status.conditionvariable. For illustrative purposes,foois the output variable.ConnectionErrorfoo.status.connectionErrorSOAPErrorfoo.status.soapErrorOperationErrorfoo.status.operationError
- When enabled, specify which error conditions stop processing. The following choices are available.
- Whether to attempt to resolve redirects. Some protocols generate redirects as part of the protocol; for example, HTTP response code 302. By default, does not resolve redirects.
- Whether to restrict transactions to HTTP/1.0. The property is deprecated. You must specify the HTTP protocol version.
- The HTTP protocol version for the connection. When HTTP/2, whether the connection must use
HTTP/2.
When the protocol version is HTTP/1.1, the connection can request a WebSocket upgrade. The Allow WebSocket upgrade (deprecated) property in this action is deprecated. Instead, define a WebSocket upgrade assembly action and assign it to the assembly. For more information, see Adding a WebSocket upgrade assembly action.
- Whether to send documents to the server with
Transfer-Encoding: chunked. When the service uses HTTP/1.1, the body of the document can be delimited by eitherContent-LengthorTransfer-Encoding: chunked. While all servers can interpretContent-Length, many applications fail to understandTransfer-Encoding: chunked. For this reason,Content-Lengthis the standard method.The use of
Content-Lengthinterferes with the ability of the service to fully stream. If you must stream full documents to the target server, set this property toon.When enabled, the server must be RFC 2616 compatible. Unlike all other HTTP/1.1 features that can be negotiated down at run time, you must know beforehand that the target server is RFC 2616 compatible.
- Whether to enable HTTP persistent connections.
- With the cache type, you can set whether and how to cache documents in the response.
- No cache
- Does not cache any documents.
- Protocol
- Uses the cache behavior that is defined by the
Cache-Controlheaders on the request and response. When used, the invoke action forwards theCache-Controlheader from the client to the target and sends theCache-Controlheader from the target back to the client. - Time to live
- Keeps documents in the cache for a specified time.
- You must specify the validity period for documents in the cache.
- You can control whether to cache responses to POST and PUT requests. By default, responses to POST and PUT requests are not cached.
- You can specify a cache key, which is the unique identifier, for the document cache entry. By default, the URL is the cache key.
- Whether to decode request parameters that are referenced in the target URL.
- Whether to encode the + character in a request parameter that is referenced in the target URL.
- Whether to include the payload for a
DELETErequest. - Whether to inject the default
User-Agentheader to the API request when it is not found in the incoming request. By default, this header is injected when not found in the incoming request. - Whether to inject proxy headers to the API request. The proxy headers are
X-Forwarded-For,X-Forwarded-Host,X-Forwarded-Port, andX-Forwarded-Proto. By default, these headers are not injected. - The control list to manage whether headers are accepted or rejected. By default, all headers are accepted.
- The control list to manage whether URL parameters are accepted or rejected. By default, all URL
parameters are rejected.
The correlation path indicates the part of the API definition that correlates with the assembly action. This path is included in the debug data for use by debugging tools. For example, when an API configuration is specified in an OpenAPI document with gateway extensions, this path is the JSON path to the policy in the IBM extensions section of the document. The path can be expressed in any form that the debugging tool can correlate to the API definition.