Grouper Users - Open Discussion List

[Martin van Es <>]

Hi, thx for the answers!

I think the noop LDAP target that does lookups in grouper using PIT queries would fit my ideas best. SPML is not a requirement, it's just a way to get the things needed to do accross I could think of based on what Grouper supports.

Chris, querying grouper_change_log_entry_v doesn't feel like a very safe bet if the name of the table or columns change? Are the logs in grouper_change_log_entry_v kept indefinately or are they purged once in a while? Should we purge them after consuming? Is there a quick 'n dirty way to query a hsqldb without writing java code?

On Mon, Dec 17, 2012 at 9:35 PM, Chris Hyzer <> wrote:

If you want the diffs from an hour ago without the PSP, you could do a sql query against the grouper_change_log_entry_v table, that is how incremental provisioning works with grouper.  You might need to query PIT for more attributes etc…  but you still need to code the SPML part etc.

 

 

 

From: [mailto:] On Behalf Of Martin van Es
Sent: Monday, December 17, 2012 7:56 AM
To:
Subject: [grouper-users] Incremental pull-based provisioning

 

Hi,

 

I'm currently asked to write a technical design in which grouper is the source of provisioning for collaboration shares in University AD/DFS.

The provisioning route is quite awkward and we will start off by using their in-house built relation manangement tool. This tool could easily be modified to consume the groups and relations in grouper, but not so well to be a provisioning target (if alone because of lack of Java expertise), hence my following question:

 

Is there, other than making a scheduled full export, a way to collect time-based incremental provisioning information from Grouper without defining a provisioning target? It would be nice to have SPML messages based on a question like: show me everything I need to do between an hour ago and now. Or, for full reconciliation: everything between 0 and now, which would look like the raw export in SPML format.

 

I could think of a proxy service creating these messages based on a stem/group crawl with PIT queries, but a native interface would be a lot more robust, I guess? Can anyone elaborate on this idea (crawl+PIT)? Will that work? Another idea I had was creating a substitute LDAP target that is used to calculate the diff's against? Not so robust if provisioning LDAP or relation tool fails. Although import should be resilient for double provisioning instructions, missing one could be harmful.

 

 

Best regards,

Martin

--
If 'but' was any useful, it would be a logic operator

--
If 'but' was any useful, it would be a logic operator