Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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:

Children Display

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

GSoC 2018 Proposal

Project: Fineract SMS/Email Notification Microservice.

Applicant: Ebenezer Kwesi Akyen Graham

Abstract

...

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 members to select notifications which the member chooses during account creation.

Project Goals

  1. Develop a SMS/Email notification mircroservice

  2. Incorporate the microservice into a demo-server

  3. Incorporate the Notification user interface into the fims-web-app

    1. Interface for microservice configuration

    2. Interface to select frequency for members

    3. Interface to subscribe members to specific events

Proposed Solution

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.

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

Subsystems Breakdown

EventListener

An event listener will listen for EventEmitters generated. For instance for a new client creation the NotificationEventListener will capture the event emittered and generate the notification content

  • NotificationEventListener

    • Has microservice instance

    • Has a JmsListener to listen to emitted event

    • Has an SMSGateway/EmailGateway Object

    • Creates a NotificationMapper

    • Creates a recipient and their notification

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

  • NotificationConfiguration

    • Has SMSConfiguration

    • Has EmailConfiguration

  • SMSConfiguration

    • Defines accountSID

    • Defines auth Id

  • 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

  • Senders number

  • Retrieves organisation’s sms API configuration

  • Message content

EmailService

  • recipient addresses

  • Sender’s address

  • Authenticate email gateway

  • Mail content

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

Web Interface

  • An interface to configure SMS and email frequency

  • An interface to configure organisation(s) SMS API

  • An interface to configure organisation(s) Email Gateway

Database Structure

Entity 1: Subscriber

  • Id

  • communication_preference

  • language_preference

  • high_priorities

  • medium_priorities

  • low priorities

Entity 2: SMSConfigurations

  • Id

  • organisation

  • auth_token

  • accountid

  • option

Entity 3: EmailConfigurations

  • Id

  • organisation

  • auth_token

  • auth_secret

  • port

  • host

  • option

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

Feature/ClassTo Do: FeaturesStatus
Rest Controller and Notification Manager
  1. Add fetch operations
  •  Completed
Email Service
  1. Allow configuration of service after instantiation
  •  Completed
Email Configuration Repository and schema
  1. More query for update and delete
  •  Completed
SMS and Email Service
  1. Allow reconfiguration of service after instantiation
  •  Completed
SMS configuration Repository and schema
  1. More query for update and delete
  •  Completed
Commands for SMS and Email Config and handlers
  1. Update and delete commands
  •  Completed
Rest Controller and Notification Manager
  1. Restructure API Naming Conventions
  •  Completed
Templating Feature
  1. Create basic HTML templating feature with thymeleaf
  •  Completed
Create frontend in fims-web-app
  1. More query for update and delete
  •  Completed
Authentication
  1. Implement Permitted Feign Client Authentication
  •  Completed




Objectives for 3rd Iteration



Completed

Implement SMS and Email functionality

Incorporate notification microservice into demo-server

Message Template

Create Rest API Documentation

Testing of SMS and Email from the web interface

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

...