none
Setting manager reference value in MV when the manager object does not exist in the projecting CS RRS feed

  • Question

  • Have a table that has a small subset of records that I am projecting into the MV.  These users have "managers" but the managers do not exist in the table that is being read to provision from.  Is there a way to set the manager MV reference without it existing in the upstream/contributing source?  Of course, rules extensions cannot be used to set reference values on import to MV.  Wondering if any of you have done this before?
    Friday, April 12, 2013 10:04 PM

All replies

  • Have a table that has a small subset of records that I am projecting into the MV.  These users have "managers" but the managers do not exist in the table that is being read to provision from.  Is there a way to set the manager MV reference without it existing in the upstream/contributing source?  Of course, rules extensions cannot be used to set reference values on import to MV.  Wondering if any of you have done this before?

    Just another note, there is metadata in the contributing table that is related to the manager like employeeid etc..etc..etc..  Just looking for a way to use that data to set the MVentry manager reference.
    Friday, April 12, 2013 10:16 PM
  • I am not sure what type of MA/directory your "table" is, but the proper way is to introduce this manager metadata as an import flow with reference type.  This depends that your anchor is the same as the data you are bringing in for the manager.  For example, if an HR database is the case, and if your anchor is the employee ID for person objects, then you could flow in your manager employee ID as a reference value directly from the connected directory source into the metaverse.  The sync engine will then keep up with your references for you.

    If this is not the case for you, or you have maybe a flat file scenario of sorts, please give more information.

     

    Regards,

    jose

    Monday, April 15, 2013 10:24 PM
  • Thanks for your response Jose.  I am using a standard SQL MA, reading a table that contains a small subset of records for users I would like to provision (that cannot exist in our HR system), but does not contain records for everyone else (who could be assigned as a manager).  Creating them in the Portal is not an option.  Creating a view and including all the other records in the CS would also mean that they (the possible manager records) would have to be joined/connected in order to be referenced properly in the MV.  I do not want any attribute flows to fire on any records other than the small subset that are currently in the table I'm reading.  I can write a projection rule to prevent projections, but the join rule would essentially make this another data source containing redundant records from our HR system.  I'd hate to have to use a rules extension for every attribute flow to prevent flows from happening for these other records.  I can somewhat mitigate this with precedence, but would be far from a perfect solution.

    Tuesday, April 16, 2013 12:06 AM
  • If you cannot directly flow the referential values from the connected directory, the next option is to manually populate the reference DN during provisioning and flow this into Active Directory.  The code for this might look something like this:

                managerDN = "unknown"
                If hasNewManager Then
                    If mventry.Item("managerAccount").IsPresent Then
                        mvEntryColl = Utils.FindMVEntries("accountName", mventry.Item("managerAccount").Value)
                        If mvEntryColl.Length > 0 Then
                            If mvEntryColl(0).Item("adDN").IsPresent Then
                                managerDN = mvEntryColl(0).Item("adDN").Value
                            End If
                        End If
                    End If
                End If
    

    In this example, we are flowing in values and checking to see if the manager has changed or is new (as opposed to staying the same). We also flow in the manager's account name (this could be any value you have in your "metadata") as "managerAccount". From Active Directory, we flow in all user objects' distinguished names "<dn>" as "adDN" (a string in MV). Using the VB metadirectory tools, we look up the manager and set the manager's DN value as the reference value via the usual code:

                            If Not managerDN = "unknown" Then
                                csentry.Item("manager").Value = managerDN
                            End If
    

    I hope this gets you closer to what you were looking for.

    regards,

    jose

    Tuesday, April 16, 2013 1:14 AM
  • Thanks.  I am already doing this currently, however the manager does not flow back into the metaverse as a delta on confirming import.  Only a full sync brings the value back. Delta Import Delta Sync and doing each step separately is the same.  Because the confirming import is not really a delta, it is an expected change, the value in the metaverse stays null.  There are a lot of objects in the AD CS, and doing a full sync after every export is not really practical.
    • Edited by Marvin Lee Tuesday, April 16, 2013 2:37 PM
    Tuesday, April 16, 2013 2:37 PM
  • There are two more things you might look into.

    First, I have found that, after exporting ADMA, a delta import, followed by full import, then delta sync brings the manager value in. This is definitely not the best solution, but better than full sync times.

    Second, I have found that if ADMA has precedence for this attribute, then it will flow on deltas. Other than that, these are the only solutions I've seen to work.


    Regards, Jose Garza | MCP, MCSA:2003 | http://josetheadmin.blogspot.com


    Tuesday, April 16, 2013 2:50 PM