PingDataSync supports the following configuration parameters that determine how synchronization takes place between directories or databases:

Sync Pipe
Defines a single synchronization path between the source and destination topologies. Every Sync Pipe has one or more Sync Classes that control how and what is synchronized. Multiple Sync Pipes can run in a single server instance.
Sync Source
Defines the directory topology that is the source of the data to be synchronized. A Sync Source can reference one or more supported external servers.
Sync Destination
Defines the topology of directory servers where changes detected at the Sync Source are applied. A Sync Destination can reference one or more external servers.
External Server
Defines a single server in a topology of identical, replicated servers to be synchronized. A single external server configuration object can be referenced by multiple Sync Sources and Sync Destinations
Sync Class
Defines the operation types and attributes that are synchronized, how attributes and DNs are mapped, and how source and destination entries are correlated. A source entry is in one Sync Class and is determined by a base DN and LDAP filters. A Sync Class can reference zero or more Attribute Maps and DN Maps, respectively. Within a Sync Pipe, a Sync Class is defined for each type of entry that needs to be treated differently. For example, entries that define attribute mappings, or entries that should not be synchronized at all. A Sync Pipe must have at least one Sync Class but can refer to multiple Sync Class objects.
DN Map
Defines mappings for use when destination DNs differ from source DNs. These mappings allow the use of wild cards for DN transformations. A single wild card ("*") matches a single RDN component and can be used any number of times. The double wild card ("**") matches zero or more RDN components and can be used only once. The wild card values can be used in the to-dn-pattern attribute using {1} and their original index position in the pattern, or {attr} to match an attribute value. For example:

Regular expressions and attributes from the user entry can also be used. For example, the following mapping constructs a value for the uid attribute, which is the RDN, out of the initials (first letter of givenname and sn) and the employee ID (eid attribute).


The following illustrates a how a nested DIT can be mapped to a flattened structure.

Canvas 1 Layer 1 Nested DIT dc=example, dc=com st=TX o=accounts acctid=geneh sub=5127516011 acctid: genes st: TX Flattened DIT dc=example, dc=com o=accounts o=subscribers acctid=geneh sub=5127516011 acctid: genes st: TX Subscriber to Flattened Map from: *,**,dc=example,dc=com to: {1},acctid={acctid},o=accounts,st={st},dc=example,dc=com from: *,**,dc=example,dc=com to: {1},o=subscribers,dc=example,dc=com Subscriber to Nested Map * matches 1 RDN ** matches 0 or more RDN {1} substitute first wildcard {2} substitute second wildcard {attr} substitute attr value
Attribute Map and Attribute Mappings
Defines a mapping for use when destination attributes differ from source attributes. A Sync Class can reference multiple attribute maps. Multiple Sync Classes can share the same attribute map. There are three types of attribute mappings:
  • Direct Mapping – Attributes are directly mapped to another attribute: For example:
  • Constructed Mapping – Destination attribute values are derived from source attribute values and static text. For example:
  • DN Mapping – Attributes are mapped for DN attributes. The same DN mappings that map entry DNs can be referenced. For example: