Hold SMS - New Reactor - flowroute

Bug #1667080 reported by Josh Stompro
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Evergreen
New
Undecided
Unassigned

Bug Description

Hello, I would like to setup a new provider for sending SMS messages from Action Triggers. I would just like some guidance as to the best way to set it up.

My initial thoughts are to create a new A/T Reactor SendSMSFlowroute, to handle submitting the message to flowroute's api endpoint. And then adding a couple of org unit settings to hold the authentication settings. I think that would cover multiple organizations using the same event def that each have their own flowroute accounts.

Josh

summary: - Hold SMS - New Provider - flowroute
+ Hold SMS - New Reactor - flowroute
Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

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

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

Something we will also need is a way to hide all the UI options for sms_provider after we start using this. So probably another org unit setting, sms.hideprovider.

And then change the logic wherever sms.enabled is used.
http://git.evergreen-ils.org/?p=Evergreen.git&a=search&h=HEAD&st=grep&s=sms.enable

Josh

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

I updated my gist with a version that stores the message id in an async_output event_output.

Josh

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

We started using this today to send out hold pickup sms messages. So far so good. I haven't started processing the delivery reports yet, to look for clear failures that action can be taken on. There are like 50 different status codes to evaluate, and I'm not sure how long it takes for some of the errors to get reported back to flowroute. https://support.flowroute.com/Messaging/Common_Issues/Delivery_Receipt_Response_Codes

Josh

tags: added: actiontrigger
Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

I switched the text a call number feature over to flowroute sms yesterday, and it has some issues due to how the feature is designed, which I'm trying to figure out how to get around.

When the text an item is first loaded, it triggers the event before the phone number is specified, and then shows the output. The output for the flowroute sms is a json string, which doesn't seem all that friendly to show to the customer.

It also causes the reactor to try and send an invalid text message, one without a phone number to send to.

I think I'm going to go on the assumption that the user doesn't need to see what the text message is going to look like, both in the preview and once it is sent. And add some logic to not create an event if the phone number wasn't submitted to prevent extra events from being created.

Josh

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

Here are the flowroute related commits for this feature to add it to 3_11

https://gitlab.com/LARL/evergreen-larl/-/commits/rel_3_11_0-larl?search=flowroute

I think there are some other bits somewhere having to do with hiding the sms_carrier, but also always including a default value for it since it is required to be non null to place a hold.

Josh

Revision history for this message
Josh Stompro (u-launchpad-stompro-org) wrote :

A couple things,

1. There is a newer version of the Flowroute API that this code should be updated for.

2. There is a bug with how the event output id is grabbed when events are not grouped. When used with the Test SMS notice for example, that is a single event fired that doesn't go through the grouping logic. So the code that tries to grab the event output id fails, and the event gets marked as erroring out even though the message gets sent.

3. The Error checking needs to directly set the state to error when a fatal error is detected. Returning 0 doesn't take care of that. It should also create an error_output with error details in it.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.