PingDirectory

Configure notification mode

PingDataSync supports notification mode with the following components.

Use the create-sync-pipe-config tool

The create-sync-pipe-config tool supports the configuration of notification mode. Any pre-existing Sync Sources can be read from the local configuration (in the config.ldif file).

LDAP change log features required for notifications

The PingDirectory server and the Nokia 8661 Directory Server require the following advanced global change log properties: changelog-max-before-after-values and changelog-include-key-attribute.

These properties are enabled and configured during the create-sync-pipe-config configuration process on PingDataSync. The properties can also be enabled on the directory servers by using the dsconfig advanced properties setting on the Backend Changelog menu.

changelog-include-key-attribute

The changelog-include-key-attribute property specifies one or more attributes that should always be included in the change log entry. These are attributes needed to correlate entries between the source and destination, such as uid, employeeNumber, or mail. These properties are also needed for evaluating any filters in the Sync Class. For example, if notifications are only sent for user entries, and the Sync Class included the filter (objectclass=people), the objectclass attribute must be configured as a changelog-include-key-attribute so that the Sync Pipe can evaluate the inclusion criteria when processing the change. In standard mode, values needed in the filter are read from the entry itself after it is fetched instead of from the changelog entry. These attributes are always included in a change log entry, also called a change record, regardless if they have changed or not.

The changelog-include-key-attribute property causes the current (after-change) value of the specified attributes to be recorded in the ds-changelog-entry-key-attr-values attribute on the change log entry. This applies for all change types. During a delete operation, the values are from the entry before it was deleted. The key values are recorded on every change and override any settings configured in the changelog-include-attribute, changelog-exclude-attribute, changelog-deleted-entry-include-attribute, or changelog-deleted-entry-exclude-attribute properties in the directory server changelog. For more information, see Configuring the PingDirectory server.

Normal Lightweight Directory Access Protocol (LDAP)-to-LDAP synchronization topologies typically use dn as a correlation attribute. If dn is used as a correlation attribute only, the changelog-include-key-attribute property does not need to be set. However, if another attribute is used for correlation, this property must be set during the Sync Pipe configuration.

The LDAP change log attribute, ds-changelog-entry-key-attr-values, stores the attribute that is always included in a change log entry on every change for correlation purposes. In addition to regular attributes, virtual and operational attributes can be specified as entry keys.

To view an example, see the PingDirectory Server Administration Guide.

changelog-max-before-after-values

The changelog-max-before-after-values property specifies the maximum number of "before and after" values (default 200) that should be stored for any changed attribute in the change log. Also, when enabled, it will add the ds-changelog-before-values and ds-changelog-after-values attributes to any change record that contains changes (for Modify and ModifyDN).

The main purpose of the changelog-max-before-after-values property is to ensure that an excessively large number of changes is not stored for multi-valued attributes. In most cases, the directory server’s schema defines a multi-valued attribute to be unlimited in an entry. For example, if a group entry whose member attribute references 10000 entries, the desire might be to not have all of the attributes if a new member added.

If either the ds-changelog-before-values or the ds-changelog-after-values attributes exceed the count set in the changelog-max-before-after-values property, the attribute values are no longer stored in a change record, but its attribute name and number is stored in the ds-changelog-attr-exceeded-max-values-count attribute, which appears in the change record.

In addition to this property, set the use-reversible-form property to TRUE. This guarantees that sufficient information is stored in the change log for all operation types to be able to replay the operations at the destination. The create-sync-pipe-config tool configures these properties when it prepares the servers.

The changelog-max-before-after-values property configures the following change log attributes:

  • ds-changelog-before-values – Captures all "before" values of a changed attribute. It will store up to the specified value in the changelog-max-before-after-values property (default 200).

  • ds-changelog-after-values – Captures all "after" values of a changed attribute. It will store up to the specified value in the changelog-max-before-after-values property (default 200).

  • ds-changelog-attr-exceeded-max-values-count – Stores the attribute names and number of "before" and "after" values on the change log entry after the maximum number of values (set by the changelog-max-before-after-values property) has been exceeded. This is a multi-valued attribute with the following format:

    attr=attributeName,beforeCount=200,afterCount=201

    where attributeName is the name of the attribute and the beforeCount and afterCount are the total number of values for that attribute before and after the change, respectively. In either case (before or after the change), if the number of values is exceeding the maximum, those values will not be stored.

LDAP change log for notification and standard mode

Both notification and standard mode Sync Pipes can consume the same LDAP Change Log without affecting the other. Standard mode polls the change record in the change log for any modifications, fetches the full entries on the source and the destination, and then compares them for the specific changes. Notification mode gets the before and after values of a changed attribute to reconstruct an entry, and bypasses the fetch-and-compare phase. Both can consume the same LDAP Change Log with no performance loss or conflicts.

If the configuration obtains the change log through a PingDirectoryProxy server, the contents of the change log will not change as it is being read from the change logs on the directory server backend.