Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] Grouper and Provisioning

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] Grouper and Provisioning

Chronological Thread 
  • From: Josef Krupička <>
  • To: "Chris Hyzer" <>, "" <>
  • Subject: Re: [grouper-users] Grouper and Provisioning
  • Date: Mon, 02 Feb 2009 21:49:06 +0100
  • Organization: ZČU, CIV


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...


Archive powered by MHonArc 2.6.16.

Top of Page