Search
Close this search box.

Austin Convention Center Ditches Laptops and FTP for iPads and Cloud Application Storage

In this interview series with Austin Convention Center Database Administrator Jeff Moore, we are uncovering decision criteria for Apple iPad adoption and Mobile-first application development.

Austin Convention Center Logo
Part 3 of this interview covers Mr. Moore’s views on using Apple iPad
with Virtual Private Networks (VPN), further information on security and multi-tenant cloud
storage, exhibitor services workflow and why FTP is not the right
solution for application file, synch and share.

Joshua: It sounds like you are performing a one way synchronization to an external FileMaker Database, which could also be cloud application storage, is that the case?

Jeff: It is. When we set out to make this work, we realized that our external wireless network has firewall between it and the rest of the internet. Someone can’t sit at a coffee shop across the street and access resources that are on our wireless network. Beyond our network, there is a huge firewall between us and the City of Austin network.  The City is not going to allow anyone access through their firewall.

We could have supported VPN connections, but when you’re connected via VPN on an iOS device and your device goes to sleep, you get disconnected. Therefore, it’s not an optimal solution for employees to use VPN connections on their devices.

We put a separate server beyond our firewall on the external network. And then we made sure that any connections between internal FileMaker and external FileMaker were always instantiated by the internal FileMaker service. So, for example, I can see the database from within the City’s network. I can see the hosted database that’s out there on the external FileMaker server.  Further, I can then create table references to the tables that exist on the external network within my application on the internal network. And then I can write scripts that creates, updates, modifies and deletes information in those tables.

Generally speaking it is one-way, but there is some data that can be updated from the external FileMaker database. Basically, an application that’s inside has access to internal tables and external tables. The application runs updates between internal and external.

So, for example, let’s say if we lost all of the information on the external FileMaker database, the first thing the application does is move data from internal tables to the external tables. But, it can retrieve updates for specific columns in tables on the external tables, e.g. installed by, install status, notes, etc. By default the application sets a new record with pending values. When a technician changes it on their device, that update needs be updated on the internal database.

Any time a technician taps on something and updates it to “installed”, it’s recording who installed it, what date, what time, etc. We have some basic rules, such as:

  • If it already exists, then certain columns get updated
  • If it’s new, it gets pushed
  • If it’s existing, it gets updated

As I was mentioning, it’s very near like a one way push, but we do have some things that are updated from the external systems to the internal systems, but it’s mostly metadata about a project.

Alternately, the web form for those orders, as I mentioned before an exhibitor can access austinconventioncenter.com, exhibit services and then fill out the form. And at the end of it you process a payment that uses another system, a transaction bus.  We are not storing any credit card information. But an exhibitor enters credit card information and it is immediately pushed through a gateway. So there’s no sensitive information, e.g. whole credit card number, being stored on Center equipment. Exhibitors receive an email saying their payment was processed and their order has been stored.

Those orders are batch updated daily, typically around 3 a.m. the next morning. So, the infrastructure accumulates orders all day, and then at 3 a.m. they are pushed to our internal system

They become invoices and work orders in our utility services application. Invoices and orders contain payment information, but we only store the last four digits of the credit card number and expiration.  Overall, we have a rather extensive system internally, but the stuff that’s on the external network is very scaled down. It’s only specific to the task at hand.

Joshua:    I really like the model that you’re talking about, can you comment on what you were doing before iPads and Cloud Applications?

Jeff:   In the past when we were working on predecessors to this application, we had tried various means of moving the data between internal and external. And one of the things that we used with FileMaker was a plugin that supported FTP. We were able to dump the data that needed to go, and then FTP it out to our FTP server. And then the other one would pick it up from there. So we would kind of use in a similar sort of Box situation where we’re using an FTP server.

Joshua: Did File Transfer Protocol (FTP) prove successful, is the model you’re using now working better?

Jeff: Well the model that we’re using now works much better, because we have a dedicated virtual machine that is moving data, daily. Every day at 7 a.m. the virtual machine has a scheduled task that launches a FileMaker app. The application runs every five minutes. Between 7 a.m. to 7 p.m. And so that’s what does this.

ACC Solar AtriumThere is a live connection between the internal and external systems. When the application launches it makes instant connection to those tables. It is one application and two databases, so there are fewer pieces to the transfer by having this one application link everything and then do what it needs to do and then exit. If it can’t link, then it just exits and it tries again in five minutes.

So it’s a sort of thing where I try to make things happen with a few moving parts as possible. The FTP worked, but there were too many opportunities for failure there. We didn’t chose it and we never got to consider the impact of using laptops. With FileMaker Go and iPad, it is just an optimal solution for us.

In this blog, Mr. Moore clearly articulated why VPNs were not optimal
and the infrastructure he used to get data from his internal system to
the external system – one-way synchronization with metadata updates. In
the next blog entry with Mr. Moore, he’ll explain his views on using
other application storage besides FileMaker, iterating product
development for cloud applications and the impact of cloud applications
on desktop users, tool belts with tablets and LEED certification.

Part 1 – Austin Convention Center chooses iPads over Android and Considers Cloud Storage for File Synch and Share

Part 2 – Austin Convention Center considers New iPad for Camera to Support Facility Incident Application

Part 4 – Austin Convention Center Embraces Cloud Application Storage

Part 5 – Austin Convention Center Adds Tablets to Tool Belts on the Exhibit Floor

Share
Share

Click Here to Signup for the DCIG Newsletter!

Categories

DCIG Newsletter Signup

Thank you for your interest in DCIG research and analysis.

Please sign up for the free DCIG Newsletter to have new analysis delivered to your inbox each week.