Outbound SMS
Initial scope of the outbound SMS feature as documented by Gurpreet Luthra in email on April 27, 2013
Target release | Unscheduled |
|---|---|
Theme | Mobile Integration |
Document status | DRAFT |
Document owner | @Gurpreet Luthra (Unlicensed) |
Designer | |
Developers | |
QA |
Goals
The main idea of the Outbound SMS feature is to provide MifosX the ability to send SMS to clients, loan officers and others for various events and announcements -- like pending disbursement, pending payments, task list, monthly cash summary, etc.
Currently Mifos and the client and portfolio data it contains is only accessed by the staff of the MFI. However, the majority of clients served by MFIs own mobile phones. A simple yet powerful way for them to interact with the data in Mifos is via SMS. MFIs have requested the ability for both inbound and outbound SMS communication to send notifications to their clients and to enable clients to retrieve information about their accounts. When living on less than $2/day, this simple yet timely interaction with their financial accounts is extremely important.
Background and strategic fit
Apart from the client need for this accessible and affordable stream of data, there are many technology companies and mifos integrators who are seeking to integrate SMS modules to send data outbound from their applications or services.
Assumptions
Plugin Based Implementation: A plugin design where one can plugin an SMS gateway service to MifosX which takes input as a phone number and a message, and sends out an SMS.
SMS Gateway Plugins: Implementation for maybe 2 SMS providers as plugins: Twilio, Nexmo, or Telerivet. (@Gurpreet Luthra (Unlicensed) how about initially targeting FrontlineSMS, FLS for short, as this would easily give us several gateways "for free", see my thoughts in , and then later extend that to other direct connectors, via and more?)
Requirements
# | User Story Title | User Story Description | Priority | Notes |
|---|---|---|---|---|
1 | SMS Queue: | A queuing mechanism, where SMS events to be posted are put on a queue, and then a queue reader picks each SMS up and posts it out through the configured SMS Gateway. This queue should be visible in UI (exposed through API), with a status of whether the SMS was sent successfully or not. Attributes: Target User, Phone Number, Message, Time, Success/Failed, Status Message (to indicate error message or success message), Triggered By (Username/System). | TBD |
|
2 | Provide a Simple SMS sending capability for a Client: | Provide the ability to send any text sms via a simple dialog box in Client screen. This is more for show casing that a loan officer can maybe send some message to the client via the system. Some questions here: | TBD |
|
3 | Identify Automatic System Notification SMS Events | We need to identify some system events and scenarios which we would like to have integrated via SMS notification. Can you give some suggestions on what these could be? As I understand, there would be 3 types of SMS notifications:
I need examples or what events we would like to support to begin with. Some that come to my mind are (based on my super limited domain knowledge):
| TBD | This contains a LOT - we should split this up more fine grained.. the schedule based part of this, with templates, would be |
4 | SMS Notification Configuration Screen | Need to create a configuration screen where all SMS based notification configurations can be done. This will contain the following:
| TBD | Templates should be defined quite separately and outside of the respective SMS Gateway configuration. |
User interaction and design
Questions
Below is a list of questions to be addressed as a result of this requirements document:
Question | Outcome |
|---|---|
| A: Don't; it will simply fail. |
| A: Giving the SMS gateway service API the name as an input as well is probably not a good idea in general. (With FrontlineSMS, you could then imaging to automatically create Contacts in FrontlineSMS.) |
| A: that will probably quickly get complicated; KISS, and forget it for now. |
| A: Just grey out the "Send SMSthat will probably quickly get complicated" button/icon? With a tooltip "Cannot send SMS as no phone number." |
Comments from Michael Vorburger on April 30.
1. Plugable +1! Does MifosX already have any nice plug-in architecture? In an ideal world, such SMS Providers should be external JARs, droppable into some directory, registering themselves.. we don't need to go OSGi for this; http://docs.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html may be enough (I think, would need further investigation; I haven't tried). If that's too much for now, then at least Java interfaces / manual Spring configuration to pick which one - before we have a config. UI.
2. SMS Gateway Plugins: An implementation for FrontlineSMS also would be fairly high up on the list if I gave the priorities.. with FrontlineSMS then plugged into a phone - or even Twilio and Nexmo itself; I think do think even that scenario actually makes sense - because you get a full fledged "Outlook-like SMS Center" - without having to develop UI for queue management, maybe even multi-ling templating (to check; http://frontlinesms.ning.com/forum/topics/sms-templates?). If there are gaps for what we need, we could certainly contribute what we are missing in FrontlineSMS to that project - to benefit others outside Mifos. Therefore personally I think focusing directly on the integration from the start may be the best way to go - thoughts?
3. SMS Queue: I think if we do this right, this could be just another SMS provider implementation? An SMS Queue is nothing else than just another provider - which instead of actually sending it just stores the message it receives in the DB (forget JMS, no need) and then hands it over to a lower-level provider.
4. I like this as an obvious first trivial UC. We should KISS (keep it simple & stupid), specifically - see questions above.
5. Functional comment: We actually really need to start a Wiki page for refining very concrete functional scenarios for outboundSMS. With high level of detail / spec on what exactly is expected for each use case. I think the Wiki might actually already have some older pages (some may even have been by me and/or Udai; 2 years ago), search for "SMS" and do feel perfectly free to clean up whatever you find? ;) Then combing the mailing list we'll find some of this (e.g. https://mail.google.com/mail/u/0/?shva=1#search/label%3Amifos-users+sms/13be18d3829629ca). For each UC, this would have a section describing it from an end-user point of view, specify UI expectations, etc. Someone who does not have the functional/domain understanding should be able to pick one of those use cases and have a go at it.
5. Technical comment: There is a more generally useful concept to capture architecturally here.. it would be really cool if we could use this opportunity to properly introduce "business events" into the architecture. Such an "Event" is functionally anything like "SendClientSMS" (manually triggered by someone from within 'a', not 'the' one and only, MifosX UI), or LoanApproved etc. etc. These should having nothing to do with SMS-ing per se. Technically imagine just simple JavaBeans and a super light weight postBusinessEvent()-like API - I'm NOT proposing any new heavy weight infrastructure (NO JMS, ESB & Co!) - just a clear notion in the code of what Mifos' Business Events are actually available. Spring's light weight Custom Events may be of interest, http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/beans.html#context-functionality-events. MifosX plugins such as the SMS subsystem would then register for and act on such events to do what they have to do - but other future other-system-integration-type plug-ins to be written in the future could benefit from this as well...
6. I would keep that a lower priority story for starters... *.properties file may be just fine to kick things off, UI later? Queue management etc. could be in FrontlineSMS?