Introducing EasySync: A Decidedly Different Approach to Syncing FileMaker Databases
I have been chatting with a couple of other developers over the past few days about a new FileMaker sync technique that I am working on. I am calling the technique "EasySync," and here is a little about it...
My goals with EasySync are to:
• Use only native FileMaker functionality. No plug-ins, and preferably no custom functions.
• Make it as simple as possible to setup and configure.
• It should have a small footprint. The number of additional fields, tables, TOs, and relationships should be minimal.
• Avoid the need for any additional files. There should be no "connector" files, whether on the server or mobile device.
• Make it transactional. A sync process should complete in its entirety or not at all.
• Make it as fast as possible.
• Support containers.
• Make it flexible, so that it can be easily modified to support various business rules.
• Make it open source. (Yeah, as in free.)
At this point, all of those goals have been achieved. The current model supports pushing data that has been collected remotely up to a hosted file. It adds new records, and updates existing records. It supports syncing of multiple tables, and it is very easy to indicate what tables should be synced. And, thanks to the new Base64-encoding/decoding support in FileMaker 13, it fully supports the syncing of containers.
And it's fast, too. In a relatively simple test with 500 contact records, the sync process takes around 20 seconds - and that's over a 4G connection.
What makes EasySync different from other sync solutions?
EasySync relies heavily on ExecuteSQL, which is used to get info about what needs to be synced (the tables and fields to push, and the data itself). It also uses FileMaker 13's new Base64 encoding and decoding functions to handle containers. It creates what I refer to as a "payload" - an encoded package that contains all of the sync data. That package gets pushed to the server.
The client then sends a request to the server asking that the payload be processed - and it does this using Perform Script on Server to speed things along. The server-side script unpacks the payload, confirms that it is well-formed, and if so, it processes it in a transactional way. The entire sync request either succeeds or fails. So, if the remote connection dies during the sync, no harm is done - and the sync can be reinitiated later without any problem.
• Add support for bi-directional syncing - pushing data up, and pulling data down.
• Beta testing.
• Documentation, sample files, and all that jazz.
There is no timeframe for releasing EasySync just yet. Client work has been piling up while I've been experimenting with this.
I'm looking for a few developers that are interesting in kicking the tires and helping me work on EasySync. Interested? Drop me a line.