Keeping a website in sync with a FileMaker solution using AMQP.

It is several methods for keeping web-sites in sync with FileMaker server hosted solutions. Having the website pull updated records from the database using either the PHP API or the REST API. This is often a batch update technique where all updated record is queried for a modification timestamp. Updates to products in an online webshop, as an example. However, for those users who update product descriptions and prices want to see their changes immediately - waiting 1-2 minutes for the update process to complete might be too long.

To be able to have an instant update, the FileMaker solution needs to notify the update process about the changes, such as the website can implement the update immediately. This can be done with an "Insert from URL" script step, as an example.

However, this introduces a certain delay in the save record having the app wait for the insert - might be a second or more waiting for the process to complete.

A faster way is to send notifications to a message broker using the AMQP protocol. Then a worker process on the website pics up the messages and implements the update directly, using PHP API or REST API. The good thing about this method is that the broker queues the messages if the workers are busy. In that way, we can prevent too many update processes going on at the same time. They will handle the queue when finished with the current task.

The ACF plugin contains functions to both send and receives messages using the AMQP protocol.

Installations that use this technique are set up with the following set-up:

• The ACF plugin to handle AMQP messages.
• RabbitMQ message broker installed on the web-server or another server. (Open Source Software)
• Celery on the WEB-server set up as worker processes, using Phyton scripts. They activate PHP scripts to pull the record using the PHP API and implement the changes in a local MySQL base that the website uses. (Also Open Source Software).

We tested sending 100 messages to the Message Broker from a FileMaker script. The loop completed in 1,5 seconds. i.e. 15ms for each message. This means, including this into trigger scripts does not slow the performance of your solution in any noticeable way.

In the development of this solution, we implemented the sending step just before "Commit Record" in a trigger script. We had to move it next to the commit record script step because the worker pulled the data too early – before the commit was complete. It was almost too good to be true, but we checked back and forth several times.

The users can then refresh the web-page to see the changes they have done immediately.