Group Memberships not Flowing into Metaverse

Question

Hello,
I'm trying to figure out why the group member attributes in the CS are not flowing into the MV.  Here's what I have:
An HR system running on SQL Server
A staging database that extract data from the HR system
The staging database has a table representing person object
The stating database has a table representing person multi-valued attributes (i.e location, job code, etc)
The staging database has a table representing group objects
The staging database has a table representing group memberships (mult-valued)
A SQLMA connected to the person and person multi tables
A SQLMA connected to the group and group membership tables
All group memberships are based on job codes and locations.  There are no approval process in place.  If they have this job code, they get certain groups.  That's all calculated in the staging database and the memberships are in the group membership
table
This system does connect to AD (and a few other things), but I'm not concerned with that, right now.
I've read 100 articles on this, most of them over 5 years old, and tried the ones that made sense.  The flow from the database into the CS works well.  No issues there.
But, a search of the metaverse for the group shows an empty member attribute.  The sync process is not throwing any errors.  At least they're not showing up in the sync service app or the event logs.
Where allowed, I'm using rules extensions for everything.  I can't use a rules extension to set the member attribute because it's an rdn.
I'm going to move forward with this by extending the metaverse schema and adding a multi-valued string attribute named "memberOf" to the person object.  Then, I'll modify my existing MA to use that attribute instead of the member attribute. 
I'm not sure what kind of issues I'm going to run into when exporting that to AD.  I'll cross that bridge when I come to it.  I don't anticipate that being an issue as the dns for all these objects will be calculated by the ADMA based on locations,
group functions and person types (bascially, I don't care about the MV rdn).
Anyway, I'm looking for some real world insight on this.  This whole effort is to migrate off an existing IDM system that works very, very well but quite expensive to license.
Thanks,
Greg Wilkerson

Answer 1

Hey Cameron,
I have total control of all the DB tables FIM is accessing.  I build them up as part of IDM process.
I've read this article, along the many others that address the "manager" scenario.  This really doesn't apply in this case as the user and group objects are loaded in separate MAs.  Getting reference values to flow with both object live in the
same CS shouldn't be an issue. 
I also saw a solution where the group and user objects were in the same table and differentiated by the "object_type" value (user, group).  That solution solved the issue of the groups and user being in the same CS.  As I grow tired of my daily
FIM beatdown, that solution is growing more attractive.  That's a major DB redesign, and seems quite inefficient.
The multi-value table for group memberships already exists in the DB.  For FIM purposes, I transferred that data into the user object multi-value table.  See screen shot.  I can certainly configure the group MA to access that multi-value table
and load the group members as references.  But, because the group MA CS will not contain the user objects, I don't see how the references will be set.  If the reference value isn't set in the CS, it's not going to flow into the MV (at least I haven't
figured out a way to set the an reference value for an object in the MV - my problem all along.
This whole "setting a reference value" encompasses much more than just group memberships in my implementation.  Telephone resources and physical access (key cards, etc) are provisioned through the existing eDirectory system.  These objects exist
in our current IDM system and are associated with users based on rules.  So, the reference value process is something I need to figure out, if I'm going to use this product.
Maybe I could use a stripped down ECMA2 as a "staging" CS, export the users and groups into this CS and assign the reference values, then import the groups back into the MV, memberships intact.  I'm not sure that would get me where I want to go, and
it seems like a lot of extra "stuff" to solve what should be a simple problem.  Hmmmmmm.  Or, connect the ECMA2 directly to my group membership multi-value table in the DB.  Hmmmmmm.  I'd still have to export the groups and users into that
CS, but the import might be much more straight forward.  Hmmmmmm.
The structure of my GroupMembership table (both columns are anchors or directly translatable to anchors):
EmployeeGroups
    GroupName varchar(50) not null,
    EmployeeID nvarchar(50) not null,
    ID int identity(1,1) not null