- Overview
- The ForgeRock Identity Connector Framework (ICF)
- Supported Connectors
- Adobe Marketing Cloud Connector
- AS400 connector
- AWS Connector
- Cerner Connector
- CSV File Connector
- Database Table Connector
- DocuSign Connector
- Epic Connector
- Google Cloud Platform Connector
- Google Apps Connector
- Groovy Connector Toolkit
- HubSpot Connector
- Kerberos Connector
- LDAP Connector
- Marketo Connector
- MongoDB Connector
- MS Graph API Java Connector
- PeopleSoft Connector
- PowerShell Connector Toolkit
- IBM RACF Connector
- Salesforce Connector
- SAP Connector
- Before You Start
- Using the SAP Connector With an SAP HR System
- Using the SAP Connector to Manage SAP Basis System (R/3) Users
- Configuring the SAP Connector For SNC
- Implementation Specifics
- OpenICF Interfaces Implemented by the SAP Connector
- SAP Connector Configuration
- SAP S/4HANA Connector
- SCIM Connector
- Scripted REST Connector
- Scripted SQL Connector
- ServiceNow Connector
- SSH Connector
- SAP SuccessFactors Connector
- Workday Connector
- Configure Connectors
- Sample Provisioner Files
- Configure Connectors With the Admin UI
- Configure Connectors Over REST
- Connector Reference Properties
- Pool Configuration
- Operation Timeouts
- Connection Configuration
- Synchronization Failure Configuration
- Configure How Results Are Handled
- Specify Which Attributes Are Updated
- Set the Supported Object Types
- Configure Operation Options
- Remote Connectors
- Check External System Status Over REST
- Remove a Connector
- ICF Interfaces
- ICF Operation Options
- Connection Pooling Configuration
- IDM Glossary
Synchronization Failure Configuration
Important
Connectors continue to be released outside the IDM release. For the latest documentation, refer to the ICF documentation.
The syncFailureHandler
object specifies what should happen if a liveSync operation reports a failure for an operation. The following example shows a synchronization failure configuration:
{ "maxRetries" : 5, "postRetryAction" : "logged-ignore" }
maxRetries
positive integer or
-1
, requiredThe number of attempts that IDM should make to process a failed modification. A value of zero indicates that failed modifications should not be reattempted. In this case, the post retry action is executed immediately when a liveSync operation fails. A value of -1 (or omitting the
maxRetries
property, or the entiresyncFailureHandler
object) indicates that failed modifications should be retried an infinite number of times. In this case, no post retry action is executed.postRetryAction
string, required
The action that should be taken if the synchronization operation fails after the specified number of attempts. The post retry action can be one of the following:
logged-ignore
- IDM ignores the failed modification, and logs its occurrence.dead-letter-queue
- IDM saves the details of the failed modification in a table in the repository (accessible over REST atrepo/synchronisation/deadLetterQueue/provisioner-name
).script
specifies a custom script that should be executed when the maximum number of retries has been reached.
For more information, see "Configure the LiveSync Retry Policy".