Project Notes for the AMQP development

ACF plugin changes for AMQP update.

AMQP - Or Advanced Message Queuing Protocol is now implemented in PHASE # 3 in the ACF plugin.

PHASE 1 Done - Create "empty" plugin features in the Plugin framework. Create the dsPD_AMQP_Initialize function that will only collect parameters for other plugins calling. This is the host, user, password, port.

PHASE 2 Done - Implement C ++ libraries for AMQP in the plugin, and create a function to send AMQP messages to celery for processing. This is the function dsPD_AMQP_Send

PHASE 3 Done - Implement dsPD_AMQP_Listen that receives AMQP messages, and either returns the message as a plug-in result or starts a script when the message is received. This should be able to run "One-Off" to retrieve, possibly wait for a message - or it can run as a background process by "idle" - and perform a FileMaker script with a message as the script parameter. The dsPD_Close function will stop the background process and disconnect the connection.

PHASE 4 Done - Release the Mac plugin version with AMQP functionality, and Windows without it until PHASE 5 is complete.

PHASE 5 - Windows 32 and 64 bit (not complete yet). This consists of the following sub-items:

The reason PHASE 5 is delayed, is some of the 3th party libraries that does not compile well on windows. We are working on this to complete also the AMQP for windows users soon.

The plugin version is now: 1.6.1.0 as the latest version. Versions before 0.3.5 do not have AMQP. This includes PHASE 4. All functions in the plugin except AMQP for Windows is now available for both Mac and Windows 32 and 64bit.

Advantages of adding this to the plugin

There is no built-in functionality to send events to Web systems or other sync centres directly. It's used a URL plugin, to get a Sync Center URL, but this adds a slowness to the system that is not OK. If you need to inform the sync centre that a record has changed, it is untenable that it takes 0.5 - 2 sec and transmit this info with a URL plugin (Mainly waiting for the website to respond). Doing this routinely makes the FileMaker app becomes "soup-slow" to work with.

The following test was performed with these functions in place that will only send a message to the broker: (Message Reception where messages are processed and distributed to a Worker performing the task) - Test with 100 messages in a loop: Time 1.5 seconds. That is, we are talking about 15 ms, instead of 500-2000. The result is precisely the same.

What is the purpose of this method?

We are talking about keeping the sync centre and the FileMaker application in live sync as possible in PT. Previously, there were 1-2 minutes of delay here, and it might be a problem where people are meeting and updating their plans. The fact that others can see changes quickly is an advantage.

For a website, we have some extra benefits. Updating the online stores or web-pages - when users make changes to records in FileMaker - then they want to see the changes as soon as possible. Using an "update now" button, that runs the entire sync centre loop - i.e. it takes maybe 30-50 seconds to see the result on the web. After implementing this technique, they can hit refresh on the web page and see the changes right away.

Other references: See other articles on Celery and RabbitMQ.