Evergreen

Bug #1667080
Comment #1

Comment 1 for bug 1667080

Revision history for this message

Josh Stompro (u-launchpad-stompro-org) wrote on 2018-01-22:

After seeing bug 1744358 I took another look at this and got something working. I stuck the code at https://gist.github.com/stompro/1cd3008785995517e0305fb280a0d8ef for now. As mentioned by Miker, this doesn't need to be included in evergreen to be used, the SendSMSFlowRoute.pm just need to be in the perl module path.

Sending an SMS messages works fine. But I have some questions about a few things.

1. Delivery Reports: There are a few options for dealing with delivery reports. Each message can specify a callback URL, that flowroute will post data to. So one option to get delivery reports is to set that for each message and then setup something to receive those reports.

It is also possible to query the flowroute API for delivery reports, but you need the message ID generated at send time to do that. It might be easier to just have a script that processes delivery reports in batch every once in a while instead of setting up the callbacks. But where should the message ID be stored? Can ate.user_data be used/abused for that? The AstCall reactor seems to store data in an asyc_output action_trigger.event_output, would that be the preferred option. That would avoid redundancy for grouped events.

If the async_output is used, can I just store the message id string there? Or do I need to store a copy of the template_output along with the message ID appended to the end. Should I store the json results that are returned?

2. The flow route API seems to make it possible to allow interactivity through SMS. You set a callback url for your account which they post new message data to. The hold pickup message could include "Reply with HELP for more options." And then "ITEMS - list of items ready, HOURS - pickup location hours and contact info, CANCEL - cancel these holds, WRONGLOCATION - change pickup location.

The data would need to be looked up based on the sending phone number. So that would probably need to be matched against the action_trigger.event_output data. So I might get wonky if there a multiple users using the same SMS number at the same time. It might be good to have a limit of a couple days for responses to be accepted, but I don't usually use SMS services so I don't know what users might think is acceptable. I would love some feedback from anyone who has thought about this.

Josh

After seeing bug 1744358 I took another look at this and got something working.  I stuck the code at https://gist.github.com/stompro/1cd3008785995517e0305fb280a0d8ef for now.  As mentioned by Miker, this doesn't need to be included in evergreen to be used, the SendSMSFlowRoute.pm just need to be in the perl module path.

Sending an SMS messages works fine.  But I have some questions about a few things.

1. Delivery Reports:  There are a few options for dealing with delivery reports.  Each message can specify a callback URL, that flowroute will post data to.  So one option to get delivery reports is to set that for each message and then setup something to receive those reports.

It is also possible to query the flowroute API for delivery reports, but you need the message ID generated at send time to do that.  It might be easier to just have a script that processes delivery reports in batch every once in a while instead of setting up the callbacks.  But where should the message ID be stored?  Can ate.user_data be used/abused for that?  The AstCall reactor seems to store data in an asyc_output action_trigger.event_output, would that be the preferred option.  That would avoid redundancy for grouped events.

If the async_output is used, can I just store the message id string there?  Or do I need to store a copy of the template_output along with the message ID appended to the end.  Should I store the json results that are returned?

2. The flow route API seems to make it possible to allow interactivity through SMS.  You set a callback url for your account which they post new message data to.  The hold pickup message could include "Reply with HELP for more options."  And then "ITEMS - list of items ready, HOURS - pickup location hours and contact info, CANCEL - cancel these holds, WRONGLOCATION - change pickup location.

The data would need to be looked up based on the sending phone number.  So that would probably need to be matched against the action_trigger.event_output data.  So I might get wonky if there a multiple users using the same SMS number at the same time.  It might be good to have a limit of a couple days for responses to be accepted, but I don't usually use SMS services so I don't know what users might think is acceptable.  I would love some feedback from anyone who has thought about this.

Josh