Building automated phone systems is easier than ever with services such as Twilio. Twilio has built a communications platform transforming actions such as sending and receiving calls/SMS messages, which traditionally needed investment in significant hardware, into simple API calls. One use-case for Twilio is making automated calls to groups of people based on a set of business rules being true. That is what we will focus on in this post. However, what we really want to do is make intelligent automated calls – that is where location comes in – often notifications are only applicable if the user is in a certain location.
Calls and messages without code
The first thing I have done is created a series of Twilio FME custom transformers that allow you to easily interact with Twilio in FME Desktop, our graphical modelling tool.
- TwilioMakeCalls: Make automated calls. The content of the call can be set at runtime.
- TwilioSendSMS: Send SMS messages. The message content including text and images can be set at runtime.
Automated Phone Alert Scenario
The scenario we will look at is related to flooding. Let’s say we want to monitor real-time flood data based on the level of the river, dynamically generate flood plain maps, then select everyone that lies within the floodplain and send them an automated message if there is a problem. Of course we want to do this without writing any server-side code.
Workflow to automate sending SMS messages and phone calls.
Incoming data sources
- Flood data: The USGS provides real-time gage height and discharge for the whole of the USA now. We read in the data for the Gilmer County catchment.
- Floodplain map: Point cloud data for the drainage basin including z values.
- Users: A database of users who have subscribed to receive alerts. You will need to build a subscribe workflow to allow users to signup for the service, details on how to do that here.
Workflow
Step 1: Process Incoming Data
We read the USGS feed every 1 minute using the schedule functionality on our enterprise product, FME Server.
Step 2: Dynamically select subscribers
Using the point cloud data, we can create polygons representing the different flood risk zones. I created two zones: people at immediate risk and people who need to be warned. The polygons are dynamically created based on flood height. For example, if the gauge is currently at 10ft – which is above the flood trigger level – we create the following polygons:
Immediate Risk: Containing the land mass below gauge height and up to 5 feet above gauge height.
Warning risk: Containing the land mass between 5 feet to 15 feet above gauge height.
These are the transformers we used to achieve this complex workflow, all 12 of them!
Step 3: Notify Users
Now that we have selected our subscribers that are at risk of flooding, we need to send them a notification to warn them. We do this using the Twilio web service. There are two custom transformers in the FME Store, TwilioMakeCall and TwilioSendSMS. Using the telephone number from the database, we send the immediate-risk people an automated call and the moderate-risk people an SMS.
Step 4: Publish to FME Server to automate
We need to run this workspace every minute to check the latest data coming from USGS. To do this we publish the workspace up to FME Server and schedule it to run every minute. The failover and fault tolerance capabilities of FME Server ensure that the workspace will always run.
Example automated SMS message we sent.
So there it is, a workflow reading in data in near real-time processing and evaluating it and then sending notifications out via Twilio without writing any server-side code. This is a classic example where leveraging the spatial features of FME really allows you to boost the intelligence of the workflows you build. The workspace and more details can be found on our support site. You can also find out more about working with real-time data, including a walk-through of this example in our recent webinar
Stewart Harper
Stewart is the Technical Director of Cloud Applications and Infrastructure at Safe. When he isn’t building location-based tools for the web, he’s probably skiing or mountain biking.
