A Sync Class defines how attributes and DNs are mapped and how Source and Destination entries are correlated. For each Sync Pipe defined, define one or more Sync Classes with the following information:
- Evaluation Order
- If defining more than one Sync Class, the evaluation order of each Sync Class
must be determined with the
evaluation-order-indexproperty. If there is an overlap between criteria used to identify a Sync Class, the Sync Class with the most specific criteria is used first.
- Base DNs
- Determine which base DNs contain entries needed in the Sync Class.
- Include Filters
- Determine the filters to be used to search for entries in the Sync Source.
- Synchronized Entry Operations
- Determine the types of operations that should be synchronized: creates, modifications, and/or deletes.
- Determine the differences between the DNs from the Sync Source topology to the Sync Destination topology. Are there structural differences in each Directory Information Tree (DIT)? For example, does the Sync Source use a nested DIT and the Sync Destination use a flattened DIT?
- Destination Correlation Attributes
- Determine the correlation attributes that are used to associate a source entry
to a destination entry during the synchronization process. During the
configuration setup, one or more comma-separated lists of destination
correlation attributes are defined and used to search for corresponding source
entries. PingDataSync Server maps all attributes in a detected change from
source to destination attributes using the attribute maps defined in the Sync
The correlation attributes are flexible enough so that several destination searches with different combinations of attributes can be performed until an entry matches. For LDAP server endpoints, use the distinguished name (DN) to correlate entries. For example, specify the attribute lists
cn,employeeNumberto correlate entries in LDAP deployments. PingDataSync Server will search for a corresponding entry that has the same
uidvalues. If the search fails, it then searches for
Again if the search fails, it searches for
employeeNumber. If none of these searches are successful, the synchronization change would be aborted and a message logged.
To prevent incorrect matches, the most restrictive attribute lists (those that will never match the wrong entry) should be first in the list, followed by less restrictive attribute lists, which will be used when the earlier lists fail. For LDAP-to-LDAP deployments, use the DN with a combination of other unique identifiers in the entry to guarantee correlation. For other non- LDAP deployments, determine the attributes that can be synchronized across the network.
- Determine the differences between the attributes from the Sync Source to the
Sync Destination, including the following:
- Attribute Mappings – How are attributes mapped from the Sync Source to the Sync Destination? Are they mapped directly, mapped based on attribute values, or mapped based on attributes that store DN values?
- Automatically Mapped Source Attributes – Are there attributes that can
be automatically synchronized with the same name at the Sync Source to
Sync Destination? For example, can direct mappings be set for
telephoneNumber, or for all attributes?
- Non-Auto Mapped Source Attributes – Are there attributes that should not
be automatically mapped? For example, the Sync Source may have an
employee, while the Sync Destination may have a corresponding attribute,
employeeNumber. If an attribute is not automatically mapped, a map must be provided if it is to be synchronized.
- Conditional Value Mapping – Should some mappings only be applied some of
the time as a function of the source attributes? Conditional value
mappings can be used with the
conditional-value-patternproperty, which conditionalizes the attribute mapping based on the subtype of the entry, or on the value of the attribute. For example, this might apply if the
adminNameattribute on the destination should be a copy of the
nameattribute on the source, but only if the
isAdminattribute on the source is set to true. Conditional mappings are multi-valued. Each value is evaluated until one is matched (the condition is
true). If none of the conditional mappings are matched, the ordinary mappings is used. If there is not an ordinary mapping, the attribute will not be created on the destination.