Pending Provisioning Transactions retry

Hi community!

I have a ‘pending’ provisioning transaction in IIQ 8.4p2. It is pending because, at the time of execution, the Active Directory application was unavailable and execution ran into a timeout. Now AD is available again and I would expect a retry. The provisioning transaction does not appear to be retryable though..

My questions:

  • What task is responsible for retrying these actions?
  • How does IIQ determine what provisioning transactions are retryable?

Kind regards,
Pieter.

1 Like

check this thread: Provisioning Transactions Table - Compass

check this one,

Forcing Retry

Retryable errors are recorded as Pending transactions in the Provisioning Transactions table. Though these transactions will automatically retry after a configured interval, an administrator can override the retry interval and force a transaction to retry immediately. For example, suppose a network error causes a retryable error. Ten minutes later, the problem is fixed but the wait period on the retry is set for the transaction to retry after two hours. The administrator can speed up the process by forcing the retry to occur immediately after the network issue is resolved.

For any Pending transaction, a Retry button appears in the Actions column. These retryable transactions appear on both the All page and the Pending page and can be forced to retry from either page.

To force an immediate retry of a pending transaction, click its Retry button. The Retry Launched pop-up window appears to confirm that the retry has begun.

Other Option to cancel the pending one, like below

Pending Provisioning not clearing - IdentityIQ (IIQ) / IIQ Discussion and Questions - SailPoint Developer Community

Saw that one as well, but the problem is that mine (see screenshot) does not have the Retry button. I’m trying to figure out why.

Required Permissions

The Provisioning Transactions page, like all other pages in IdentityIQ, is available to any user with the SystemAdministrator capability or the FullAccessAdminConsole capability. Access to it can also be granted through any other capability (custom or default) by adding one of these two SPRights to any Capability object definition:

  • FullAccessProvisioningTransaction - grants access to act on transactions on this page as described in this document
  • ViewProvisioningTransaction - read-only access to this page (no ability to override, force retry, etc.)

@pdeloos this option only avalible for system admin and syslog administrator. are u checking with system admin ?

capability matrix : Capabilities Matrix 8.4 - Compass

Yes, I’m logging in as a system administrator.

what’s value in allowProvisioningMissingRequrements in system configuration ?

It’s false. What does this setting exactly do?

Manage Provisioning Transaction Results

mine has also false but i have below configuration, check if you have somthing different.


Click the gear icon > Global Settings > IdentityIQ Configuration > Miscellaneous.

Maximum Log Level to Success.

Enable Provisioning Transaction log = selected

Days before Provisioning transaction event deletion = 60

These settings control whether a transaction is logged or not. For me ‘enable provisioning transaction log’ is selected, the maximum log level is set to ‘success’ and the days before deletion is 30.

What I’m still interested to know is why my action is not retryable.

interesting case, what’s you have in FeaturesString for that app ? i am hoping this is not related but just curies to know.

SAILPOINT IDENTITY IQ: FeaturesString Available in Sailpoint IdenityIQ

IdentityIQ implements a workflow-based retry process. It is implemented in workflow subprocess: “Provision with retries” which is used by all LCM workflows and is called by Identity Request Provision workflow subprocess. Therefore, it’s in use by all major LCM request pathways

Number of retries and and how long to wait between retries is controlled by:
Workflow defaults
Connector Configuration (can override Workflow defaults)

In order for connector to retry, override in your specific Application XML:

<entry key="provisioningMaxRetries" value="4"/>
<entry key="provisioningRetryThreshold" value=“30"/>
<entry key="retryableErrors">
        <value>
          <List>
            <String>**Failed to connect to server**</String>
          </List>
        </value>
</entry>

Note: Add additional messages to your connector as shown above. Connector does a substring match on listed messages.

Once you configure above setting, if there is a retryable error message then you would see “Retry” enabled on Provisioning Transaction under admin console

Hope this helps.