Introducing Synchronization Rules - Part 2

[AMARSIGLIA]

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.

1. The Sync rule that manages the objects data (in this example it is a user object) is performing some basic Sync rule function like adding two attributes to build the value for the attribute (in this example the Department attribute) in the Active Directory Connector Space

1. Rules Extensions applied to the entire Metaverse or a Management Agent Extension.

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:

1. A user is created in the FIM Portal

1. The new User object becomes a member of the All People Set

1. The Outbound Sync rule MPR which is triggered when a new user transitions into the All People Set contacts the Workflow associated with the outbound Sync Rule The Workflow Stamps an ERE (Expected Rules Entry) on the User Object which will map to the Sync Rule that the Workflow is associated with.

1. An Import on the FIM will bring the new user object into the FIMMA Connector Space.

1. During the next sync with Provisioning turned on the User Object will be projected into the Metaverse and at this time will match the ERE with a Sync Rule that lives in the Metaverse. If for some reason the sync rule does not exist in the Metaverse that the ERE matches up to nothing will be done and the activity stops.

1. If the User object locates a Sync rule that matches up with the ERE the Sync Rule than processes this data and provisions the user object to the Connector space which the Sync Rule is connected to.
   
   1. It is during this step if workflow data is configured on the Sync Rule that the information in that Workflow data will be passed to its destination. Without an ERE this would not be possible because the Workflow Data would not know how to locate the object in the Metaverse.

Additional Considerations when Setting up Sync Rules,

• Inbound Sync Rule - Used to Sync Data into the Metaverse from an External Data source

• Outbound Sync Rule - Used to Sync Data out to an External Data Source from the Metaverse

• Inbound and Outbound Sync Rule - Used to Sync Data to and from the Metaverse and the External Data source.

• 1 Sync Rule per Object Type per MA

• Using Initial Flow Data you could configure 1 Sync rule to Provision new objects to a connector source and 1 sync rule to mange changes.

• Sync Rules can be configured with DE provisioning, if the Sync Rule is deleted and Object Stage deletion could be set for all objects that the Sync Rule was managing. (Use with extreme caution)

• The option for Create Resource in FIM if not check will prevent new object that do not yet exist in the Metaverse from being projected into the Metaverse.(applies Inbound Sync Rule)

• The option for Create Resource in External System if not Checked will prevent new objects that do not yet exist from being provisioned into the associated connected space. (applies to Outbound Sync Rule)

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.