none
Better to define attributes in MA or Sync Rule?

    Question

  • So this might be obvious to everyone, however after working with FIM for a few months now I'm still now sure of the purpose for having two locations to define attribute flows.  I find myself defining FIM MA Attribute flows for person such as FirstName, LastName, Department, then in a sync rule for AD users I define flows for accountName, Domain...and for some reason I have DisplayName in both! 

    As I start to document and clean up a bit I'm thinking this is messy, is there general opinion that one means for defining flows is better than another?

    Wednesday, February 06, 2013 4:29 AM

Answers

  • You have two options to define attribute flows because you can setup the FIM synchronization engine without deploying the FIM portal.
    In this case, the only option you have is to configure attribute flows on a "per MA" basis.

    Even, if you have the FIM portal deployed, you must configure attribute flows for the FIM MA on a per MA basis.
    This is because the FIM service database is supposed to be a mirror of the metaverse.
    In this scenario, there is no need to do data transformations / calculations - it is just a replication of everything.

    Now, in the case of an existing FIM portal and all "non FIMMAs", you have the option to pick and choose.
    In this scenario, it is not a question of whether there is per se a better solution.

    What is better is driven by your scenario needs.
    Synchronization rule based attribute flows don't require coding, you can bring objects into the scope of a synchronization rule and remove them from the scope of them.

    However, there are cases where complex data transformations that can't be handled using the available functions are required.
    In a scenario like this, you still have the option to develop a rules extension.

    I belief, the only guiding principle should be to keep it as simple as possible.
    For example, if you manage your identities using synchronization rules, you should configure MA based attribute flow rules only as a last resort.

    Cheers,
    Markus 


    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

    • Marked as answer by Osho27 Wednesday, February 06, 2013 2:10 PM
    Wednesday, February 06, 2013 1:15 PM

All replies

  • Your question is a bit vague, you could mean 1 of 2 things by "FIM MA Attribute flows", so I'll answer both

    1) If by "FIM MA Attribute flows", you mean the FIM Service Management Agent in the FIM Sync Service

    Don't think this is what you mean, but just in case... the flow rules on the FIM MA define the flow between the FIM Service/Portal and the FIM Sync Service Metaverse. The Sync Rules you define on AD within the FIM Portal define the flow between the FIM Sync Service Metaverse and AD.

    2) If by "FIM MA Attribute flows", you mean "attribute flows in the AD MA in the FIM Sync Service"

    I think this is what you mean - within this method what you've noticed is that you can define flow rules both within the FIM Portal ("Sync Rule") and within the FIM Sync Service ("MA attribute flows") and you're wondering - why? And is there any reason why you'd use one over the other?

    Why? - The reason you can define them in both places is a historical one - prior to FIM 2010, there was no Portal, so there were no Sync Rules. the only place you could define attribute flows was in the FIM Sync Service, using the MA attribute flows. Indeed, if you implement a FIM solution without the FIM Portal (ie, Synchronisation Service only), you still have to do this.

    Why I only define  my attribute flows in the FIM Sync Service, on the MA itself:

    - It's faster (I can add 10 flow rules in the time it takes me to add 1 through the portal web interface)
    - I can create rules extensions using them (I find coding these far more flexible than the "functions" provided in the Portal Sync Rule config)
    - There's a lot less overhead as FIM doesn't have to generate an ERE for each rule. I also find that from an operational perspective, this makes more sense - for an EAF, if it's a sync rule, FIM needs to export data to the FIM Portal, import the ERE, then creates a pending export; if it's MA-defined, the FIM Sync Service just processes the flow and creates a pending export. In fact, the ERE overhead is a good reason not to use Portal Sync Rules, in my opinion.

    So why would you define Sync Rules in the Portal?

    Well, I wouldn't. But you might like to for these reasons:

    - If you need to manipulate any data in the flow (ie, not a direct flow), Sync Rules allow you to do this without writing code (some people fear code)
    - By moving this configuration to the Portal, you can allow people to add new Sync Rules without giving them direct access to the server that the FIM Sync Service runs on, as you just need to give them access via an MPR in the FIM Portal.

    And... that's all I can think of. I'd be curious to see if anyone else has any compelling reasons

    - Ross Currie


    FIMSpecialist.com | MCTS: FIM 2010


    • Edited by Ross Currie Wednesday, February 06, 2013 6:34 AM
    • Proposed as answer by Ross Currie Wednesday, February 06, 2013 6:34 AM
    Wednesday, February 06, 2013 6:32 AM
  • You have two options to define attribute flows because you can setup the FIM synchronization engine without deploying the FIM portal.
    In this case, the only option you have is to configure attribute flows on a "per MA" basis.

    Even, if you have the FIM portal deployed, you must configure attribute flows for the FIM MA on a per MA basis.
    This is because the FIM service database is supposed to be a mirror of the metaverse.
    In this scenario, there is no need to do data transformations / calculations - it is just a replication of everything.

    Now, in the case of an existing FIM portal and all "non FIMMAs", you have the option to pick and choose.
    In this scenario, it is not a question of whether there is per se a better solution.

    What is better is driven by your scenario needs.
    Synchronization rule based attribute flows don't require coding, you can bring objects into the scope of a synchronization rule and remove them from the scope of them.

    However, there are cases where complex data transformations that can't be handled using the available functions are required.
    In a scenario like this, you still have the option to develop a rules extension.

    I belief, the only guiding principle should be to keep it as simple as possible.
    For example, if you manage your identities using synchronization rules, you should configure MA based attribute flow rules only as a last resort.

    Cheers,
    Markus 


    Markus Vilcinskas, Knowledge Engineer, Microsoft Corporation

    • Marked as answer by Osho27 Wednesday, February 06, 2013 2:10 PM
    Wednesday, February 06, 2013 1:15 PM
  • Thank you Ross - starting to see the light. Yes, I was looking at the FIM MA attribute flow rules that I've set up and comparing those attributes to those I've then defined for the AD sync rules (my flows go from portal to AD for the time being).  I do not define any attribute flows for the AD MA.  I do understand your pros/cons explanation.  Since I am building a system for someone else to eventually run and manage, I tend to think keeping things at a configuration-level (versus coding rules) is a better form of delivery.  Something to thing about anyway - and perhaps discuss with the customer.

    Wednesday, February 06, 2013 2:54 PM
  •  

    Thank you Marcus - I understand your points. Let me ask a mechanics question.

     

    In my FIM MA outbound attribute flow (my end-to-end flow is from FIM portal to AD) I defined the following attributes

     

    Data Source   Attribute        Metaverse   Attr.        

    Type

    dn                                            

    sync-rule-mapping

    MVObjectID                   object-id           

    Direct

    DetectedRulesList           detectedRulesList

    Direct

    DisplayName                   displayName           

    Direct

    Domain                   domain                   

    Direct

    FirstName                   firstName           

    Direct

    LastName                   lastName                   

    Direct

    ObjectSID                   objectSid                   

    Direct

    Department                   ou                   

    Direct

     

    I run an import and sync after filling out a number of fields for a new user within FIM portal. If I look at the CS object properties I see:

     

    Distinguished Name : 4b27ac09-4fbc-4045-b304-464731dcc1f0

    Object Type: Person

     

    Attribute information:

     

    AccountName

    string

     

    CreatedTime

    string

     

    Department

    string

     

    DisplayName

    string

     

    Domain

    string

     

    EmployeeType

    string

     

    FirstName

    string

     

    IsRASEnabled

    boolean

     

    LastName

    string

     

    MVObjectID

    string

     

    MiddleName

    String

     

    ObjectType

    string

     

    Creator

    reference

     

    DomainConfiguration

    reference

     

    ExpectedRuleList

    reference

     

    ObjectID

    reference

     

     

    Why is it that more attributes are flowing than what I have defined in the FIM MA?

     

    Granted I did define some of them within the AD User sync rule as being required, such as accountName, but I didn't define some of these other attributes however I may have entered respective values in the FIM new users form. 

     

    If I look at click on the object Lineage tab, then click Metaverse Object Properties I do see a refined list that looks like the attributes I'm after…

     

    accountName

    csObjectID

    displayName

    domain

    firstName

    lastName

    ou

    expectedRulesList

     

    I conclude that the Metaverse object attribute list is a net result of the FIM MA attribute flow definitions and ANY export MA sync attribute rules.  Might be loose in my wording, but is this roughly the idea?

    Wednesday, February 06, 2013 3:29 PM
  • Synchronization rule based attribute flows don't require coding, you can bring objects into the scope of a synchronization rule and remove them from the scope of them.

    Ah yes, that would be the other "pro" for SR's via the Portal that I was forgetting.

    - Ross Currie


    FIMSpecialist.com | MCTS: FIM 2010

    Thursday, February 07, 2013 5:13 AM
  • Hi Osho, actually the second table that you are showing is the Connector Space for the FIM Portal, which is inturn connected to the Metaverse through the FIM MA. these attributes MUST have an Import Flow defined for them in teh FIM MA.

    Regards Furqan Asghar

    Thursday, February 07, 2013 1:56 PM
  • Just to add to what Furqan has said...

    When you configure a flow rule, you're defining a flow from the connector space to the Metaverse (Import attribute flow - IAF) or the Metaverse to a connector space (export attribute flow -  EAF).

    If you want to have an end-to-end flow from the FIM Portal to AD, then you need to have two flow rules:

    1) Import attribute flows configured in the FIM Service MA ("FIM MA") within the FIM Sync Service to flow attributes from the Portal into the MV (this moves data from the FIM Portal to the FIM Metaverse)

    2) Export attribute flows  configured in a Sync Rule within the FIM Portal to flow to AD. (this moves data from the FIM Metaverse to AD)

    The reason you're seeing extra attributes in the connector space, is that you are looking at the connector space object within the FIM Portal - ie, the attributes you see in the CS object are all the attributes that currently have data for that user in the portal.

    When you click "view Metaverse Object Properties", the attribute list you are seeing is a net result of ALL Import attribute flows from ALL end systems. In your case, this may just be the FIM Portal (unless you have import rules defined against AD)

    "Why is it that more attributes are flowing than what I have defined in the FIM MA?"

    In answer to your question, they're not flowing. The extra attributes you are seeing are in the FIM MA connector space object - ie, the Sync Service's view of the FIM Portal object. Values then flow from there into the Metaverse, and then into the connector space object in AD.

    Hope that explains things a bit more.

    - Ross Currie


    FIMSpecialist.com | MCTS: FIM 2010

    • Proposed as answer by Ross Currie Friday, February 08, 2013 7:16 AM
    Friday, February 08, 2013 7:10 AM