The Complete Synchronization Process – Part 4: Delta/Full Import/Synchronization Explained


In "The Complete Synchronization Process - Part 1: New User Synchronization", we covered the complete synchronization process as it relates to new objects.In "The Complete Synchronization Process - Part 2: Existing User Synchronization", we stepped through the sync process for modifying a preexisting user object. In "The Complete Synchronization Process - Part 3: Joins", we discussed joins. In the fourth (and final) installment in this series, I'd like to talk about the difference between full and delta import and synchronization run profiles.

When discussing new and existing user sync, it was mentioned that there are actually two types of imports and two types of synchronizations. Let us now dig deeper into the distinctions, there.

Terminology:

FI: Full Import

FS: Full Synchronization

DI: Delta Import

DS: Delta Synchronization

CS: Connector Space

MV: Metaverse

 

The very first run you will perform when building FIM (or adding a new data source) is a full import. During a full import, everything in the connected data source is brought into the connector space. The key point to remember about a full import is that, regardless of total number of objects or objects with changes, everything will be refreshed. In the below illustration, of the eight represented user objects, only one has changed (indicated in red). During the full import, all eight are (again) recreated in the connector space.

image

 

This contrasts with a delta import in that, unlike a full import, a delta brings in only changes. While there may be eight total objects in the connected data source, only two have changes (indicated in red). With a delta import, only those two changed users will be refreshed in the connector space.

image

 

This same logic carries over to synchronizations as well. Here we see a representation of a full synchronization. Even though only one of eight objects has changed in the connector space, a full synchronization will cause all six steps (filter/delete, join, project, import attribute flow, provision, export attribute flow) to be performed on all eight objects in the Metaverse.

image

 

Likewise, a delta synchronization will only cause the six synchronization steps to be performed on the users who have actually experienced a change. In the below illustration, we see that, of the eight connector space objects, only two have had a change (as indicated in red). As such, only those two objects are synchronized into the Metaverse.

image

 

 

Questions? Comments? Love FIM so much you can't even stand it?

 

EMAIL US>EMAIL US<

 

## http://blogs.msdn.com/connector_space ##

Comments (4)

  1. Hennie says:

    Finally, I understand the synchronization process, thank you.

  2. Kevin Lusty says:

    I’d like to see a part 5 that digs a little deeper into the following differences between a delta and full…

    The scenario is this: you ran a sync and have objects pending export in a connector space. Those objects are pending because you have not exported them to the target system yet, they’re just sitting there waiting to be exported… If you were to Preview one of those objects from the source system again, using a Full Sync Preview you would see the following in the preview results:

    “Auto-Deleted” followed by “Added”

    So during a Full Sync of that object, the pending export is whacked, then replaced by a fresh new pending export. This makes total sense to me; something could have changed, our rules fired again, so the new object is created.

    However, if you were to Preview the same object using a Delta Sync Preview you would NOT see this behavior… There is no status reported for provisioning at all, like it never happened. Turns out the rules extension IS called on both Delta and Full in this scenario, but on Delta the action is just thrown away silently by the server.

    Another difference between a delta and full sync can be further illustrated when a user object has a relationship to some other object… for example, the user object has a “building code” attribute and a “building name” attribute… a rules extension is used to calculate the name by looking up the code in the building object database. If the building name is changed in the building database, the name will not be recalculated on all the user objects with that building’s code unless a full sync is run…

  3. Thanks @ktackett. Great explanation! (Y)

  4. Louis Gonzalez says:

    Great explanation! Thank you.

Skip to main content