Considerations for synchronizing to database destination

When configuring a directory-to-database Sync Pipe, the following are recommended:

Identify the Object Classes

Create a Sync Class per object class, so that they can easily be distinguished and have different mappings and synchronization rules.

For each Sync Class, set the following items in the configuration menus using the dsconfig tool.

Set the Include-Filter Property: Make sure the include-filter property is set on the Sync Class configuration menu to something that will uniquely identify the source entries, such as objectClass=customer.
Create Specific Attribute Mappings: Create an attribute mapping for every Lightweight Directory Access Protocol (LDAP) attribute to be synchronized to a database column, add these to a single attribute map, and set it on the Sync Class. With this configured, the script does not need to know about the schema on the directory side. A constructed attribute mapping that maps a literal value to the objectClass attribute can be added to the script to determine the database entry type. For example, "account" → objectClass can be added, which would result in the constructed destination LDAP entry always containing an objectClass of "account". If needed, a mulit-valued conditional-value-pattern property can be used to conditionalize the attribute mapping based on the subtype of the entry or on the value of the attribute.
Create Specific DN Maps (optional): If necessary, create a distinguished name (DN) map that recognizes the DN’s of the source entries and maps them to a desired destination DN. In most cases, the script will use the attributes rather than the DN to figure out which database entry needs to be changed.
Set auto-mapped-source-attribute to "-none-": Remove the default value of "-all-" from the auto-mapped-source-attribute on the Sync Class configuration menu, and replace it with "-none-."

Configure Create-Only Attributes

Any attributes that should be included when created, but never modified (such as objectclass) should be specified on the Sync Pipe as a create-only attribute. If PingDataSync ever computes a difference in that attribute between the source and destination, it will not try to modify it at the destination. To avoid bidirectional loop-back, set the ignore-changes-by-[user\|dn] property on both Sync Sources when configuring for bidirectional synchronization.

Synchronizing DELETE Operations

On PingDirectory Server and Nokia 8661 Directory Server systems, configure the changelog-deleted-entry-include-attribute property on the changelog backend menu using the dsconfig tool. This property allows for the proper synchronization of DELETE operations. For more information, see Configure the PingDirectory server backend for synchronizing deletes.

Attribute-Synchronization-Mode for DBSync

For MODIFY operations, PingDataSync detects any change on the source change log, fetches the source entry, applies mappings, computes the equivalent destination entry, fetches the actual destination entry, and then runs a diff between the two entries to determine the minimal set of changes to synchronize. By default, changes on the destination entry are made only for those attributes that were detected in the original change log entry. This is configurable using the attribute-synchronization-mode property, which sets the type of diff operation that is performed between the source and destination entries.

If the source endpoint is a database server, set the attribute-synchronization-mode property to all-attributes on the Sync Class configuration menu. The diff operation will consider all source attributes. Any that have changed will be updated on the destination, even if the change was not originally detected in the change log. This mode is useful when a list of changed columns in the database might not be available. If both endpoints are directory servers, use the default configuration of modified-attributes-only to avoid possible replication conflicts.

Handling MODDN Operations

The concept of renaming an entry (modifyDN) does not have a direct equivalent for relational databases. The JDBCSyncDestination API does not handle changes of this type. Instead, the modifyEntry() method is called as if it is a normal change. The extension can verify if the entry was renamed by looking at the SyncOperation that is passed in (syncOperation.isModifyDN()). If true, the fetchedDestEntry parameter will have the old DN. The new DN can be obtained by calling syncOperation.getDestinationEntryAfterChange().