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-index property. 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.
DNs
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. PingDirectory Server maps all attributes in a detected change from source to destination attributes using the attribute maps defined in the Sync Class.

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 dn,uid, uid,employeeNumber and cn,employeeNumber to correlate entries in LDAP deployments. PingDirectory Server will search for a corresponding entry that has the same dn and uid values. If the search fails, it then searches for uid and employeeNumber.

Again if the search fails, it searches for cn and 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.

Attributes
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 cn, uid, 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 attribute, 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-pattern property, 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 adminName attribute on the destination should be a copy of the name attribute on the source, but only if the isAdmin attribute 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.