First published on MSDN on Dec 29, 2014
Continued from Introducing Synchronization Rules - Part 1
How Synchronization Rules manage data
Probably the most difficult concept to grasp for some is the direction of the Attribute Data Flow when using Sync rules, as mentioned earlier Sync Rules only flow data either into the Connector Space of the External Data Source ( except for the Connector Space of the FIM MA ) from the Metaverse or from the Connector Space of the External Data Source ( except for the Connector Space of the FIM MA ) into the Metaverse. The FIM Portal potentially has a limited role in the Synchronization of data, notice I said potentially. What can be difficult to grasp is FIM 2010, R2 , and R2 SP1 all require the Synchronization Rules to be Configured with-in the FIM Portal so when you are configuring the Sync Rule the only thing you have to remember is where the data is going to or coming from, if your configuring the Sync rule to flow Attribute values that are built with-in the FIM Portal the attribute value must be in the Metaverse and the Sync Rules DO NOT Sync Data into or from the Metaverse into or from the FIMMA Connector Space. Let’s say that you have workflows that build the value for the Department Attribute in the FIM Portal and you add the Attribute Department in the Outbound Sync rule for the User Object to Active Directory. If you have not configured the FIMMA using Direct Attribute flows for the Department Attribute the Department Attribute in the Metaverse will not contain a value unless it was populated by an external data source but if you are building the Department Attribute in the FIM Portal using workflows you probably would not have the Department Attribute in the Metaverse being populated by any other Data source. For this example let’s say that Department is not populated from any other data source. Now let’s say we run a sync in the Metaverse and then do a Pending Export (we would do a pending export because we are obviously making changes in the Metaverse and it is recommended to perform a Pending Export on the ADMA to verify the changes to prevent exporting bad data.) We would notice that the Pending Export would show us the user object without anything populated for the Department Attribute. At this point you would be thinking what happened and begin troubleshooting which I would do a Metaverse search on the user object in question and examine what attributes are populated in the Metaverse. If the Attribute does not contain a value in the Metaverse than the Connector Space would not be able to be populated with a value unless 1 of the following would apply.
To make things even more difficult is if the attribute that is being synced is part of an Initial Flow Attribute Flow meaning it is performed on the object being synchronized just the initial instance the sync rule manages the object than the sync would fail on for any object where an attribute that is expected is not available.
Relationship Criteria is essentially the Join Criteria for the Object as it is syncing into the Metaverse. You may have noticed that the Relationship Tab is grayed out on Outbound Sync Rules using the System Scoping Filter, this is because joining only happens when syncing objects from the Connector Space into the Metaverse.
Workflow Parameters is a way to pass data from workflows within the FIM Portal to the object that is being synced from the Metaverse to the External Data Source it is connected to all without storing the Data permanently in the FIM Portal or even in the Metaverse. Because this is workflow Data is active for a limited amount of time to be utilized by another workflow or in this discussion within a Sync Rule. Using the Workflow Data you would be able to build a password using workflows in the FIM Portal and pass them via Workflow Data to the Sync Rule without storing that value to an attribute which could potentially be a security risk. Workflow data can be used to temporary store data to be committed later during the Synchronization process or used as a building block to build of attribute data. It is important to note that Workflow Data is only an option with Traditional Outbound Sync Rules.
Traditional Sync Rules were the 1 st iteration of Sync Rules used for “Codeless Provisioning” that was introduced with FIM 2010. It wasn’t until 2010 R2 when we were introduced to the System Scoping Filter Sync Rules which we talked a bit about earlier and will discuss with a bit more detail a bit later. The first thing we need to discuss is the major difference which is Traditional Sync Rules do absolutely nothing until they are connected to a Workflow that is triggered by an MPR (Management Policy Rule) which is associated with a Set. Depending on the complexity of the environment and how many Sync Rules are in in play would determine how you set up your sets and MPR to trigger the Workflow that adds an ERE (Expected Rules Entry) object as a reference object to the object being synchronized. This ERE is like a bus ticket that the User Object carry’s into the Metaverse and hands to the Sync Rule that lives in the Metaverse which than processes that data to the external data source connector space. Let’s map this out:
Additional Considerations when Setting up Sync Rules,
In the follow up blogs we will walk through step by step configuring each type of Sync Rule. Although I prefer System Scoping Filter Sync Rules 1 is not overwhelmingly better than the other, both sync rules server a very important purpose.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.