We’re back with FLO of the Week and focusing on something a little more complicated than our past FOTWs. This particular FLO was actually used in an application created by a team of three Azuqua employees for TechCrunch’s Disrupt London hackathon and is a bit more developer-focused than our usual FOTWs.

Wandered.space is the web app that we made for Disrupt London using Azuqua. It is a web-based service which uses your location to suggest points of interest around you to visit. It’s designed to help users explore the areas around them and find interesting locations they never would have otherwise.

Get Started With Your Azuqua FREE TRIAL

Orchestrate microservices, automate workflows, and synchronize data right away!


Clearly, this means that one of the main functions of this web app is the ability to provide users with directions and walking times for the different suggestions so they can decide whether or not they actually want to make the journey. Today, we’re going to look at the FLO that provides that information for wandered.space. It uses the ArcGIS API to find the walking time and directions between the user’s current location and the location they are trying to get to.

WS Step 1

Step 1

On Demand – From Another FLO

This FLO only runs when called by another FLO, so here we make sure that we set it to be an on demand flow. The client-side application passes the start_latitude, start_longitude, end_latitude, and end_longitude.

WS Step 2

Step 2

String – Compose

This card creates a string that is composed of the start longitude and latitude, and the endpoint longitude and latitude. Latitude and longitude are delimited by commas. The pairs of latitude and longitude are delimited by semicolons.

All of this info is pulled from the client-side application.

WS Step 3

Step 3

JSON – Stringify

In this step, we establish a special object that ArcGIS Routing Services uses to determine the “travel mode.” In this case, the travel mode was walking. There is more text in the “object” section than is shown in this image.

WS Step 4

Step 4

Object – Construct

This card uses the outputs from steps 2 and 3.

We construct a new object that contains the keys token, travelMode, stops, and f. This is going to be used as a parameter for the ArcGIS Routing Services API.

WS Step 5

Step 5

HTTP – Raw Request

We send a GET request to the ArcGIS Routing Services API, passing in the object we just constructed as a query parameter in step 4.

WS Step 6

Step 6

JSON – Parse

We use a JSON action for this step and parse the body of the object that is returned from the card in step 5.

WS Step 7

Step 7

Object – Pick

The object we just parsed in step 6 contains a routes object and a directions object. From those two objects, we pick out the field Total_WalkTime and a list of objects containing the pertinent directions to get from the starting point to the ending point.

WS Step 8

Step 8

List – Shift

We shift the first item off the list because the first direction is irrelevant. The first step that is returned is always “start at start location”, which is unnecessary. This is an optional step, it just depends on whether or not you want that first step in the list to be part of your returned info.

WS Step 9

Step 9

Control – Return

Return the walkTime from step 7 and the directions from step 8, which are both consumed client-side by the web app.

This FLO demonstrates some of the more powerful applications that Azuqua can be used to create. Azuqua is more than just an integration platform. Developers can be innovative and creative while still integrating with all the different applications they need to easily and quickly.

Read more about what to look for in an integration platform with one of our resources by clicking here. »