I'm waiting for a development system to be built, so I can't yet try this
out myself. I'm thinking through the changes I need to make, due to
changing requirements here, and I've either run in to a good idea, or a
bad one, depending on what happens.

We have multiple authoritative sources for people. Primarily HR
(PeopleSoft) and Student Admin (also PeopleSoft). People here could be
employee, student, or both. Employees come from HR, students come from
SA. Internally to PeopleSoft, both systems share the employee id number

For historical reasons, the ID vault treats these as separate people that
happen to have the same name. HR events happen and employee accounts are
created, deleted, etc. on a lifecycle. SA events happen and student
accounts are created, deleted, etc. on their own separate lifecycle. Both
objects in the ID vault have the same EMPLID from PeopleSoft, but they
are otherwise unrelated to each other.

I have a connected system using the JDBC driver, with direct access to
its database. When implemented, this system was deliberately "students
only" and no employees were ever going to use it. So the database has
been provisioned with all student objects from the ID vault.

Now, 7 years or so later, yeah, we need employees to use this application
as well. Further complicating things, the application has an internal
database schema limitation of only being able to have one user object per
actual person. And, because of the way they have other linked tables in
the SQL database, users once created, cannot be deleted (though they can
be renamed).

So, step one is to rename the users. Right now, the user name is the eDir
CN. That's going to change to be the EMPLID. That gets me past the first

The second problem is merging data from the two eDir objects representing
a person in to the single user object in this database. Since the eDir
objects are on different lifecycles, it's possible that the student may
show up first, or the employee might show up first. The student could be
deleted, leaving the employee in place, or the employee could be deleted,
leaving the student.

What I think I want is to allow both objects though the driver. Use the
Subscriber Matching Rule to find the correct database object [@user =
EMPLID], and update it. That would also then allow both eDir objects to
have an association with this one JDBC driver. There's no Publisher
channel to worry about.

Does that work? I realize that whichever object is updated last is what
will show up in the database. That's ok

David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.microfocus.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.