Grouper Users - Open Discussion List

[Josef Krupička <>]

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