Considerations and limitations
This section describes limitations and other constraints to consider when synchronizing changes from a PingOne environment.
Bidirectional synchronization
If you plan on configuring bidirectional synchronization between PingOne and PingDirectory, make certain that you satisfy the following conditions:
-
Use separate worker apps for the source and destination.
-
To prevent the unnecessary duplication of changes, add the client ID of the destination worker app to the
actor-id-to-ignoreconfiguration attribute of the source. -
To ensure that no attribute mappings are mismatched, modify the reference
dsconfigbatch files.
Population management
If your PingOne environment features a large number of populations, or if you want to limit synchronized users to a specific set of populations, provide one or more population-to-synchronize configuration attributes to the source. The name or ID of the population can be used.
Synchronization delay
PingDataSync propagates changes throughout PingOne nearly in real time. However, a delay might occur between the time a change occurs in PingOne and the time it becomes available for PingDataSync to synchronize. To help ensure that no changes are missed, a default delay of 5 seconds has been configured within the sync source. For environments of sufficient size or with high rates of change, use the configuration attribute realtime-sync-polling-offset on the sync source to increase the delay.