FileMaker Server-Side Scripts: File Paths

In an earlier post I wrote about FileMaker Server’s ability to combine system scripts, or shell scripts, with native FileMaker scripts. This shows one of the many ways that FileMaker integrates with external systems, one of the great benefits of working with FileMaker. Yet aside from integration, FileMaker’s server-side scripting also runs native FileMaker scripts. This can off-load many tasks currently assigned to robot boxes, computers whose sole purpose is to connect to FileMaker Server, mimic a user and run various events. With enhancements in FileMaker Server 10 and 11, a veritable movement has risen in the FileMaker community to stomp out robot usage in favor of handling such events through FileMaker Server instead.

There are advantages to running regular tasks through Server. Robot boxes take up resources. The computer running scripts might be better served elsewhere. Security considerations also play a part. Where does the robot box sit? Is it a headless box in a server room, or on someone’s desk? If the robot goes down or fails, how quickly will this be noticed? What about backups? Moving the scripts to server might remove some of this concern.

FileMaker’s Knowledge Base contains a couple of brief entries on server-side scripting, one defining the issue, another looking at differences between client and server-side scripting. Referring to these documents while setting up server-side scripting provides a nice overview of options and things to consider, but there are additional caveats.

External File Paths

Consider the server folder structure. Organizing databases into folders both gives a visual overview of separate types of files, and helps break down the backup process into more discrete parts. While relative file paths like file:filename.fp7 will still find other files, even across separate folders, they will break with server-side scripting across multiple files.

To test this issue, I took a copy of SeedCode complete, which uses three files, and split these into two folders, one for the data, and one for the UI. This will mimic a situation where running backups on the UI might differ from the data files. I then created a script in the UI file that found records in the data file through the External Data Sources. This script worked perfectly when the files were in the same folder. When you separate the files, the server side script failed. This failure showed in the Schedule view, under status – “FileMaker Script error”.

To see what happened, I swithed over to the Log Viewer and enabled Server Events. There you can get more details about any errors. In this instance it showed error 100: File not Found.

The recommended solution is to address the folder in External Data Sources, in addition to the relative path.

I first tried listing just the folder name:

file:SeedCodeData/SeedCodeData

This failed, as did adding a dash in front of the folder name. The solution, recommended by Lisette Wilson, was add two periods in front of the folder name, something quite typical in PHP include files (as well as HTML). The new format looked like this:

file:SeedCodeData
file:../SeedCodeData/SeedCodeData

When I ran the schedule again – no errors! Actually, there was one small error. Since any OnOpen script also runs, I had modified the script to look for Get ( ApplicationVersion ) = “Server”. This would bypass the regular process and skip any incompatible steps. Yet, I still got an error indicating the opening script was still running. The actual calculation result was “Server 11.0v4”. Once I adjusted for this, there were no errors in the Event Log.

Conclusion

This process illustrated some of the frustrations with server-side scripting – there is no Script Debugger when running a server-side script. Even if the Event log shows no error, there may still be unknowns in the process that need to be debugged. To deal with this I often build an event log table, and populate this with information from the script during testing. Also, the exact format of the folder path in External Data Sources took a while to track down. Still, with caution and planning, the possibilities opened by server-side scripting are well worth investigating.