FileMaker Server-Side Script Sequences

FileMaker solutions often employ what’s know as robots–computers that run FileMaker scripts so that users do not need to execute scripts manually. The release of FileMaker Server 9 debuted server-side scripts, which can reduce the need for robots and take advantage of Server schedules. In this post I’m going to take a brief look at this scripting option.

In FileMaker Server, when you select “Run Script” there are three kinds of scripts available:

• FileMaker script
• System-level script
• Script sequence

As with any instance of limited resources, decisions must be weighed before proceeding. FileMaker Server has a limit of 50 schedules. System-level scripts can be run as cron events (Mac OS X) and system events (Windows), so these scripts might not be the best use of FileMaker Server’s schedule resources.

Running FileMaker scripts can off-load client processes onto the server, thus eliminating the use of robot machines. Script sequences allow a mix of both worlds, since you can script both FileMaker and the OS to run repetitive tasks.

Getting Started

Setting up schedules takes place in the Admin Console, which has a series of easy steps to create a schedule. Once you have selected “script sequence” for the type, you’ll see a list of databases along with a place to enter an account to access the database.

Since a database is usually accessed by FileMaker Pro, special consideration is necessary to run scripts server-side. A file with an OnOpen script needs to take Server into consideration. One option is to use Get ( ApplicationVersion ) and exit the opening script if the result is “Server”.

After the database and account are entered, you select the script that the server will run. (Adding an option to filter for scripts like the Manage Scripts dialog in FileMaker Pro might be a nice future enhancement for FMS.) As with FileMaker Pro, you also can specify an optional parameter.

Setting Sequence Permissions

The next step is to select the sequence options, which is where it gets interesting. Here you can select system-level scripts to run before and/or after your FileMaker script, along with any system-level parameters (see below). Importantly, you also select the account to run the system-level scripts. On Mac OS X this is important because it must match the permissions on the system-level script inside the Scripts folder for FileMaker Server.

Since the default account is fmserver, you should set the system-level script username to fmserver and the group name to fmsadmin. The drop-down will let you select any script in the Scripts folder, but permission issues can cause errors in the execution of the schedule. An enhancement in FMS 11 allows you to set a time limit on the schedule, which can be helpful when a script sequence may run too long and collide with subsequent schedules. In the example below the FileMaker script runs after the shell script. Other examples might have a shell script run first, followed by a FileMaker script, then another shell script. This could involve some method to load and transform data, then export and move the data via the OS. This opens many additional possibilities for FileMaker integration.

Conclusion

Unfortunately, large aspects of server-side scripts remain in a black box environment. Error messages aren’t always clear. The script may fail and the Schedule status shows a FileMaker error. Checking the Log Viewer usually provides more clues, such as Error 100 for file not found, or another FileMaker error. Sometimes the status may be OK but the shell script portion fails, which requires troubleshooting outside FileMaker. Agnes Riley of Zero Blue wrote a post in 2010 covering some of the caveats. Despite these cautions, server-side scripting has tremendous benefits and power.

A subsequent post will look more closely at running FileMaker-only server-side scripts. Does your solution use sever-side scripts? What are some of the best practices and problems you encountered?