Technical Brief

FileMaker Go 1.2.1 Technical Brief
26
Server Side Queuing
Rather than having FileMaker Go handle your entire scripting load, consider moving some scripts to your
FileMaker Server or a FileMaker Pro client machine dedicated to supporting your solution. Queuing is a common
technique used by FileMaker developers. It is sometimes referred to by different names; asynchronous processing,
(ro)bot processing, and server side processing all refer to this concept. Namely, a user does something that puts
a request into a queue, which then gets processed by a daemon or scheduled process running at some regular
interval on the host or robot/client machine.
This technique is frequently used for tasks that may take a lot of processing time, and therefore would block
the user from doing other things if performed on the client. This technique has new relevance in mobile apps.
Mobile devices have less processing power and more intermittent connections, so task queuing might be worth
considering in more situations than it normally would have been in solutions designed only for FileMaker Pro on a
local area network.
Queuingworksparticularlywellwhenyoucanhavetimely“push”notication,andtheOnTimer trigger makes a
great compliment to this technique. Note that OnTimer script triggers will only work when FileMaker Go is actively
running.
Here’showthetechniqueworks:
1. User initiates your script by tapping a button or running a script from the scripts menu.
2. RatherthanprocessthescriptthereontheFileMakerGoclient,yourscriptcreatesarecordina“queue
table”withthenameofthescriptintendedtorun,theuserwhorequestedit,andanypertinentscript
parameters or required data.
3. EitheraFileMakerProclientorFileMakerServerrunningitsown“watcher”scriptonatimernoticesthat
there is a new script request in the queue table. Based on the name of the script and the parameters
provided it runs the batch process.
4. As a nice way to notify the user that their script is done, an OnTimer triggered script on FileMaker Go could
watch the queue table and note when a record is listed as being complete. It could then show a dialog to
the user informing them of this.
This is by no means the only way to work, and glosses over some challenges with context and found sets, but it is
an approach worth considering.
Script Logging / Flagging
Another approach to ensuring that data is not left in an incomplete state by an unfinished script is to simply test
for a result condition. This idea could be implemented in a number of ways, but the essential idea is to flag each
record modified by a script with a timestamp or some similar element and then to, perhaps via an OnTimer script,
periodically look for records missing that timestamp. Your database could then ask the user if they wish to run the
script again in order to conclude its process.
Common sense should dictate your approach to these issues. If you write a script that, for example, generates a
report for the user, no one will care if a connection drops and the report is not presented. Your data will be fine
and the user, once she reconnects, will have an opportunity to run the report again.
The intent here is to be mindful of the issues around halted scripts and plan accordingly.