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.

Navigation:

Description

The notification service can be described as a messenger service responsible for handling email, push notifications and SMS transactions. It enables members (Staff and Customers) of a tenant to get notified of events occurring on their accounts.

It uses JMS Listeners to subscribe to event topics 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.

Please consider contributing! 

1. Repository
2. Drive Containing Relevant documents

Service Roadmap/Feature

1. Implement basic SMS and Email integration
   1. Interface with Twilio
   2. Gmail integration
2. Incorporate notification microservice into demo-server to enable testing.
3. Basic Message Templating
4. Rest API
   1. Documentation

5. Add support for FINCN Mobile

   1. Implement FCM push notification with a multi-tenanted approach
      1. Resources: Official FCM Documentation, FCM implementation in Java, 
6. Replicate SMS/Email/Push Notifications functionalities for Portfolio/Office/Group/Employee Event Listener
7. OTP through Push Notifications, SMS and Email
8. Message Localisation
9. Disable SMS and Email for specific users by using a custom field in customer
10. Tenant Reputation Management
    1. Notification subscription and unsubscribe feature via SMS and email
11. Message Templating
    1. Bulk SMS/Email/Push Notification
       1. Customized Bulk SMS
       2. Generic SMS
    2. Customized Messaging
       1. Templating
12. Assess the feasibility of third-party integration with other messaging services
    1. Amazon SES Multitenant Solution
13. Final test plan

Objectives for ongoing Iteration

Objectives for 3rd Iteration

Other Resource

Building a notification service in a multi-tenanted service-oriented architecture can be very complex. Here are a few resources to help assess some of the complexities involved.

1. Building scalable multitenant email sending programs

Problem Overview

Summary of Proposed Solution:

My proposed solution is that notification topics are defined and potential recipients ( MFI members (Staff or Customers) ) are subscribed to a topic when their account is created. Hence, in the occurrence of an event which matches the topic, a topic mapper will provide all members who need to be notified of the event ( for an Company client account is created hence the manager of the office).

NB: Topic 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 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.

To personalise the message, a subscriber’s prefered language and communication stated during account creation 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 messages are now formatted using a template associated to a topic.

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 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.

...