Hi Ebenezer, I believe you're planning to monitor at the wrong abstraction level. Currently each command handler has a so-called @EventEmitter, which places a message on the ActiveMQ message queue. A command handler might change multiple tables while persisting the data it needs to persist, but it will only emit one ActiveMQ message. So your monitor should listen to ActiveMQ rather than monitoring the database. In all of the component-test modules for the services, there is a listener module which shows how to listen to the ActiveMQ events defined for that service.
Also a question: how do you plan to solve the localization problem in your design? IE what if an institution has customers who don't speak the same language as each other? If you'd like to put your design in confluence, create a confluence id and I'll give you edit permissions. Best Regards, Myrle On Fri, Mar 16, 2018 at 3:17 PM, Ebenezer Graham <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *Hi,I would like to contribute to the development of the new notification > microservice for Fineract CNThis is my thinking around the implementation > of notification microservice for GSoC. I would like get your input on the > approach if possible. The Notification Microservice could be divided into > the following subsystems.Preferably, refactor the existing codebase to > generate the triggers after passing the necessary checks in the > backend.Alternatively, A trigger creator can be made within the > microservice to avoid tampering with the existing codebase.TriggerGenerator > - Monitor Database for new records and generate and eventThe resolver will > accept event from the generator and then determine what has to be done. The > Resolver then determines the kind of notification required, an email or an > SMS I will determine if its an instant notification or need to be scheduled > for later release TriggerResolver - Listen for triggers- Determine the kind > of notification- Forward instant notification- Aggregate Notification for > scheduled releaseThis component will be abstracted to accommodate future > changes in message formats. It will create DAO for the various databases > accessDAOFactory - clientDAO- loanDAO- etcThe message resolver will gather > the content from the database using the DAO to form the message and all > relevant address.This component will use the template component to form the > message structure. MessageResolver - Gather message content using internal > DAO- Gather addressesThis component will receive the message and connect > with carrier domains and mailing services to send the > notifications.MessageHandler - Send Messages- Authenticate with carrier > domains and create mail servlets- Retry sending notification if > failed.EmailHandler extends MessageHandler - Prepare Email SMSHandler > extends MessageHandler - Prepare SMSThe template will abstract the various > message formats and work with the MessageResolver.Template - SMS templates- > SMS templates- Email Templates- CC/BCC : StakeholdersI have attached a > class diagram to help visualize the components. * > > *Best Regards,* > > *Ebenezer Graham* > > *BSc (Hons) Computing* > > > [image: EmailSignature.png] > > Beau Plan Business Park | West Building > > Pamplemousses | Mauritius > > > <http://www.pactmart.com/> > <http://www.pactmart.com/> > www.pactmart.com | Freelancing made easy. > > skype: > ebenezer.graham > | Phone: > +230 5840 9206 <+230%205840%209206> > GitHub <https://github.com/ebenezergraham> | LinkedIn > <https://www.linkedin.com/in/ebenezer-graham/> | Twitter > <https://twitter.com/pactmart> | Facebook > <https://www.facebook.com/pactmart> | Personal Website / CV > <http://ebenezergraham.github.io/> > > > *“Practice isn’t the thing you do once you’re good. It’s the thing you do > that makes you good.”* > -*Malcolm Gladwell* > > >
