Grouper Users - Open Discussion List

[Steven Carmody <>]

On 4/18/13 6:59 PM, Jeff McCullough wrote:
> Hi Steven,
>
> I'm just answering your question with a question if you don't mind.
How many groups are you provisioning this way? How are the rules setup?
Are the rules using information in attributes stored in grouper or based
upon naming or something else?

first off --thanks to both Patrick and Bert for such useful descriptions 
of the approaches used at their campuses. Lots of good hints and 
experience on how to go about this.

Back to Jeff's question --

we currently have a variety of mechanisms that we use to provision to 
ldap, google, and canvas (our LMS). We're trying to standardize on a 
single approach (message bus) to be used for all the synchronization; 
we're not there yet.

We're using custom group types to indicate whether or not a group should 
be provisioned into each of those targets. (I expect the number of 
targets to increase...) Any group can be thus tagged, and provisioned 
into one or more of those targets.

The Grouper Change Log Monitor actually sends a msg (with those types) 
to a process that we call the Demuxer. It contains the Rules telling it 
which synchers to forward the msg to. For instance, a change in a course 
group might be sent to multiple destinations (including, perhaps, a 
listener run by a dept, if the course is using services in the dept).

Obviously we're just starting down this road, and things may change as 
we learn.

> Thanks,
> Jeff
>
> On Apr 9, 2013, at 10:03 AM, Steven 
> Carmody<>
>   wrote:
>
> > Hi,
> >
> > I know my question is only tangentially related to Grouper, but at least 
> > there's a link, even if its weak. Thanks for your patience with this question!
> >
> > Brown replicates group memberships from Grouper to several different target 
> > systems: ldap, Google, and our LMS. We expect to add other targets over time. 
> > When changes occur in Grouper, a msg is placed on a msg bus. A listener picks 
> > up that msg, and has a set of rules telling it the one or more targets that 
> > the msg should be forwarded to.
> >
> > As we become more and more reliant on this infrastructure, we're asking 
> > ourselves what we should monitor with respect to the bus. We're keenly 
> > interested in the experience of other sites with respect to what sorts of 
> > problems they've encountered with a bus, and what sort of monitoring we 
> > should implement.
> >
> > Is it enough to just make sure that the bus is delivering msgs? (ie have a 
> > separate Q used by the monitoring software). Or do we need to build 
> > monitoring into all the Listeners, to make sure that they are all still 
> > processing msgs ? Or other approaches ?
> >
> > Thanks in advance for sharing your experience and suggestions!