DirXML Merge-Resync Process

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:

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:

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

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:

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 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:

Category#

DirXML

More Information#

There might be more information for this subject on one of the following:
Please see our Copyright And Intellectual Property Page and Standard Disclaimer Pages!