egov-notification-sms
Objective:
The objective of this service is to create a common point to manage all the SMS notifications being sent out of the platform. Modules like PT, TL, PGR etc make use of this service to send messages through the Kafka Queue.
Requirements:
Prior Knowledge of Java/J2EE
Prior Knowledge of SpringBoot
Prior Knowledge of Third party API integration
Prior Knowledge of REST APIs and related concepts like path parameters, headers, JSON etc
Prior Knowledge of Kafka and related concepts like Producer, Consumer, Topic etc.
Setup:
Step 1: Start the egov-notification service present in the following repo:
https://github.com/egovernments/core-services/tree/master/egov-notification-sms
Or port forward the egov-notification service.
Configurable Properties:
Following are the properties in application.properties file in notifcation sms service which are configurable.
Property | Value | Remarks |
kafka.topics.notification.sms.name | egov.core.notification.sms | It is the topic name to which the notification sms consumer would subscribe. Any module wanting to integrate with this consumer should post data to this topic only. |
sms.provider.class | Generic | This property decides which SMS provider is to be used by the service to send messages. Currently, Console, MSDG and Generic have been implemented. |
sms.provider.contentType | application/x-www-form-urlencoded | To configure form data or json api set sms.provider.contentType=application/x-www-form-urlencoded or sms.provider.contentType=application/json respectively |
sms.provider.requestType | POST | Property to configure the http method used to call provider |
sms.provider.url | URL of the provider. This will be given by the SMS provider only. | |
sms.provider.username | egovsms | Username as provided by the provider which is passed during the API call to the provider. |
sms.provider.password | abc123 | Password as provided by the provider which is passed during the API call to the provider. This has to be encrypted and stored |
sms.senderid | EGOV | SMS sender id provided by the provider, this will show up as the sender on receiver’s phone. |
sms.config.map | {'uname':'$username', 'pwd': '$password', 'sid':'$senderid', 'mobileno':'$mobileno', 'content':'$message', 'smsservicetype':'unicodemsg', 'myParam': '$extraParam' , 'messageType': '$mtype'} | Map of parameters to be passed to the API provider. This is provider-specific. $username maps to sms.provider.username $password maps to sms.provider.password $senderid maps to sms.senderid $mobileno maps to mobileNumber from kafka fetched message $message maps to the message from the kafka fetched message $<name> any variable that is not from above list, is first checked in sms.category.map and then in application.properties and then in environment variable with full upper case and _ replacing -, space or |
sms.category.map | {'mtype': {'*': 'abc', 'OTP': 'def'}} | replace any value in sms.config.map |
sms.blacklist.numbers | 5*,9999999999,88888888XX | For blacklisting, a “,” separated list of numbers or number patterns. To use patterns use X for any digit match and * for any number of digits match |
sms.whitelist.numbers | 5*,9999999999,88888888XX | For whitelisting, a “,” separated list of numbers or number patterns. To use patterns use X for any digit match and * for any number of digits match |
sms.mobile.prefix | 91 | add the prefix to the mobile number coming in the message queue |
Entities:
SMS: Model to capture the sms information. The object pushed onto the queue must be in accordance to this model. Contains mobileNumber and message.
How does it work?:
This service is a consumer, which means it reads from the kafka queue and doesn’t provide facility to be accessed through API calls, there’s no REST layer here. The producers willing to integrate with this consumer will be posting a JSON that is in accordance with the entity mentioned above onto the topic configured at ‘kafka.topics.notification.sms.name’.
The notification-sms service reads from the queue and sends the sms to the mentioned phone number using one of the SMS providers configured. The decision as to which provide is to be picked is controlled by the property ‘sms.gateway.to.use’ from the application.properties file. Currently, SMS Country and MSDG are implemented. The API contract of these providers is available on the respective portals.
There is a common interface which has to be used incase a new provider is to be configured. The current code-base has 2 implementations of the same interface. Please ensure that the implementation follows the norms of the provider wrt to encryption, masking, rate-limiting etc.
We’ve tested this service with localised msgs in Hindi, Kannada and other languages, We’ve observed that both MSDG and SMS Country have seamless support for localised msgs. Please go through the API documentation of these SMS gateways to support localised messages and also for any new provider that is implemented.
EXAMPLE:
Kafka -
Topic: egov.core.notification.sms
Body:
{"mobileNumber": "9480411228", "message":"Hey, how you doing?"}
Messages -
Interaction Diagram:
