Identify

Document Owner	Adhyan Srivastava
Document Status	Draft
Intern Working on this Project	Adhyan Srivastava
Mentors	Pranjal Goswami, Gaurav Saini
Source Code	https://github.com/ad-os/incubator-fineract
Documentation	Notification API Developer User Guide

Project Summary

Enable generic way of sending notifications - these notifications should be capable of being delivered via the Community App, via the Android app for field officers or Android self-service app.

Goal

To allow the user to directly act upon the alert directly from the notification (i.e. approve a client). This is what actionable means.

Approach for designing a generic notification system

The designing of the notification system will be done in two parts :-

Notification generation and storage
Notification Delivery

Notification Generation and Storage

1. Generation

This part contains information about how notifications are being generated in the backend and what design they follow for their generation.

- There is an event (like new Loan Request by Loan Officer) which is broadcasted.
- The event listener gets the message (that a new Loan Request was made)
  - Note :- This part (broadcasting and receiving a message) has to be asynchronous and it can be achieved by implementing message queues. Read about message queues here. We have used Apache ActiveMq for implementing this behaviour.
- The listener will now do something - for example :- Generate the notification and save it in the database by mapping it to the user for whom it was generated .

Each generated notification will contain the following attributes :

Subject --> Object --> Action --> Actor

Subject - The user who needs to be notified
Object - The object on which action happened
Action - The action that resulted in this notification
Actor - Who did it

All the notifications can fit into this model. Now for our standard branch manager - loan officer interaction the notification may look like

Notify [User 322] a [new loan application] was [created] by [User 432]

subject object action actor

2. Storage

This part contains information about how notifications are being stored in the database after their generation and what data model design they follow.

Two tables are being used for storing the generated notifications.

1. notification_generator :- This table contains the attributes of the generated notification.

id	object_type	object_identifier	action	actor	is_system_generated	notification_content	created_at

id :- The id of the generated notification.

object_type :- The type of object for the generated notification.

object_identifier :- The id of the object by which it is identified in the database.

action :- Type of action performed by the actor. The actions may be created, updated, deleted etc.

actor :- Username of the actor which acts upon the action.

is_system_generated :- It is a boolean value. This column tells whether the notification was generated by the system or by the user.

notification_content :- This column contains the text of the generated notification which would be shown to the user for whom it was generated. For e.g A new client with name ABC was created by mifos.

created_at :- It contains the date and time of the generated notification.

...................................................................................................................................................................................................................................................................................................................................

2. notification_mapper :- The table maps the id of generated notification with the id of a user for whom it was generated.

id	notification_id	user_id	is_read	created_at

id :- The id of mapped notification.

notification_id :- It contains the id of a notification which has to be mapped to a user. This is coming from the notification_generator table.

user_id :- It contains the id of a user for whom the notification is mapped.

is_read :- It is a boolean value. It tells whether the notification has been read by the user or not.

created_at :- It contains the date and time of the mapped notification.

Notification Delivery

For each REST request which the UI makes the server will send back a response header for e.g 'X-Notification-Refresh' with each response containing the value of either true or false depending upon whether new notifications are present on the server or not.
If no REST request has been made for certain time interval then a new REST request is made to check whether there are new notifications on the server or not.