Request Properties

Updated on 17 Nov 2022

Dark

Light
PDF

Article summary

Did you find this summary helpful?

Thank you for your feedback

Definition

All request properties are contained within the request object in the IAP Service Instance Configuration for the adapter. These tell the adapter libraries some specifics about how to handle the request to the other system.

Property	Type	Required	Description
`number_redirects`	integer	No -> 0	If the adapter should allow redirects, this property tells the adapter how many redirects are allowed before returning an error.
`number_retries`	integer	Yes	The number of times to retry any request that failed with the provided `limit_retry_error` before the adapter will return an error.
`limit_retry_error`	integer or array	Yes	An error that has been defined as one the adapter should re-attempt. Supports an array of integers or an array containing ranges. Example: [401,“500-599”]
`failover_codes`	array of integers	No	List of error codes used by the adapter to send an error response that notifies the platform to attempt the request through another adapter, if available.
`attempt_timeout`	integer	Yes	Defines the time in milliseconds (ms) after which the adapter should abort a request. The request may be retried again after a healthcheck returns successfully.
`global_request`	object	No	Provides a way to have global data used in all requests the adapter makes. It is key that all values provided here are static. Dynamic values are handled through the adapter.js. `payload`: If every payload sent to the other system is supposed to contain specific fields with static values, that part of the payload can be set here. `uriOptions`: If every request sent to the other system is supposed to contain query fields with static values, those options can be defined here. `addlHeaders`: If every request sent to the other system is supposed to contain specific headers with static values, those headers can be defined here. `authData` : If every request sent to the other system is supposed to contain authentication data with static values, that data can be defined here.
`healthcheck_on_timeout`	boolean	Yes	Defines whether a healthcheck should be performed when a request has timed out to make sure the other system is still available.
`return_raw`	boolean	No	Tells the Adapter Utils to return the raw response along with the results being returned. This is helpful to collect mock data.
`archiving`	boolean	No	Deprecated. Do not use except in a lab environment for testing the adapter.
`return_request`	boolean	No	Determines if you want the information sent on the request to be returned. Note: Understand that sometimes the request can include authentication information, so if you are asking for this, that information may be returned to the calling method.

Example Scenario

In this example, there are no redirects.
The adapter will retry up to 5 times when the request times out or a 501 error is returned on the request.
There is no failover to other adapters.
If we have not received a response on the request after 1 minute (60s – 60000ms), the system will abort and resend the request.
Every call to this system should have a header of “SimonSays” with a value of “Please”.
When there is a timeout (no response on a request for 1 minute), we will run a healthcheck.

IAP Service Instance Configuration Properties for the Adapter

"request": {
  "number_redirects": 0,
  "number_retries": 5,
  "limit_retry_error": 501,
  "failover_codes": [],
  "attempt_timeout": 60000,
  "global_request": {
    "payload": {},
    "uriOptions": {},
    "addlHeaders": {
      "SimonSays": ”Please",
    },
    "authData": {}
  },
  "healthcheck_on_timeout": true,
  "return_raw": false,     
  "archiving": false
},

Was this article helpful?

What's Next

Healthcheck Properties

Table of contents

Definition