How to Structure a FileMaker Server Script Schedule for Polling a Web Service

Frequently Recurring Schedule

FileMaker Server schedules are commonly used to run tasks that must run at a certain time, even if there are no users logged in. If the task needs to be run repeatedly — for example, polling a web service to check if there are updates you need to know about — you can set up a recurring schedule to run as frequently as once a minute.

A recurring schedule works well, except for the fact that frequently running schedules end up creating lots of log entries. Every time a recurring schedule runs, FileMaker Server logs three entries:

• script starting running
• script stopped running
• script scheduled to run again

On top of that, there are usually some false-positive errors (like 401 when a Perform Find script step doesn’t find any records) that get added to the log. As a result, these log entries end up crowding out other less-frequent entries. Log files roll over once they reach a designated file size limit. The net effect of this behavior is that the log files don’t reach as far back in time as they otherwise would. Troubleshooting unexpected behaviors frequently requires access to log data. Not having a lot of it available can hinder the troubleshooting effort.

Looping Script

Creating a single schedule that loops (and pauses in between loop iterations) is an alternate approach. While this removes the too-many-log-entries problem, it introduces a significant shortcoming. If FileMaker Server or the script engine (FMSE) process is restarted, an admin will need to start the schedule back up manually — or wait until the next scheduled start time for it to start automatically.

Another drawback of this approach is that it maintains a user session for an indefinite amount of time. There is no problem with this in theory. However, in practice, problems such as memory leaks do occasionally occur (albeit rarely). For this reason, in my opinion, it’s good to structure your code so that it doesn’t have to run endlessly.

Hybrid Approach

There is, however, another way, a hybrid approach that combines both methods. It relies on a behavioral quirk of FileMaker Server schedules. When a recurring schedule finishes, FileMaker Server schedules the next run without running the schedules that may have been skipped during the previous run.

For example, if we have a schedule that is configured to run every minute, and the 12:00 PM run of the schedule takes a little less than 5 minutes to run, then once the script finishes running (say at 12:04:40 PM), FileMaker Server will schedule the next run to be at 12:05 PM. It will not try to run the schedule for the missed time periods, i.e., 12:01, 12:02, etc.

To take advantage of this behavior, we can write a script that loops to perform the task that needs to be repeated but still exits after a pre-determined time, say after an hour. For example, within the loop, the script could perform the task, then pause for a minute. The script would then check to see if it’s time to exit out of the script, e.g., if an hour has passed by since the script started running. The script would look something like this:

Loop
     Do task
     Pause for 1 minute
     Exit loop if script has been running for longer than 1 hour
End Loop

This way, the log file will not get filled up with unhelpful messages that tell us the task has started, stopped, and been rescheduled. And if FileMaker Server or the FMSE process is restarted, the schedule will start up again within a minute.

Next Steps in Claris FileMaker

If you’d like more insights into how to make your FileMaker application more efficient, we can help. Contact us to learn more.