Grouper Users - Open Discussion List

[Chris Hyzer <>]

My personal opinion has been to do something very similar to what you 
suggest...  with a table of work to do, managed by triggers, etc.

https://wiki.internet2.edu/confluence/display/GrouperWG/Auditing#Auditing-Notifications

However, we are currently discussing this approach and potentially other 
options to see what we will do...

That is similar to how Penn currently provisions and it works great.

Thanks,
Chris


> -----Original Message-----
> From: Josef Krupička 
> [mailto:]
> Sent: Monday, February 02, 2009 3:49 PM
> To: Chris Hyzer; 
> 
> Subject: Re: [grouper-users] Grouper and Provisioning
> 
> Hi,
> 
> this feature looks very good. We need this mechanism to connect Grouper
> with Sun IDM and one possibility is to use special DB table where is
> stored something like subjectid, group id, type of action (INSERT,
> UPDATE,
> DELETE, ...) and timestamp. For beginning we need only watch changes in
> memberships. The simplest way is to use triggers (fail safe,
> transactional) but i don't know how it will cooperate with Hibernate
> (portability between different databases). Can I ask how you plan to
> implement this feature and when you plan to release some prototype?
> 
> With best regards,
> Josef Krupicka, Western university of Bohemia.
> 
> On Mon, 02 Feb 2009 18:49:25 +0100, Chris Hyzer 
> <>
> wrote:
> 
> >
> >
> >> Now that hooks are available, we'd be VERY interested in talking to
> >> sites that are looking to build on that interface to do real time
> >> provisioning into ldap, etc.
> >
> > Hopefully in 1.5 we will have "Grouper Notifications", which will be
> a
> > reliable way to notify external systems about grouper registry
> changes,
> > incrementally, and in real time (well, you configure the interval,
> e.g.
> > max 1 minute delay).  The advantages to this over hooks would be:
> >
> > 1. Traffic to the external system would be more structured and less
> > chaotic since they would originate from one entity (e.g. the loader),
> > instead of from the loader, GSH, UI (could be load balanced array),
> WS
> > (could be load balanced array)
> >
> > 2. Any updates to the DB would take effect, e.g. if you have to run
> some
> > SQL against the DB to do a bulk update or something.  Granted we
> don't
> > want people doing this, but if you had to... :)
> >
> > 3. Updates would be ordered by the order they occurred in the
> registry.
> > E.g. if the WS makes a change, and the UI makes a related change,
> then
> > the order of traffic from the UI and the WS to the external system
> might
> > have a race condition and be different than what actually occurred in
> > the registry.
> >
> > 4. It would be fail safe.  If the destination system is down for a
> > little while, and grouper hooks started failing, unless you built in
> > your own queueing mechanism, those changes might get lost.  In
> grouper
> > notifications, the messages would just sit on the queue in the DB
> until
> > the external system is back online
> >
> > 5. It is transactional.  If the change happens in grouper, the
> message
> > will be on the queue.  This is not really case if you are using
> grouper
> > hooks and not keeping the data in the grouper database or doing some
> > sort of distributed transaction or something.  E.g. if the change
> > occurs, is committed to grouper, then grouper gets turned off, before
> > notifying the external system, when it gets turned on, it will not
> know
> > it needs to notify.
> >
> > If we don't like the polling of the work queue table because it is
> too
> > slow or inefficient, TomB has also mentioned that the UI or WS could
> > kick the loader somehow to tell it to do some work...
> >
> > Regards,
> > Chris
>