Retry provisioning less than 60 min apart

[cgurung (Chhiring Gurung)]

From ISC documentation, When Identity Security Cloud receives a retryable error during provisioning, it will retry the action a maximum of 3 times, 60 minutes apart.
Question: Can the provisioning retry 60 min apart time be reduced for webservice connector ?

[colin_mckibben]

Provisioning retries are configured per source by configuring retryableErrors under the connectorAttributes . In addition, provisioningMaxRetries and provisioningRetryThreshold can also be optionally specified to control the amount of retrying that is done.

curl --request PATCH '{api-url}/v3/sources/{id}' \
--header 'Content-Type: application/json-patch+json' \
--header 'Authorization: Bearer {token}' \
--data '[
    {
        "op": "add",
        "path": "/connectorAttributes/retryableErrors",
        "value": [
          "Connection reset",
          "Read time out"
        ]
    },
    {
        "op": "add",
        "path": "/connectorAttributes/provisioningRetryThreshold",
        "value": "1"
    },
    {
        "op": "add",
        "path": "/connectorAttributes/provisioningMaxRetries",
        "value": "3"
    }
]

• retryableErrors
  • A list of string specifying the retryable errors to match against.
  • e.g., retry on any error with “Connection timed out”
• provisioningRetryThreshold
  • A string specifying the retry looping threshold in minutes. Default is 1.
  • i.e., retry every X minutes.
• provisioningMaxRetries
  • A string specifying the maximum number of retries to attempt. Default is 3.
  • i.e., retry up to Y times

This show and tell provides more information about retry logic in connectors.

How to Configure Retries for Connector Aggregations and Provisioning Actions

Overview Connectors in both IdentityIQ and Identity Security Cloud support retryable errors during both aggregation and provisioning. This document showcases how to configure these. Aggregation Retries Identity Security Cloud, like IdentityIQ, has support built-in for aggregation retries. This is configured per source by configuring aggregationRetryErrors under the connectorAttributes. Additional options retryWaitTime and maxRetryCount can also be configured. curl --request PATCH '{api-url}/v3…

[cgurung (Chhiring Gurung)]

Hi @colin_mckibben
I added the provisioningRetryThreshold as “30” in one of our webservice sources and I’m assuming next retry will happen after 30 min, however on our prod tenant I’m still seeing retry happening on every 60 min.
When I check account activity I see there were 2 account request for 2 different source. 1 web service source have provisioningRetryThreshold as “30” and other AD source doesn’t. Does this impact in retry mechanism ?

[colin_mckibben]

Did you set the retryableErrors attribute? Are you sure the error you’re getting is added to retryableErrors. That could be one reason why the retry isn’t kicking off.

[cgurung (Chhiring Gurung)]

Hi @colin_mckibben
Yes I have added retryableErrors attributes as well.
“retryableErrors”: [
“java.lang.RuntimeException”,
“Downtime exception”,
“java.net.SocketTimeoutException”
]
and Error