System Level Scripts and FileMaker
Many FileMaker developers would agree that system level scripts enable us to extend the power of Filemaker, by giving us the opportunity to interact with the operating system, and perform actions that are beyond the scope of FileMaker. In a previous blog post titled “AppleScript and Filemaker”, my colleague Jason Nardozza discusses his experiences with AppleScripts and Filemaker, lists some of the challenges he faced with merging the two technologies, and explains how he addressed some issues as they came about. In this post, I will be taking a similar approach of(1) discussing my experiences with implementing our Calendar Sharing feature in Kosmas with system level scripts and FileMaker Server.
One of my favorite features in our primary product, Kosmas, is the ability to make a Kosmas Calendar available for subscription through Google or Apple Calendar. This feature allows both Kosmas and non-Kosmas users to view events, schedules, and resources that have been created in Kosmas on their personal devices by subscribing to a shared Calendar. We are able to achieve this by using FileMaker scripts to generate ics files, exporting the ics files to our servers, transferring the exported ics file to the web root of our web server with system level scripts, and displaying a shareable url link to the user. In the following paragraphs, I will be discussing how I was able to achieve this with FileMaker and system level scripts.
Using the FileMaker Admin Console
FileMaker Server allows us to schedule and run system level script sequences in the form of FileMaker Scripts, Windows Batch commands, VBScripts, OSX Shell (Bash, Perl or Python) from the Admin Console. As a result, my initial instinct was to set up a script sequence that would trigger a PSOS script to export the ics files to our database server and fire an AppleScript to transfer the exported files to our web server after the files had been exported. This seemed pretty straightforward. However, I was unable to successfully get our system level scripts to perform tasks on remote machines through a scheduled script sequence. As a result, I left the admin console to deal with scheduling and running FileMaker scripts and let the operating systems handle the system level scripts.
In spite of this, I encourage FileMaker developers to use the FileMaker Admin Console to schedule system and to level scripts because the wizard makes them easy to set up and it works in a lot of cases. However, there are some instances in which using the FileMaker Admin Console is not ideal because of the limitations.
AppleScript Handlers, Folder Actions, and the Window Task Scheduler
Handlers come into play when we are unable to get a FileMaker Server scheduled system level to perform a task we want it to. One of the powerful features of the AppleScript Editor is the ability to use handlers to trigger events. This becomes very handy when dealing with repetitive tasks and can be very handy in areas that the admin console is limited. An example of this is trying to perform a task that the fmserver account or Windows Local account cannot perform. The common handlers are the run open, idle and quit handlers.. In most cases saving an AppleScript as an application and running it with a handler would work. While this is not the best of solutions, it could be useful depending on the task you need to perform.
For Windows users, the Windows Task Scheduler could be said to be the relative of handlers in AppleScript. It allows users to run and schedule Windows batch scripts and even trigger them with events. I personally have not had a chance to trigger batch scripts with events using the task scheduler but it might be worthwhile to look into this if you use a Windows machine. OSX machines make it simple with its folder actions which allow us to associate an Applescript with an action in a folder.
Don’t Forget File/Folder Permissions & Sharing
Depending on what kind of actions your scripts perform, some file and folder permissions may have to be modified. When working permissions it is important to note what permissions are required for the the actions in your system level scripts. You might also want to pay attention to the security implications of changing permissions in your folder. The rule of thumb is to only give the permissions that the script needs.