Grouper Developers Forum

[Gagné Sébastien <>]

Oh I see now.

 

What I was suggesting is :

Option 3 : A method is called

 

The loader would do anything after the call; it will be “the method”’s tasks to get the members from SQL, modify them based on configurations and compare them against a subset of members of a subset of groups based on Grouper attributes

 

So this loader type would basically become more of a scheduler than a loader process since it could be used to fire other tasks that don’t have anything to do with external members. Sure we could simply use an external scheduler that could call a gsh script, that is our original design, but I thought that it might be better integrated with a loader type.

 

As I said, this isn’t required as we have another solution for this

 

De : Chris Hyzer [mailto:]
Envoyé : 3 juillet 2012 12:02
À : Gagné Sébastien
Cc :
Objet : RE: Custom Grouper Loader

 

Option 1: A method is called which gets external memberships, compares to the Grouper registry, adds/removes members

Option 2: A method is called which gets external memberships, and returns them to the loader wrapper in a certain form, and then automatically it will compare to the registry and add and remove for you

 

Chris

 

 

From: Gagné Sébastien
Sent: Tuesday, July 03, 2012 10:56 AM
To: Chris Hyzer
Cc:
Subject: RE: Custom Grouper Loader

 

I’m not sure what’s the difference between the two options you said. My initial idea was something like a simplified duplicate of the LDAP loader where you use another type of attribute (e.g. confCustomLoader) with basic scheduling attibutes and add a new “GrouperLoaderType.scheduleCustomLoads();” that schedules all the configured groups. You could then use a JEXL _expression_ to call any method when the job runs.

 

This would mean that the loader isn’t aware of the success of the operation, but that might be OK. Throwing an exception could be used when there’s an error or your idea of an interface would be interesting since it could return a Boolean for the success.

 

 

 

De : Chris Hyzer []
Envoyé : 3 juillet 2012 10:06
À : Gagné Sébastien
Cc :
Objet : RE: Custom Grouper Loader

 

Sure, we can do that.  The simplest would be you specify the attributes on a group where the loader type is custom and you specify the class which implements some interface with one method.  Another option is to reuse some of the loader logic already there where you get the data into the form that the existing loader uses, and it uses that to compare to what is in Grouper, does the adds/removes, and logs everything.  Either way shouldn’t be a lot of work, and I can help with the Grouper side.

 

Thanks,

Chris

 

From: Gagné Sébastien
Sent: Tuesday, July 03, 2012 10:01 AM
To: Chris Hyzer
Cc:
Subject: Custom Grouper Loader

 

Hello Chris,

I’m designing our own custom loader for our academic source and I see that I’ll be redoing some parts that are already in the LDAP loader. This gave me the idea that maybe a third type of loader could be included in Grouper : a custom Grouper loader.

 

Basically it would be an empty shell where you would plug in your own custom class that does the work. The loader shell  would take care of scheduling the job and checking if it’s still enabled, but would have no business logic other than calling your custom process, the class call could be specified like the Grouper Name _expression_, e.g. ${customProcess.loadAcademic()}

 

This could probably applied to other scheduled processes and could become a way to schedule various tasks in Grouper and not only “loader” type of tasks.

 

I’m not sure about if there’s a lot of added value and how much work is required to add it, but maybe some others might like to have an easy way to include custom processes in Grouper. If you find it a good idea I could do the code and contribute it for the next version (2.1.2 ?).

 

 

Sébastien Gagné,     | Analyste en informatique

514-343-6111 x33844  | Université de Montréal,

                     | Pavillon Roger-Gaudry, local X-100-11