Hi,

Using the latest build 4.1.3508.0.

Trying to create an Outbound Sync Scope Rule. When I setup the Sync Rule, I select 'employeeID' as the relationship criteria.

I then complete the Sync Rule, and Submit.

When I return to the Sync Rule, the Relationship Criteria is greyed out and blank:

Further, when I try to create the associated Workflow, the Sync Rule does not appear in the drop down box:

I have restarted IIS and FIMService a few times; even rebooted the computer.

Is this a config error or a software bug?

thanks,

sk

• Edited by Shim Kwan Friday, April 04, 2014 3:52 AM

Hello,

I suspect you've created an Outbound Synchronization Rule that's using the Outbound System Scoping Filter to apply the rule (check the Apply Rule section on the General tab).  

Since that type of synchronization rule is applied to a resource based on the scoping filter criteria, the relationship criteria is not defined/kept after creation, nor would the rule be applicable in terms of a Synchronization Rule Activity, since you don't need to explicitly apply/add that type of synchronization rule to a resource.

Cheers,

Marc

Hi,

That is correct, I am using the Outbound System Scoping Filter Rule.

Does this mean that this rule can only be used once, just to provision a user account in AD for example, and can never be used for ongoing user account maintenance (e.g. employeeStatus changes, OU moves, etc)?

Thx

SK

No, it means that the rule applies automatically to all records that match the outbound scoping filter. You can still have individual flows within the rule that apply only at provision time (initial flow only checked) or on every synchronization, including the provision (initial flow only unchecked).

Outbound rules that are not "outbound scoped" (you instead select "apply rule to specific metaverse resources...") must be applied to individual records via workflow.

Rex

thank you - so how does FIM know which record to update? Doesn't FIM need an anchor ID defined to ensure it is updating the same record?

This is defined in 'Scope' tab.

I forgot the exact name but is called 'Outbound Scoping Filter' in Scope tab where you define the criteria.

-Mann

Hi,

Here's a screenshot of the 'Scope' tab - there is nothing that says "join on employeeID" for example.

I guess I will need to define the Join/Project criteria in the Management Agent (in the FIM Sync console).

The scope tab is used to determine on what existing connections the attribute flow rules apply (Outbound scoping filter for outbound rules, Inbound scoping filter for inbound rules). Note that the filters are for the synchronization rule you are currently configuring - you can have different scoping filters for each synchronization rule.

Join, Project, and Provisioning are accomplished on the next tab (Relationship). The checkbox for "Create resource in FIM" means "Enable a Project rule". The checkbox for "Create resource in external system" means "Provision" and the "Relationship Criteria" is your join rule.

If you wanted to bring in existing accounts from AD and wanted to join on any accounts that you already had in the Sync engine (join and project) your screen might look like:

Rex

• Marked as answer by Shim Kwan Thursday, April 24, 2014 3:20 AM

Thank you Rex, I understand everything you are saying.

Which brings me back to my original question...why, when using the new Outbound Scoping Filter, the relationship criteria is greyed out? As per my limited understanding of FIM, there needs to be some relationship between the MV object and the source/target object (e.g. employeeID) so that FIM can maintain the correct relationship with the correct object when its attributes change (e.g. job title).

When initially configuring the Outbound Sync Rule for the first time, I am able to select the Relationship Criteria attribute. However, when I return to the Sync Rule, the Relationship Criteria is greyed out as in the screenshot above.

So why is it greyed out? and why can I not see what attribute the Relationship is based on?

• Edited by Shim Kwan Tuesday, April 22, 2014 9:52 PM

In the Sync Engine, joins and projections occur on inbound synchronization when disconnecters are evaluated. During inbound sync, each record in the connector space that is not connected to a metaverse object is examined for possible joins. If there is a join rule that uniquely matches, the connector space object gets connected to the matching metaverse object. If no joins are found then a projection rules are examined; if a projection rule exists, a corresponding object in the metaverse is created and joined to.

When you are using declarative sync rules (rules created in the FIM Portal), the same underlying logic occurs. The declarative sync rules are transformed into join, projection, and provisioning rules as I alluded to above.

The trick is since joining only occurs in inbound sync, you need to put your "Relationship" information on a declarative sync rule that is an inbound rule. Try creating a separate inbound declarative sync rule and specify your relationship information or create a combined rule "inbound and outbound" and do the same.

Rex

• Marked as answer by Shim Kwan Thursday, April 24, 2014 3:20 AM

Thank you Rex, I understand your explanation. I most likely was using the wrong terminology to identify my problem. Let me try again.

The Scoping Sync Rule, that I am creating, is meant to take certain MV data (employeeType=Student) and provision it to Active Directory; I have another similar rule to provision this same data to ADLDS.

When the MV data is Exported to AD and ADLDS, shouldn't there be something like an 'anchor' attribute or 'relationship criteria' attribute to establish a relationship between the MV object and the corresponding AD and ADLDS object?

In my screenshot above, I expected that the 'relationship criteria' would NOT be greyed out, and instead list something like what your screenshot depicted (accountName to samAccountName match). If my 'relationship criteria' is greyed out, how does FIM know, when exporting, which object to update in the target system (AD or ADLDS)?

Hope this question is clearer now, and thank you again for your time.

• Edited by Shim Kwan Wednesday, April 23, 2014 7:53 AM

Every management agent has an "anchor" defined - with the anchor being the attribute or set of attributes that uniquely identify a record and that have values which never change. However in the case of the management agents you are using (AD, ADLDS, FIM), the anchors are internal and you can't change or see them (you also wouldn't want to change them). This is because these systems have an inherent internal key that uniquely identifies record and never changes. For things like text files and SQL tables, you have to define these anchors because they don't have inherent internal keys.

A connection (joined record) in the FIM Sync engine is the association between an anchor in a management agent and an object id in the metaverse.

A join rule in the FIM Sync engine is a definition about how to potentially associate (connect) unconnected (disconnected) records in a management agent to corresponding records in the metaverse.

The thing that is easy to miss is that a connection and a join rule are not the same thing. Join rules are used to make connections, but once a record is connected, you can delete the join rule or change the values of the attributes referred to in the join rule so that the join rule no longer matches and the record will still be connected. Join rules do not need to refer to the anchor attributes (and frequently don't). While management agents can have multiple join rules per object type (multiple different ways to try to connect), a given record in a management agent (connector space) is either connected to the metaverse or it is not - it is either a connector or a disconnector.

When thinking about synchronization you want to think about the connection process separately from the attribute flow process. During synchronization there is a process to determine if any disconnected records need to be connected (evaluation of join rules) and after that data flows through the connections (attribute flow) as specified by the synchronization rules.

So... to get to your question of how does FIM know at export time how to where to send the data -- On export FIM will send the data across any existing connections that were previously created. "Previously" means during an inbound synchronization which could have happened in an earlier phase of the current synchronization cycle, or could have happened a long time ago.

"Relationship Criteria" is how you set up join rules that are used create a connection during an inbound synchronization operation - This is why it is greyed out if your rule only has outbound flow.

Additional note: Inbound and Outbound scoping filters are additional filters that prevent or allow data to flow across an existing connection, they don't set up the connections themselves.

Hope this makes more sense.

Rex

• Marked as answer by Shim Kwan Thursday, April 24, 2014 3:20 AM

that explanation helped a lot Rex, thank you for taking the time to write it out for me!