Cloud-based SaaS software is awesome. No doubt about it. You’d be hard-pressed to find an industry that has not been impacted by it. And as the internet becomes more and more ubiquitous, it’s disruptive effect continues to expand.
No internet connection? Oh sh%#!
There is, however, one catch: you have to have access to a reliable internet connection for it to work properly. And therein lies the problem with some use cases: the lack of internet connectivity—or at least semi-reliable internet connectivity—for construction projects that cannot afford downtime simply because there’s a poor signal or no signal at the point of data collection on the project site. When downtime of a single day means tens or hundreds of thousands of dollars of added cost, waiting for a spinning wheel to stop spinning and load the form is simply not acceptable.
This is where applications that run locally on a device come into use. Applications built in this manner just work, regardless of a cell or wi-fi signal’s strength. You don’t have to watch a spinning wheel refresh or a form to load. And you don’t have to worry about a network connection to get your work done and recorded properly. The app just works, without any latency or load issues, which translates into less field tech downtime just waiting for a form to load from the cloud.
Offline Sync Methods
When it comes to sync, there are two basic ways to handle it:
- By storing a record in a local cached file, pushing this file to the server whenever an internet connection is detected, and then parsing the information in the file and inserting it into the appropriate database fields on the server database
- By storing a record in local database tables on the device and then synchronizing the local database with the server database when an internet connection is detected
Both sync methods work, but there are differences that matter in certain use cases. Method 1 above, where sync occurs by simply storing a record in a cached XML file or similar, is a more rudimentary and crude way of handling sync. When connectivity is detected, the cached file is uploaded to the server, and the data stored in the file is parsed/extracted out and inserted into the server-side database into the appropriate database fields. This type of sync is usually in one direction, where record exchange is performed from local to server only. In most cases, there is no return trip back to local. Obviously this has its limitations, but works fine for many types of uses, particularly where a field tech only needs to enter data and push it to the server and that’s it.
Method 2 above, where sync occurs by storing data in a local database, and then syncing the local database with the server database, is a more elegant and robust solution. This method provides the most flexibility and customization, and can do this in a bi-directional way. What this means is that—unlike method 1 where data is stored in a local XML flat file—data is stored in a local copy of the database. This local database copy is virtually a clone of the server database schema, and when connectivity is detected, synchronization is performed between the two databases in accordance with permissions settings for the particular user. In this type of sync, you can control permissions at a highly granular level, meaning you can set read/write/modify/delete permissions for each user/user group down to the individual column level for each application’s table. You can also control the sync type (from server to client only, from client to server only, or bi-directionally) and conflict resolution mode (server record overrides the local record, local record overrides the server record, keep both records, or ask the user). Try that with a flat XML file…it’s just not possible.
We use the best sync engine
There’s a database development platform called Adesso that handles sync in a generic way right out of the box via method 2 described above for any application built using that platform. Adesso was built from the ground up with offline sync in mind, and this is why it’s a good choice for use cases like construction commissioning. Built-in features include:
- Rich and highly granular (down to the individual column in a table) user permissions at the user level and user group level
- Full bi-directional sync with SQL query filtering options in both directions
- Full audit trail capability
- Build-in application designer
- Plug-in architecture for adding other components and software
- Enterprise-friendly features such as Active Directory/LDAP and Microsoft SQL Server support
- Built-in admin panel right out of the box
Here’s a couple of screenshots of the SyncAdmin synchronization options:
We at Terraine use this tool to build applications where offline sync matters, and then build other components of the commissioning system on top of this platform. For example, for Duke Energy, American Electric Power, and others, we will typically create the database schema and field data collection forms in Adesso, and then build a web dashboard in .NET or Java which will then communicate with the Adesso database via AdessoSQL APIs. Permissions controls are then handled in real-time via Adesso’s SyncAdmin portal, so user credentials can be changed as needed either directly in SyncAdmin or via Active Directory. Reporting is then built to the client’s specifications, typically done as PDF and/or Excel format downloads, with or without email automation for report delivery. On-premise solutions are available as well as hosted solutions.
Want to take a closer look at an example commissioning system we built? Click the button below.
Introducing XForms, a brand new software platform designed for Cx
- Runs natively on any hardware (iOS, Android, Windows, and web)
- Easily create checklists using an Excel-like table grid control (even works on tiny smartphones)
- Draw on top of pictures
- Collects metadata automatically including geolocation
- Automatically calculates % complete at the form level
- Collapsible section headers to quickly remove N/A items
Automatically calculates partial % complete
- While most software treat devices as either 0% complete or 100% complete, XForms can automatically give credit for partial completions.
- By doing so, your project completion calculations will be more accurate and not suffer from inherently lower % complete than actuals
- This is automatic, meaning no extra work to set up your project
Simple to understand reporting and admin dashboard
- Graphs and curves to track progress by any aggregation grouping (by system ID, area/location, device type, etc)
- View and print device checklists and completions data forms
- Easily manage device lists, system ID lists, and other reference lists
- Control who sees what from a user permissions perspective
- Click a button to produce a turnover package per system ID