Overview#

The DirXML Merge and Resync processes are the same process differentiated only on how the process is started.

The DirXML Merge-Resync Process utilizes the Merge Processor to preform the operation regardless of how the process was initialed.

Normally, Resync term is used when the process is associated with actions performed administratively where the Merge term is associated with with actions performed by the DirXML Engine. The DirXML Engine is indifferent to how the events are generated.

What is DirXML Merge?#

The actions commonly referred to as "resync" in DirXML refer to several different but related actions:
  • The re-synchronization (or merging) of attribute values of an object in eDirectory with the corresponding attribute values of an associated object in a connected system.
  • The migration of an eDirectory object which does not have an associated connected system object into the connected system (i.e., the creation of a new object in the connected system).
  • The generation of the list of objects to submit to the driver's Subscriber channel for resynchronization or migration in response to a user request (a manual resync).
  • The generation of the list of objects to submit to the driver's Subscriber channel for resynchronization or migration in response to enabling a formerly disabled driver, or in response to a cache error.

When is DirXML Resync Performed?#

The DirXML Engine performs object resynchronization or merging in the follow circumstances:

Submission on the Subscriber Channel or Publisher Channel#

A sync event element is submitted on the Subscriber or Publisher channel. A sync event element is submitted on the Subscriber channel in the following circumstances:
  • The state of the object's association value is set to "manual" or "migrate". (This causes an eDirectory event which in turn causes the DirXML caching system to queue an object synchronization command in the affected driver's cache.)
  • An object synchronization command is read from the driver's cache.

A sync event is submitted on the Publisher channel in the following circumstances:

    • A driver submits a sync event element. No known driver currently does this.
    • The DirXML Engine submits a sync event element for each object found as the result of a "migrate-into-NDS" query. These sync events are submitted using the Subscriber thread, but are processed using the Publisher channel filter and Policies.

A Matching Policy Set finds a matching object#

An add event (real or synthetic) is submitted on a channel and the channel Matching Policy finds a matching object in the target system.

An Associated Object submitted on the Subscriber Channel#

An add event with an association is submitted on the Subscriber channel. This would normally only occur in exceptional cases, such as the bulk load of objects into eDirectory with DirXML-Associations attribute values.

Publisher Channel Already Associated#

An add event is submitted on the Publisher channel and an object is found in eDirectory that already has the association value reported with the event.

DirXML Engine Events#

The DirXML Engine generates synchronization requests for zero or more objects in the following cases:
  • The user issues a manual driver resynchronization request. This corresponds to the "Resync" button in the Driver Set property page in ConsoleOne, or to the"Synchronize" button on the iManager "DirXML Driver Overview" page.
  • The DirXML Engine encounters an error with the driver's cache and cannot recover from the cache error. The driver's cache is deleted and the engine generates object synchronization commands as detailed under "How does the Engine decide which objects to synchronize"?

Which objects to Synchronize#

How does the Engine decide which objects to synchronize?

The DirXML Engine processes both manually-initiated and automatically-initiated synchronization requests in the same manner. In particular, the only difference in the processing of manually-initiated vs. automatically-initiated driver resynchronization requests is the starting filter time used to filter objects being considered for resynchronization.

The starting filter time is used to filter objects that have modification and/or creation times that are older than the starting time specified with the resynchronization request.

For automatically-initiated driver resynchronization the starting filter time is obtained from the timestamps of cached eDirectory events. In particular, the starting filter time is the earliest time from the events cached for which haven't yet been successfully processed by the driver's Subscriber channel.

For manually-initiated driver resynchronization the default starting filter time is the earliest time in the eDirectory database. In DirXML 2 an explicit starting filter time may also be set. (In DirXML 1.1a there is no facility to set the starting filter time value for resynchronization when manually initiating driver resynchronization.)

The DirXML Engine creates a list of objects to be resynchronized on the Subscriber channel in the following manner:

  • Find all objects that: Have an entry modification timestamp greater than or equal to the starting filter time –and–
  • Have a DirXML-Associations attribute value that references the driver being resynchronized.

Find all objects that have an entry creation timestamp greater than or equal to the starting filter time.

Add a synchronize object command to the driver cache for each unique object found as a result of step 1 and step 2.

Resulting Logic#

Once the DirXML Engine determines an object is to be synchronized the following occurs:
  • Each system (eDirectory and the connected system) are queried for all attribute values in the appropriate Novell IDM Driver Filters.
    • eDirectory is queried for all values in the Subscriber filter (and that are marked for synchronization if DirXML 2).
    • The connected system is queried for all values in the Publisher filter (and that are marked for synchronization if DirXML 2).
  • The returned attribute values are compared and modification lists are prepared for eDirectory and the connected system according to the tables below. In the tables the following pseudo-equations are used:
    • "Left = Right" indicates the left side receives all values from the right side.
    • "Left = Right[1]" indicates the left side receives one value from the right side. Which value if there is more than one value is indeterminate.
    • "Left += Right" indicates the left side adds the right side values to the left side’s existing values.
    • "Left = Left + Right" indicates the left sides receives the union of the values of the left and right sides.

More Information#

There might be more information for this subject on one of the following:

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-9) was last changed on 18-Jan-2016 06:05 by Alexander McHugh