none
Possible to map mv attribute to multiple data source attributes? RRS feed

  • Question

  • Hello!

    Is it possible to map a single metaverse attribute to multiple data source attributes during export flow? Each person object has a multi-value string attribute containing string-encoded account information and we need a way to map it during export to the corresponding account objects. Unfortunately, it is not possible to select multiple data source attributes in the export flow configuration window, multiple MV attributes are fine on the other side (but not what we need).

    Creating the account object and connecting it to the person (provisioning) already works but we cannot export our account attributes. It is not possible to set the attributes during export with code (rules extension) because they are read-only except the one that is currently scheduled for export. And mapping each attribute 1:1 means splitting/parsing the account string for every single exported attribute which is from a performance point of view suboptimal. It would be better if there is a way to parse the string only once and set all affected attributes.

    If that doesn't work, is there another way to properly manage user accounts? We have a very heterogenous organization and our current IDM solution supports managing accounts via LDAP and workflows (e. g. triggering scripts to create accounts on target machines). But it works quite different from the way FIM does (for example event based vs. state based).

    Thanks in advance!

    Thursday, March 21, 2013 8:37 AM

Answers

  • Hi-

    You can't assume any inter-dependency between your export flow rules, really.

    Do all these attributes come from the same place? What about pre-formatting your export data on import? Is doing the calculation twice really that expensive?


    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    • Proposed as answer by Ross Currie Monday, March 25, 2013 3:55 AM
    • Marked as answer by Taronyu Tuesday, March 26, 2013 8:23 AM
    Thursday, March 21, 2013 2:43 PM
    Moderator

All replies

  • You should make an export flow for each data source attribute to do this. You could use the Transaction Properties class in the Rules Extension so you only have to do the splitting part just once and don't have to deal with the performance degradation.

    If you are using the FIMPortal for defining sync rules this could be a little easier.


    Find me on linkedin: http://nl.linkedin.com/in/tranet




    • Edited by Robin Gaal Thursday, March 21, 2013 10:34 AM
    Thursday, March 21, 2013 10:33 AM
  • Thank you for your answer. I had a look at the TransactionProperties property but I'm not quite sure if it helps. And I've found on this site here that Utils.TransactionProperties is deprecated and will be removed in future versions.

    Currently it looks like this, at least that is what we try to implement:

    • loginName <= accountData
    • mail <= accountData
    • type <= accountData
    • fname <= givenname
    • lname <= sn

    On the left is the specific account object (mailAccount, vpnAccount, ...), on the right the person object (mapping like it would appear in the attribute flow configuration window).

    accountData contains the string-encoded account information like account type (mail, vpn, ...), username, and type-specific data and it is stored as a multi-value attribute inside our person object. It is multi-valued because we want to support having multiple accounts per person. The only solution we found so far is mapping each attribute 1:1 like shown above which implies parsing the whole accountData string per exported attribute. Because accountData is a multi-value attribute I'm a bit concerned about the order in which those strings are returned during each call. Here is a little example to clarify what I mean:

    Multi-valued attribute "accountData" containing three account strings
    accountData = account1, account2, account3

    During export flow, our rules extension retrieves all accountData strings from the metaverse object and checks for account types that need to be exported in the current run (by checking the account type field of each string). Now if we want to handle the mapping "loginName <= accountData" we parse the string, look for the "loginName" field (or what it is actually called) and set the value in the affected object. When we move to the next export step ("mail <= accountData") our rules extension is called again. But when we retrieve the list/array of multi-value strings for our accountData attribute, how do we know if the current string (-> account) is the same as in the last step without parsing it again and checking the unique account id/name? If we don't know we cannot parse the account string only once, store the resulting data structure temporarily and just set each attribute step-by-step until the next account is reached. I hope it gets more or less clear what the problem is, I'm not even sure how I would explain it in German (my mother tongue). It's complicated :(

    If there is an easier solution to achieve what we need, please tell us. I'm not that happy about the current solution either but from everything I have tried out so far, this was the most working solution.

    One alternative is writing a custom application that handles account management and FIM just forwards the accountData strings through a management agent. This application would parse the strings, decide which systems are affected and execute the appropriate action. Therefore it would be fairly simple in terms of logical complexity, only the connectors to the target systems could be a bit more complex.


    • Edited by Taronyu Thursday, March 21, 2013 2:28 PM
    Thursday, March 21, 2013 2:27 PM
  • Hi-

    You can't assume any inter-dependency between your export flow rules, really.

    Do all these attributes come from the same place? What about pre-formatting your export data on import? Is doing the calculation twice really that expensive?


    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    • Proposed as answer by Ross Currie Monday, March 25, 2013 3:55 AM
    • Marked as answer by Taronyu Tuesday, March 26, 2013 8:23 AM
    Thursday, March 21, 2013 2:43 PM
    Moderator
  • Im not sure what the real problem is.. It functions correct now, right? You just want to solve this in a nicer way, right?

    Find me on linkedin: http://nl.linkedin.com/in/tranet

    Thursday, March 21, 2013 8:10 PM
  • So we shouldn't rely on the multi-value order, am I getting this right? That's what we want to avoid anyway.

    I can't gurantee that there is only a single attribute source, we are still experimenting. The attribute string is stored only inside the person object's accountData multi-value attribute but as far as I remember it could be possible that it is modified/created by different systems.

    We have a lot of accounts (100,000+) therefore we're always concerned about performance - on the other hand, premature optimization is the root of all evil ;-)

    And could you please explain a bit more what you mean with "pre-formatting your export data on import"?

    Thursday, March 21, 2013 8:10 PM
  • So we shouldn't rely on the multi-value order, am I getting this right? That's what we want to avoid anyway.

    I can't gurantee that there is only a single attribute source, we are still experimenting. The attribute string is stored only inside the person object's accountData multi-value attribute but as far as I remember it could be possible that it is modified/created by different systems.

    We have a lot of accounts (100,000+) therefore we're always concerned about performance - on the other hand, premature optimization is the root of all evil ;-)

    And could you please explain a bit more what you mean with "pre-formatting your export data on import"?

    You shouldn't make any assumptions around the order of multi-valued attributes or the order that your attribute flow rules will be alled.

    From what you've described, this sounds like some text handling which is probably not very expensive. You're also not going to process every user every single time, I assume.

    With regard to "pre-formatting your export data on import", I was wondering if you could put the data in the right format in an MV attribute in an import extension to be more efficient.


    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    Thursday, March 21, 2013 8:15 PM
    Moderator
  • Im not sure what the real problem is.. It functions correct now, right? You just want to solve this in a nicer way, right?

    Find me on linkedin: http://nl.linkedin.com/in/tranet

    Yes. The way it works with the current IDM solution is like this: you have a person object and then each account object is attached to that person object (it's internally using a LDAP if I remember correctly). Now we would like to achieve the same or at least something similar with FIM. But except of storing the account data inside a multi-value attribute, nothing we have tried so far worked.

    @Brian

    Okay, thanks for your answer. I guess we will stick to the current solution and modify it so it doesn't depend on the export order anymore - or we find a better solution. Well, I didn't expect managing our accounts with FIM would be that complicated :-(


    • Edited by Taronyu Friday, March 22, 2013 5:34 PM
    Friday, March 22, 2013 5:29 PM
  • I've read through this and Brian's answer regarding formatting on import seems the most obvious to me.

    Also, are these all attributes that are set only during provisioning? Do you need to have a constant flow to all of them?

    If they are set only during provisioning, consider having the values set in the Provision() method. Do the split once, then apply it to all three attributes at that point

    eg,

    loginName,mail,type = mventry["accountDetails"].StringValue.Split(',');
    csentry["loginName"].StringValue = loginName;
    csentry["mail"].StringValue = mail;
    csentry["type"].StringValue = type;

    or something like that.

    Edit: Just saw you mention accountDetails is a multivalue. Obviously splitting on ',' would not work in this case, but you hopefully get the gist

    - Ross Currie


    FIMSpecialist.com | MCTS: FIM 2010 | Now Offering ECMA1->ECMA2 Upgrade Services


    Monday, March 25, 2013 4:02 AM
  • Actually our code looks pretty much like this. And we have set all attributes during provisioning in our first attempt too but as the account information might change over time (depends on the account type though), we had to move it towards a rules extension that is used during export attribute flow. Well, then it seems like this way of doing things might not be that bad at all :-)

    Thank you all for your help!

    • Edited by Taronyu Tuesday, March 26, 2013 8:24 AM
    Tuesday, March 26, 2013 8:17 AM
  • I just want to let you know that we have found a working solution based on what has been discussed here. Even delta import/sync with multiple accounts of the same type works now :-)
    Wednesday, April 3, 2013 1:48 PM