So I have this workorder driver that has been running for quite some
time. It basically converts a delete from HR via jdbc into modifying
some homegrown entitlement attributes that when the connected systems
see them turns those modifys back into deletes. Then writes a workorder
object to delete the user in 14 days--which flows to the one connected
system we wanted to delay the delete on.

So at the end what I end up with is the user still in the vault,
removed from all connected systems but one(those associations are
removed as well), and has a 14day timebomb.

This has been working well, but now we are in a position that some of
these users will be re-added before the 14days.

Since the new add has changed nothing on the user when it goes through
jdbc as the add I do not even get a change to test for a "from-merge"
since nothing has changed:

1837377856 DVRS: [2009/04/10 13:54:56.624] JDBC 2 PT:Applying publisher
1837377856 DVRS: [2009/04/10 13:54:56.625] JDBC 2 PT:Publisher
processing add for PK_ID=13033957235,table=V_ID_MGMT,schema=IDM.
1837377856 DVRS: [2009/04/10 13:54:56.625] JDBC 2 PT:Found an
associated object.1837377856 DVRS: [2009/04/10 13:54:56.625] JDBC 2
PT:Merging eDirectory and application values.

I will never get a merge to test for.

So I had thought of munging an attr,,,maybe prefixing something to sn
when the account is in the vault waiting for the timebomb,,,that way if
a re-add does happen I can at least get sn to change which will trigger
the modify and should repopulate the other systems.

Just curious if someone can give me some logic to try before I head
down that path.


jeff@linux1:~> glxgears
120308 frames in 5.0 seconds = 24061.553 FPS
jedijeff's Profile:
View this thread: