Problem Overview
...
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.
...
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).
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.
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 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!
Service Roadmap/Feature
- I
mplement basic SMS and Email integrationInterface with TwilioGmail integration
Incorporate notification microservice into demo-server to enable testing.Basic Message TemplatingRest APIDocumentation
Add support for FINCN Mobile
- Implement FCM push notification with a multi-tenanted approach
- Resources: Official FCM Documentation, FCM implementation in Java,
- Implement FCM push notification with a multi-tenanted approach
- Replicate SMS/Email/Push Notifications functionalities for Portfolio/Office/Group/Employee Event Listener
- OTP through Push Notifications, SMS and Email
- Message Localisation
- Disable SMS and Email for specific users by using a custom field in customer
- Tenant Reputation Management
- Notification subscription and unsubscribe feature via SMS and email
- Message Templating
- Bulk SMS/Email/Push Notification
- Customized Bulk SMS
- Generic SMS
- Customized Messaging
- Templating
- Bulk SMS/Email/Push Notification
- Assess the feasibility of third-party integration with other messaging services
- Amazon SES Multitenant Solution
- Final test plan
Objectives for ongoing Iteration
Feature/Class | To Do: Features | Status |
---|---|---|
Rest Controller and Notification Manager |
|
|
Email Service |
|
|
Email Configuration Repository and schema |
|
|
SMS and Email Service |
|
|
SMS configuration Repository and schema |
|
|
Commands for SMS and Email Config and handlers |
|
|
Rest Controller and Notification Manager |
|
|
Templating Feature |
|
|
Create frontend in fims-web-app |
|
|
Authentication |
|
|
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.
...