Grouper Users - Open Discussion List

["Gettes, Michael" <>]

I thought this was an interesting idea, thanks Greg.  From my short investigation into otherJob it appears it is a way to hook the scheduling capabilities of grouper (quartz) with running grouper code/functions which in itself is kinda cool.  But, it’s not
 evident to me how this would achieve what I am asking.  I want to run a loader job.  I just don’t want to be limited by SQL/LDAP.  I guess what I am seeking is the essential components of the SQL loader job modified into 3 components:

1) Run an external program to produce the dataset associated with the grouperLoaderQuery phase of processing in a SQL loader job. Most likely the value of this attribute is the full filesystem pathname to the program to execute.  The output (maybe stored in a filename passed to the program as a parameter on execution) would be the same output as defined by the grouperLoaderQuery SQL job attribute.  The first line of output would be tab-delimited “column names” and the remaining lines would be tab-delimited “columns” in the same order to be consumed by the grouper loader processor.

2) Run an external program to produce the dataset associated with the the grouperLoaderGroupQuery phase of processing in a SQL loader job. Most likely the value of this attribute is the full filesystem pathname to the program to execute.  The output (maybe stored in a filename passed to the program as a parameter on execution) would be the same output as defined by the grouperLoaderGroupQuery SQL job attribute.  The first line of output would be tab-delimited “column names” and the remaining lines would be tab-delimited “columns” in the same order to be consumed by the grouper loader processor.

3) with all the other possible parameters of a loader SQL type job, process the resulting datasets from 1 and 2 as usual.

I am not seeing how to influence/alter a loader job to behave in this fashion without our fearless grouper devs providing an extended capability of the loaderJob itself.  Doing this would seem to provide infinite extensibility to the essential grouper loader function.

I hope this helps.

/mrg

On Feb 13, 2019, at 9:02 PM, Greg Haverkamp <> wrote:

Currently, grouper supports loader jobs of LDAP and SQL and an additional capability to inject messages to process changes related to an individual - a way of sparking loader jobs for one person instead of in bulk - at least this is my interpretation.

Perhaps I don't understand the nuances of what you're looking for, but could you use the otherJob construct for this?  Primarily what you want is something running as Grouper in the JVM with the daemon, right?

Or it's possible that I'm overestimating what's possible with an otherJob, and there's a limitation I don't know of.

Greg

On Wed, Feb 13, 2019 at 2:38 PM Gettes, Michael <> wrote:

Hi all,

Currently, grouper supports loader jobs of LDAP and SQL and an additional capability to inject messages to process changes related to an individual - a way of sparking loader jobs for one person instead of in bulk - at least this is my interpretation.

I have a need for loader jobs to be of an arbitrary nature - call a program, written in any language, which might do REST calls or whatever and return, in bulk, something similar to what the loader job now receives from SQL/LDAP.  This way I can go against alternative sources without the need of staging the data into LDAP/SQL but get all the benefits and scale of a grouper loader job.

Does anyone else see a need for this?  Grouper dev dudes… (and dudettes)… have you considered this?  I can only assume you have since you guys have thought of a great many things for grouper.

Many thanks for your time and consideration especially if you choose to respond.

/mrg