RouteSavvy User Guide – 1.7 – Technical Architecture
RouteSavvy is hosted on Microsoft Azure instances secured on the Azure cloud platform. RouteSavvy scales as required with new Azure Standard_A1 instances located in multiple datacenters.
“Security is built into Azure from the ground up, starting with the Secure Development Lifecycle, a mandatory development process that embeds security requirements into every phase of the development process. We help ensure that the Azure infrastructure is resilient to attack by mandating that our operational activities follow the rigorous security guidelines laid out in the Operational Security Assurance (OSA) process.”
Total Uptime Cloud Load Balancer provides multi-instance load routing. This includes automatic failover and disaster recovery for multiple instances hosted in disparate physical locations and cloud platforms.
RouteSavvy uses a custom token based authentication mode which tracks active users for license compliance. Authentication lookup is handled using a private SQL Azure instance as the token store and active user tracking. Since all authentication is handled server side, firewall access to the SQL Azure is limited to OnTerra RouteSavvy instances.
RouteSavvy is a browser based service two primary data resources, Locations/Stops and Projects.
The client data model and AJAX data transfers use standard JSON format. Data is transferred to the RouteSavvy controller where all communication with external data services is handled. RouteSavvy uses Bing Geocode REST service for geocoding and reverse geocoding addresses and latitude, longitude pairs. Bing Route service is used for map routing. A proprietary OnTerra optimize service handles stop order optimization.
Location/Stop CSV addresses are uploaded from the client system to the current RouteSavvy HttpApplication session using multipart mime transfer. HttpApplication session data is transient and disappears at session end. From the RouteSavvy HttpApplication session, calls are made to Bing REST services for Geocoding/Reverse Geocoding and Routing.
Locations are geocoded on upload using Bing REST Geocode service. After the user designates which Locations to use as Stops, the Route Planner Optimize button instructs RouteSavvy to run an optimize ordering that involves multiple Bing Route service requests.
Because Location/Stop data is transient it is helpful to have a more permanent store for a RouteSavvy session data and state. RouteSavvy uses html local storage to preserve this data in a local json text format on the user computer. Users may opt to reuse a locally saved session state, project.json, or start over with a new session. It is the user’s option to save RouteSavvy data and state for later use.
RouteSavvy includes a Mobile option for sharing the results of a route optimization. Directions are added to a static web page stored in Azure blob storage with a unique ssl link. The directions include stop addresses with turn by turn instructions and notes. Additional Google, Bing, and Waze links allow users to tap each stop for location on a mobile user’s map app. Once this static mobile page is saved to blob its link can be shared with users for navigation using their mobile device in vehicle.
Shapes and Territories
RouteSavvy Shape objects, which are useful for spatially organizing locations and stops, may be drawn and edited using RouteSavvy draw tools. RouteSavvy also includes a territory building option for defining territories based on USA zipcodes, counties, and states, or international countries. Territories may be built manually by selecting polygons from the map or by importing a list of polygons in a csv file. Territories may be defined as complex polygons with holes and islands. Once a territory is defined, it is saved as a shape object in a RouteSavvy project.