Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Project Problem :
This project is a new feature request in the Apache and Mifos Initiative idea list for the Apache Fineract CN. The SMS/Email Notifications service would be a microservice developed on Apache Fineract CN to enable MFI members to get notified on events occurring on their accounts. This will impact the KYC of the organisation
Overview
Summary of Proposed Solution:Proposed Solution
My proposed solution is that notification topics are defined and potential recipients ( MFI members (Staff or Customers) ) are subscribed to the a topic when their account is created. Hence, in the occurrence of an event which matches the topic, a topic mapper will provide all staff members who need to be notified of the event ( for an Company client account is created hence the manager of the office).
NB: Topic definition definitions and topic mappings are persisted into the database.
So, when an actual event occurs, the system knows the subscribers to notify and now the notification itself has to be generated. An event listener will listen for Spring Event Emitters generated. Then the listening to the rest API controller Event emissions, will invoke the notification service
NB: each event emitter will have a corresponding listener listening to it.
The notification service will start by creating a notification object for the event, the notification object will be persisted in to the database and later added to a notification queue for processing.
The notifications are then mapped to the list of members who have to receive them (for instance a new client created event can send out a notification to the customer (customer), the manager of the office (staff) and anyone who needs to know of an new client account) and at this stage notification which do not have to be sent are discarded based the subscriber’s priority declarations.
The notification mappings are then persisted into the database and then queued into a notification-subscriber queue for processing
The notification-subscriber queue is take and transmission begins.
then converted into an Email or SMS. To personalise the message, a subscriber prefines their subscriber’s prefered language and communication preference stated during account creation . This is used to localize and separate notifications into SMS and Emails.
A member who selected a communication channel during account creation has indicated consent to receive notification hence we have to determine how often they will receive emails to avoid spamming them.
To determine how frequent a member gets a notification, the subscribers predefine notifications they would like to receive based on three priority categories (ie during account creation a user chooses a topic and assigns High, Medium and Low priority to it ). The system will also predefined default topics which have to go out eg: (Client created, Loan created, Account Created etc).
The localised messages are now formatted using a template associated to a topic.
The prepared messages will be passed to the Email services application containing email gateway such as google’s SMTP server or Twilio SMS to be transmitted. I propose that the system allows multiple configurations to accommodate cases where the application supports multiple organisations who use different services.
Data (Notification, Notification mapping, Templates, Topics, Topics mappings, Subscribers) generated will be persisted into the Microservice’s database.
Subsystems Breakdown
EventListener
An event listener will listen for Spring EventEmitters generated. For instance for a new client creation the NotificationEventListener will capture the event emittered and generate the notification content
NotificationEventListener
Has a JmsListener to listen to emitted event
Initiates the NotificationEventService
NotificationService
Has an SMSService Object
Has an EmailService Object
Creates a NotificationMapper
Creates a recipient and their notification
Gets recipients details
Localize the message using subscriber preference
Sends the email or SMS
Domain
This package will define the class for the entities in the problem domain.
Notification
States the Recipient
states the action
states the content
NotificationMapper
Takes topic mapping and map notifications to subscribers
NotificationMapperRepository
Accumulate NotificationMappings
Configuration
This will be used to configure the behaviour of the system.
NotificationConfiguration
Has SMSConfiguration
Has EmailConfiguration
SMSConfiguration
Define sender’s Number
Defines and sets sms service authentication credentials
EmailConfiguration
Defines and sets mail service host
Defines and sets mail service ports
Defines and sets authentication credentials
SMSService
Use the Twilio SMS service and google SMTP Server
SMSDomainService
AuthenticateClient
AuthenticationClientRecordsRepository
EmailService
EmailDomainService
AuthenticateClient
AuthenticationClientRecordsRepository
This component will use the template component to form the message format. The template will abstract the various message formats. I believe using Apache Velocity to prepare default themes and allow the user to generate custom templates woube be a good consideration. Also, given that Fineract CN and Velocity [ http://velocity.apache.org/ ] share the same license it will be easier to use them
Template
SMS templates
Email Templates
API & DAO
The DAO will be used to access resources in the Database and also persist data from the notification Microservice into its down database
TopicDAO
Get and set predefined topics
SubscriberDAO
Get and persist subscriber communication preference
Get and persist language preference
NotificationDAO
Get and persist content
Get and persist notification id
Get and persist action
Get and persist action ID
Get and persist office id
Get and persist topic mappings
TopicMapperDAO
Get and persist topic id
Get and persist topic mappings