Currently, Grouper sends messages (via AMQP or Amazon SNS) regarding changes going on in Grouper with create/read/update/delete messages pertaining to groups, privileges, memberships, attribute changes, and possibly other activities. With respect to memberships in particular, the change and resulting message is incremental and includes essential information about the change along with the subject, the group and the action - usually ADD/DELETE. While there appears to be general agreement Identity Management related messages need to be delivered in order and never deleted (a deleted message implies not delivering in order), it remains possible actions represented by messages "get lost" either by the message broker system or by the consumer/processor itself on the receiving end of Grouper messages, OR an application fails in some way and needs to be synchronized with data/groups from Grouper.
There are various integration patterns for applications and the following methods should address the scenarios for handling the overall problem.
As an "application/consumer" might be configured to receive many groups or a portion of the Grouper tree assigned to the app it would be needed for the mechanism to traverse the Grouper Stem tree from a starting point Stem thereby making it easy to sync up many groups or even all groups if Root is the starting point.
Initially, only interested in memberships, but there may be a desire to sync up privileges and other attributes or objects in the future.
There are many applications and scenarios in which a variety of integration techniques and security concerns may be at play causing the 3 integration patterns noted above to be applied.
Execution should be handled by Grouper Loader OTHER jobs making use of Quartz cron and supplying the needed parameters to control the jobs. There may be many jobs configured with different parameters. Parameters based on above include: limit_number_of_subjects, limit_size_of_message, stem_to_sync, message_type (sync-callback, fullsync) or it's all fullsync with the parameters governing behavior - a fullsync with no subjects implies callback.