The notification service can be described as a messenger service responsible for handling email and SMS transactions. It enables an organisation's members (Staff and Customers) to get notified of events occurring on their accounts.
There are arrays of events occurring in other microservices, therefore, there is a need to streamline these events and notify MFI members of significant events. This will impact the KYC of the organisation and the user experience.
This problem has led to the need for a microservice such as this one to be developed to enable MFI staff to select notifications which need to be sent or the member choose specific events during account creation.
Develop an SMS/Email notification mircroservice
Incorporate the microservice into a demo-server
Incorporate the Notification user interface into the fims-web-app
Includes an interface for microservice configuration
Includes an interface to select the frequency for members
Includes an interface to subscribe members to specific events
When an event occurs, the system knows the subscribers to notify and now the notification itself has to be generated. An event listener listening to the rest API controller event, will then create an instance of the corresponding mircroservice interact with it hence creating a notification
NB: each mircroservice will have a corresponding listener listening to it event emitters. For instance, AccountingListener, OrganisationListener etc
The notification service will start by creating a notification object for the event, the notification object will be persisted into 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 a 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 taken and transmission begins.
To personalise the message, a subscriber’s prefered language and communication stated during account creation is used to localize and choose the gateway to use. For instance, if a customer indicates only SMS is sent through to their mobile and not the email. If both are indicated both SMS and email is used
A member who selected a communication channel during account creation has indicated consent to receive notifications 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 messages are now formatted using a template associated with an event.
The prepared messages will be passed to the application containing email gateway such as google’s SMTP server or Twilio SMS to be transmitted. I propose that the systemallows multiple configurations to accommodate cases where the application supports multiple organisations who use different services.
An event listener will listen for EventEmitters generated. For instance, for a new client creation, the NotificationEventListener will capture the event emitted and generate the notification content
Has microservice instance
Has a JmsListener to listen to the emitted event
Has an SMS gateway / EmailGateway Object
Creates a NotificationMapper
Creates a recipient and their notification
Localize the message using subscriber preference
Sends the email or SMS
This package will define the class for the entities in the problem domain.
States the Recipient
states the action
states the content
Takes topic mapping and map notifications to subscribers
This will be used to configure the behaviour of the system. This will be used to help scale the transmission of notifications in a day where more notifications are going out. (for instance an organisation with multiple gateways can scale in high)
Also, in a case where the Application support multiple MFI each MFI can get their own notification
Defines auth Id
Defines and sets mail service host
Defines and sets mail service ports
Defines and sets authentication credentials
Use the Twilio SMS service and google SMTP Server
Has Senders number
Has recipient number
Retrieves organisation’s SMS API configuration
Authenticate email gateway
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 would 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
It uses JMS Listeners to subscribe to event topics in registered the system's message broker (ActiveMQ). Once the message has been received, it determines the template, the gateway and the builds the content of the message