How the DirXML or Identity Manager Resync process works

  • 3798038
  • 19-Nov-2007
  • 26-Apr-2012

Environment

Novell Identity Manager - Nsure Identity Manager 2.0
Novell Identity Manager DirXML 1.0
Novell Identity Manager DirXML 1.1
Novell Identity Manager DirXML 1.1a
Novell Identity Manager 3.0
Novell Identity Manager 3.5
DirXML 1.1a
IDM2

Situation

How the DirXML Resync process works.

Resolution

For most drivers, the individual driver documents contain a section called"Synchronizing Objects" which explain how it works in Versions of IDM from 3.0 and on.

The document below explains driver and object resynchronization in DirXML 1.1a and IDM2.

Driver resynchronization was broken in DirXML 1.0 and 1.1 and is therefore not discussed further.

What is Resync?

The actions commonly referred to as "resync" in DirXML refer to several different but related actions:

  1. The resynchronization (or merging) of attribute values of an object in eDirectory with the corresponding attribute values of an associated object in a connected system.
  2. 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).
  3. 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).
  4. 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.

Object Resynchronization

When is it done?

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

  1. A event element is submitted on the Subscriber or Publisher channel.

A event element is submitted on the Subscriber channel in the following circumstances:

  1. 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.)
  2. An object synchronization command is read from the driver's cache.

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

    1. A driver submits a event element. No known driver currently does this.
    2. The DirXML Engine submits a event element for each object found as the result of a "migrate-into-NDS" query. These events are submitted using the Subscriber thread, but are processed using the Publisher channel filter and Policies.
  1. An event (real or synthetic) is submitted on a channel and the channel Matching Policy finds a matching object in the target system.
  2. An 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.
  3. An event is submitted on the Publisher channel and an object is found in eDirectory that already has the association value reported with the event.

The DirXML Engine generates synchronization requests for zero or more objects in the following cases:

1.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.

2.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"?

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:

  1. Find all objects that:
    1. Have an entry modification timestamp greater than or equal to the starting filter time

–and–

    1. Have a DirXML-Associations attribute value that references the driver being resynchronized.
  1. Find all objects that have an entry creation timestamp greater than or equal to the starting filter time.
  2. Add a synchronize object command to the driver cache for each unique object found as a result of step 1 and step 2.

What does it mean?

Once the DirXML Engine determines an object is to be synchronized the following occurs:

  1. Each system (eDirectory and the connected system) are queried for all attribute values in the appropriate filters.
    1. eDirectory is queried for all values in the Subscriber filter (and that are marked for synchronization if DirXML 2).
    2. The connected system is queried for all values in the Publisher filter (and that are marked for synchronization if DirXML 2).
  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:
    1. "Left = Right" indicates the left side receives all values from the right side.
    2. "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.
    3. "Left += Right" indicates the left side adds the right side values to the left side’s existing values.
    4. "Left = Left + Right" indicates the left sides receives the union of the values of the left and right sides.

Attribute is sync both and merge authority is default

eDirectory

Application

Single-valued

Multi-valued

empty

non-empty

empty

non-empty

Single- valued

empty

No change

App = eDir

No change

App = eDir[1]

non-empty

eDir = App

App = eDir

eDir = App

eDir += App

Multi-valued

empty

No change

App = eDir

No change

App = eDir

non-empty

eDir = App[1]

App += eDir

eDir = App

App = App + eDir

eDir = App + eDir

Attribute is in subscriber sync only or is sync both and merge authority is eDir

eDirectory

Application

Single-valued

Multi-valued

empty

non-empty

empty

non-empty

Single- valued

empty

No change

App = eDir

No change

App = eDir[1]

non-empty

App = empty

App = eDir

App = empty

App = eDir[1]

Multi-valued

empty

No change

App = eDir

No change

App = eDir

non-empty

App = empty

App = eDir

App = empty

App = eDir


Attribute is publisher sync or merge authority is application

eDirectory

Application

Single-valued

Multi-valued

empty

non-empty

empty

non-empty

Single- valued

empty

No change

eDir = empty

No change

eDir = empty

non-empty

eDir = App

eDir = App

eDir = App

eDir = App

Multi-valued

empty

No change

eDir = empty

No change

eDir = empty

non-empty

eDir = App[1]

eDir = App[1]

eDir = App

eDir = App

.

Formerly known as TID# 10087047