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..
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
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.)
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.
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