Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] RE: Recommendation for EsbConsumer

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] RE: Recommendation for EsbConsumer

Chronological Thread 
  • From: Rob Hebron <>
  • To:
  • Subject: Re: [grouper-dev] RE: Recommendation for EsbConsumer
  • Date: Tue, 10 May 2011 07:08:33 +0100

However, there’s one major drawback: the EsbListenerBase abstract class

defines the “dispatchEvent” event method as taking a JSON string

I think it would be much more effective if the API instead accepted a

single EsbEvent object as the parameter of the “dispatchEvent” method.

This would then turn EsbConsumer into a generic provisioning connector

(which would probably mean it could be renamed).

We actually have made these modifications for our implementation, and

we’d love to share them with the community if you think they would be

Note you can convert back to JSON to the beans if you like J. Also note
that you

would get multiple EsbEvents, not just one. That said, I do think your
idea is good,

Rob owns this code, Rob, what do you think?

Thinking back, I believe that the original design allowed for single events only, then I made changes to allow for multiple events. I have never used multiple events in a live environment (for similar reasons to those Nathan outlines), so I'd be happy to make the change if no-one else is using it for multiple events.

We've been using the ESB consumer at Cardiff University to sync all group memberships from Grouper to LDAP for about 6 months now and it has proved very reliable, with no need for periodic bulk sync. This does rely on each part of the chain reporting errors correctly so that retries happen properly where appropriate. On a related point: I find that the latency in the ESBConsumer is insignificant in comparison with latency in other operations in the provisioning chain.


Archive powered by MHonArc 2.6.16.

Top of Page