The Complete Synchronization Process - Part 3: Joins
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 both of those, we mentioned joins and the sync step of the same name. With this post, I'd like to explain that in further detail. It is also worth noting that this post is in reference to the automatic process which occurs based on a met criteria, not the manual process of effecting a join as described here.
For this scenario to occur, we must first be in a state where a join is needed. Realistically, there are two principle situations in which joins are likely: 1. A disaster recovery scenario where the Metaverse and connector spaces have been deleted, and, 2. Bringing an additional data source into FIM (i.e., another AD or a SQL database) that contains users we already have. It is also worth noting that a join requires a unique value be present in each data source where the object exists so that we can use it as an anchor. Typical examples of this are values such as EmployeeID or sAMAccountName. In the below example, we are using EmployeeID. Note that this user object exists in both SQL and Active Directory, but it does not exist in either connector space or the Metaverse.
As before, our process begins with an import. In this example (SQL and AD), it doesn’t matter which is imported first. In fact, it is perfectly acceptable to perform two or more imports simultaneously (if the performance allows). In the below illustration, we see both imports running, simultaneously building their respective connector spaces.
Next, it is necessary for a synchronization to occur. In this example, it does not matter which runs first (so long as only one synchronization job runs at a time). That being said, there are scenarios where order absolutely matters. These situations we will discuss later. In this example, we’ll first sync the SQL MA. This will, as we know, project the shell object into the Metaverse.
As well as perform an import attribute flow. From here, we have a fully formed Metaverse object.
Next, we will perform a synchronization on the Active Directory management agent. Now, however, the second step (join) occurs.
Here’s how it works: The user object is currently sitting in the Metaverse. Of the populated attributes, one of them is the EmployeeID. In this case, EmployeeID=12345. When a synchronization is run on the AD management agent, the filter/delete step is passed over and it attempts a join. During this attempt, the AD management agent contacts the Metaverse and basically says, “Do you have a user object with EmployeeID=12345?” The Metaverse, naturally, responds in the affirmative and the two become joined together.
Now, I previously mentioned that sometimes the order in which synchronizations occur matters. Allow me to explain: in the above scenario (SQL and AD), it doesn’t matter who syncs first as we can (and likely have) configured join logic on both management agents. However, there are management agent types on which you cannot configure join logic. The most common of these, in fact, is the FIM Service Management Agent (FIMMA). Because of this, if the two data sources in use were AD and the FIM Portal, the FIM would absolutely need to sync first. The reason behind this is, since we cannot configure join logic on that management agent, it needs to be the one to project into the Metaverse (and have the other management agent join to it). Failure to do so can result in duplicate and/or orphaned Metaverse objects.
I also previously mentioned that once a join has occurred (or FIM has provisioned an object, in the case of new objects), a relationship criteria then exists. Once an object has been created in a connector space, it receives a unique ID, known as the csObjectID. Likewise, once an object has been created in the Metaverse, it receives an mvObjectID. Once an object has passed all the way through FIM (from source connected data source, through the Metaverse and into the target connected data source), these values are created and an association is made. A visible representation of this would be:
These values are actually stored in the FIMSynchronization database in the form of a link table. That, however, is outside the scope of this discussion.
Questions? Comments? Love FIM/MIM so much you can’t even stand it?
>WE WANT TO HEAR FROM YOU<