Ed,
http://telerivet.com/examples#api
The above link (Telerivet) is what I guess could be used by us. We can
evaluate this too.
Like I said, I think the idea would be to implement it in a manner that we
are agnostic of the SMS Gateway. Then we can have plugins for Twilio, or
Telerivet, etc implemented, and allow people to choose which ones they want
to turn ON, depending on suitability based on country, pricing,
convenience.
Regards
Gurpreet
On 27 July 2013 22:40, Edward Cable <[email protected]> wrote:
> Gurpreet,
>
> There continues to be more and more requests for the SMS integration so I
> wanted to bring this thread to the mifos-users list and share some other
> recent updates.
>
> I also posted this to this wiki in spirit of moving Gurpreet's notes
> towards a spec -
> https://mifosforge.jira.com/wiki/display/MIFOSX/Outbound+SMS
>
> I just learned that Nuru has launched an internal SMS platform for all the
> programs across their organization - NuruSMS -
> http://www.nuruinternational.org/blog/healthcare/nuru-short-message-service-launch/
>
> It's quite exciting and they utilized Telerik as their SMS gateway service.
>
> Telerik seems to have some good potential with more affordable and better
> support for international markets than Twilio and Nexmo -
> http://telerivet.com/product/why?lang=en
>
> Ed
>
>
> On Mon, May 20, 2013 at 3:24 AM, Gurpreet Luthra <[email protected]
> > wrote:
>
>> Michael,
>>
>> Have you used FLS? How is your experience using FLS?
>>
>> In essence I think you are suggesting that MifosX can delegate all SMS
>> sending features to FLS. I read more on FLS today, and it does seem to have
>> many SMS sending features, and also features to "collect" inputs via SMS.
>> Although I feel the latter isn't really a priority right now for MifosX,
>> but it could become one in time.
>>
>> The drawbacks I see with FLS approach are as follows (Warning: this is
>> based on my 2 hours reading of FLS):
>> 1. There doesn't seem to be any obvious integration strategy with FLS (no
>> APIs, Programmable plugin, etc). So I am not sure how MifosX would "talk"
>> to FLS, and how will FLS talk to MifosX when we introduce use cases like
>> "Customer sends an SMS to inquire about next repayment).
>> 2. FLS seems to be a desktop app, that one installs and then uses. How
>> will the experience be if we are looking at MifosX from a Cloud/Amazon
>> deployment strategy?
>> 3. One more "product" or "component" is added to the stack -- increasing
>> maintenance work for MifosX non-cloud customers.
>>
>> Since adding SMS support to MifosX isn't very difficult, I would
>> recommend that we do both:
>> 1. Add SMS support in MifosX, and allow MifosX to be able to send SMS
>> messages based on Events/Scheduled Jobs.
>> 2. Add ability to talk to FLS (later), by seeing if we can create
>> "groups" for various entities into FLS, so that bulk messaging to
>> groups/regions is possible from within FLS.
>>
>> On a side note:
>> 1. ThoughtWorks does have good relations with FLS, and in fact last year
>> we spent a lot of voluntary effort helping in translation efforts for
>> FrontLine SMS V2 (https://github.com/gsluthra/frontlineSMS-Translations).
>> So if needed we can try and get them on a call for inputs.
>> 2. I also did not understand much about what Sander/Musoni said. The
>> business rule idea although sounds cool in principle, seems like an
>> overkill to me right now for MifosX. Should wait for feedback from the
>> field, before implementing something this generic.
>>
>> What do you (and others) think?
>>
>>
>> Regards
>> Gurpreet
>>
>> Join the Humanitarian Software
>> Program<https://my.thoughtworks.com/groups/humanitarian-software-program> to
>> help and contribute OpenMRS, RapidFTR, Camfed and MifosX SIP Projects. We
>> are looking for Volunteers!
>>
>>
>> On 20 May 2013 06:44, Michael Vorburger <[email protected]> wrote:
>>
>>> Hello (dropping off Sander/Musoni),
>>>
>>> so if we're serious about using GSoC capacity for SMS stuff, we probably
>>> need to agree our requirements a bit more? I've given this a little more
>>> thought, and will try to write up UCs on the Wiki when I get a moment.
>>>
>>> Something we should may be decide about together in the near future is a
>>> choice between how much SMS support we want to built into Core Mifos X
>>> Platform, versus how much to just enable interface with, say, FrontlineSMS
>>> - personally I would meanwhile have an increasingly strong preference
>>> for the latter. For example, for the simple UCs of outgoing SMSs to a
>>> client/LO/group/area (as described in
>>> https://mifosforge.jira.com/browse/MIFOSX-119), should this really be
>>> in Mifos? How about doing this straight in FrontlineSMS, only? With the
>>> Mifos clients & LOs + MFI staff replicated into FLS via... a mechanism
>>> to be decided? Groups/areas etc. could relatively easily be mapped as
>>> Groups or Custom Fields/Tags in FLS... access control would have to be
>>> considered, as its quasi non-existant in FLS (just login), but is that a
>>> really a problem in real-life MFI? The reference UI could simply have a
>>> link directly into the Send screen of FLS?
>>>
>>> Even things like scheduled and business events triggered outgoing
>>> messages, as well as incoming messages, could of course be dealt with
>>> outside of Mifos, and just use the platform REST API to fetch client data
>>> etc. - should it? Am I making any sense?? Shoot it down if this sounds
>>> like a stupid idea - I'm just thinking out loud.
>>>
>>> The emails from Sander/Musoni didn't make all that much sense to me
>>> personally if I may be honest... Their "business rule"-based thing
>>> sounds interesting.. but what exactly did they do there, how does that
>>> work? Gurpreet, you wouldn't have time / want to follow-up to dig a little
>>> more into that (functionally, less technically, initially), like ask to see
>>> some concrete examples etc. would you?
>>>
>>> Best,
>>> Michael
>>>
>>>
>>> _______________________
>>> Michael Vorburger
>>> http://www.vorburger.ch
>>>
>>>
>>> On Mon, Apr 29, 2013 at 2:13 PM, Keith Woodlock <[email protected]
>>> > wrote:
>>>
>>>> Guys,
>>>>
>>>> Just saw that this mail wasnt on the public developers list. I guess
>>>> once you collate what you want to do into a wiki page you can open up to
>>>> public list. so cc'ing Sander from Musoni on this also as Musoni have
>>>> operational expierence of what they need from SMS notifications and have
>>>> plugged in an SMS module into their software they use at Musoni Kenya.
>>>> Sander you mentioned before to me that you would be happy to tell us/show
>>>> us what it was you looked for SMS module.
>>>>
>>>> Comments to Gurpreet and Michals comments in line below:
>>>>
>>>>
>>>> 1. 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.
>>>>
>>>> [michael vorburger]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.htmlmay
>>>> 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.
>>>>
>>>> [keith woodlock] I guess we want from platform point of view to use
>>>> some SMS service. We would want to be agnostic of any given service for
>>>> sure, so the underlying implementation shouldnt really be exposed. For the
>>>> time being I am happy for people to just go the 'Factory' route in deciding
>>>> to use Nexmo or Twilo or whatever. Getting it work working would result in
>>>> a clean abstraction that the platform code would use at right time - We
>>>> could then later loooking to supporting the 'drop a jar' in approach of
>>>> adding in new implementations
>>>>
>>>> 2. SMS Gateway Plugins/Queue: Implementation for maybe 2 SMS providers
>>>> as plugins: Twilio and Nexmo.
>>>>
>>>> [michael vorburger] 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?
>>>>
>>>> [keith woodlock]: Yes we should get something working first of all. And
>>>> we should not attempt to implement any backend/UI support for
>>>> queuing/tracking/viewing or QoS info like SMS sent and if they were
>>>> delivered but instead rely on the service we are using to support that.
>>>> Hopefully they would do all of that and no expect applications to have to
>>>> re-invent this kind of functionality.
>>>>
>>>> So no comments on the individual use cases like being able to send SMS
>>>> straight to a client or loan office from screen or have automated SMS due
>>>> to some event which would most likely be needed - Prefer to hear how Musoni
>>>> use SMS in their operations first
>>>>
>>>> regards,
>>>> Keith.
>>>>
>>>>
>>>> On Sun, Apr 28, 2013 at 10:40 PM, Michael Vorburger
>>>> <[email protected]>wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Great write-up! I have some feedback:
>>>>>
>>>>> 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:
>>>>>
>>>>> - Q: How do we ensure each client has given us a phone number? -
>>>>> A: Don't; it will simply fail.
>>>>> - Q: If many people share a common phone number (in a group for
>>>>> instance), then maybe sending the "name" of the person in SMS is
>>>>> important.
>>>>> - 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.)
>>>>> - Q: Do we need some country specific validation in phone number
>>>>> entry for a client? - A: that will probably quickly get complicated;
>>>>> KISS,
>>>>> and forget it for now.
>>>>> - Q: Do we need some flag indicating that a user has not
>>>>> configured a valid phone number and hence we won't be able to send any
>>>>> sms
>>>>> notification. - A: Just grey out the "Send SMSthat will probably
>>>>> quickly
>>>>> get complicated" button/icon? With a tooltip "Cannot send SMS as no
>>>>> phone
>>>>> number."
>>>>>
>>>>> 5. Functional comment: We actually really need to start a Wiki page
>>>>> for refining very concrete functional scenarios for outbound SMS. 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?
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>>
>>>>> _______________________
>>>>> Michael Vorburger
>>>>> http://www.vorburger.ch
>>>>>
>>>>>
>>>>> On Sun, Apr 28, 2013 at 7:29 AM, Gurpreet Luthra <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> I wanted to summarize the *Outbound SMS *feature for GSOC, so that
>>>>>> this can be published maybe on a WIKI for students and others.
>>>>>>
>>>>>> ==============
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> What this might in-effect translate to, is the following:
>>>>>>
>>>>>> 1. *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.
>>>>>>
>>>>>> 2. *SMS Gateway Plugins: *Implementation for maybe 2 SMS providers
>>>>>> as plugins: Twilio and Nexmo.
>>>>>>
>>>>>> 3. *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).
>>>>>>
>>>>>> - Should this be implemented using a persistent JMS queue, or a
>>>>>> similar queue library?
>>>>>> - How does this look for multi-tenant systems. One common queue
>>>>>> or a queue-per-tenant? I guess a queue-per-tenant.
>>>>>>
>>>>>> 4. *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:
>>>>>>
>>>>>> - How do we ensure each client has given us a phone number?
>>>>>> - If many people share a common phone number (in a group for
>>>>>> instance), then maybe sending the "name" of the person in SMS is
>>>>>> important.
>>>>>> - Do we need some country specific validation in phone number
>>>>>> entry for a client?
>>>>>> - Do we need some flag indicating that a user has not configured
>>>>>> a valid phone number and hence we won't be able to send any sms
>>>>>> notification.
>>>>>>
>>>>>>
>>>>>> 5. *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:
>>>>>>
>>>>>> - Manual - triggered by someone from within MifosX. Like sending
>>>>>> an SMS to a client with some message.
>>>>>> - Event based - triggered by system whenever certain events
>>>>>> occur. Like a loan is approved or rejected, etc.
>>>>>> - Schedule based - triggered periodically, running as a batch
>>>>>> job.. maybe integrated with the Spring Scheduler framework. For
>>>>>> instance of
>>>>>> checking on disbursements to be done today, and send sms in morning
>>>>>> to all
>>>>>> loan officers.
>>>>>>
>>>>>> 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):
>>>>>>
>>>>>> - Inform a client when her loan is approved - "Your loan of
>>>>>> amount X has been approved".
>>>>>> - Inform a client when her loan is disbursed - "Your loan for
>>>>>> amount X has been disbursed on <date>".
>>>>>> - Inform a client when her next repayment is due (n days earlier)
>>>>>> - "For loan payment for Rs 300 is due in 3 days on the 21-April-2013".
>>>>>> - I need more suggestions on this.
>>>>>>
>>>>>> 6. *SMS Notification Configuration Screen:* Need to create a
>>>>>> configuration screen where all SMS based notification configurations can
>>>>>> be
>>>>>> done. This will contain the following:
>>>>>>
>>>>>> - SMS Gateway Plugin choice + Gateway Plugin
>>>>>> configurations/credentials
>>>>>> - Which system events should be enabled for auto-send (from list
>>>>>> 5 above)
>>>>>> - What would be the template message for each type of system
>>>>>> event (or maybe for now, we hardcode this in code, and expose
>>>>>> templates
>>>>>> later when the need arises) The problem around hardcoding the SMS
>>>>>> message
>>>>>> for system events is that we need to send messages in different
>>>>>> languages
>>>>>> to different roles. Like Loan Officer may want SMS in English, while
>>>>>> Clients may want it in Swahili, or Hindi, etc. So - it would just make
>>>>>> sense to give the ability to enter the SMS template message right now.
>>>>>> - Ability to see the SMS notification queue.
>>>>>>
>>>>>> What else? Did I miss something important? Any suggestions?
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Gurpreet
>>>>>>
>>>>>> Join the Humanitarian Software
>>>>>> Program<https://my.thoughtworks.com/groups/humanitarian-software-program>
>>>>>> to
>>>>>> help and contribute OpenMRS, RapidFTR, Camfed and MifosX SIP Projects. We
>>>>>> are looking for Volunteers!
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
>
> --
> *Ed Cable*
> Mifos Community Manager
> Director of Community Programs, The Community for Open Source Microfinance
> [email protected] | Skype: edcable | Mobile: 484.477.8649
>
> *Collectively Creating a World of 3 Billion Maries | *http://openmf.org
> <http://on.fb.me/cosm-openmf>
> * * <http://www.twitter.com/mifos>
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Mifos-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mifos-users
