Our FMRPC product and other techniques have allowed this type of functionality with FileMaker 12, but having this capability built into the FileMaker 13 platform means we can leverage it much more broadly. Performing a script remotely allows us to build solutions that:
- Dramatically improve remote performance for data-intensive tasks
- Access plug-in features and complex web services from FileMaker Go
- Perform scripts asynchronously
- Seamlessly leverage FileMaker’s security model
When the client is FileMaker Pro and it’s on the same fast local network as the server, performing a script on the server instead of on the client will likely have very little performance benefit. However, as the network latency between the client and server increases (Wi-Fi, WAN, 3G/4G) or the performance of the client machine decreases (iPad, iPhone) performing a script on the server can be many, many times faster.
Some of the kinds of scripts we’ve found to have the highest performance improvement include:
- Scripts that create, modify, or delete many records
- Scripts that aggregate or summarize data
- Scripts that need to perform finds on unindexed data
FileMaker Go can’t directly use plug-ins, but a script called by Perform Script on Server can use plug-ins that are installed on the server. This lets you do things like:
- Process a credit card using the 360Works Plastic plug-in
- Access a SOAP-based web service
- Perform SQL statements (including SELECT, INSERT, UPDATE, and DELETE) within your FileMaker database
- Manipulate images and other files
- Execute shell scripts on the server
In order for plug-ins to be available to the FileMaker Script Engine, you must configure FileMaker Server to enable support for plug-ins and enable each plug-in after installing in the following location:
- Windows: \Program Files\FileMaker\FileMaker Server\Database Server\Extensions\
- OS X: /Library/FileMaker Server/Database Server/Extensions/
Perform scripts asynchronously
Sometimes a system has a feature that needs to be initiated by a user, but the user doesn’t need to wait for the result. The Perform Script on Server script step has a handy “Wait for completion” option that is perfect for this scenario. The option is enabled by default, but you can uncheck the option to cause the client-side script to immediately continue after telling the server to perform a script. Keep in mind that when you do this, Get( ScriptResult ) will not contain a value.
FileMaker’s security model allows the server-side script to be automatically run with the same account that called the script on the client. The server-side script will respect all of the privilege settings for the account. This is a major benefit for systems that have relied on scheduled scripts for server-side processing since scheduled scripts require the credentials to be entered at the time the schedule is created.
Since the client’s account is used by the server-side script, the values returned by functions such as Get( AccountName ), Get( AccountPrivilegeSetName ), and Get( AccountExtendedPrivileges ) will be identical on both the client and the server-side scripts called by that client.
Other things to note
The OnFirstWindowOpen and OnFirstWindowClose script triggers will fire on the server each time a script is called using Perform Script on Server.
The server-side script will NOT have the same context as the client. This means that things like the found set, current record, sort order, variables, and global field values will not automatically be the same. You may be able to build logic into your script to reestablish these.
You should always check for an error after Perform Script on Server. There are several situations where the script step itself will fail, including:
- The client is FileMaker Go 12 or FileMaker Pro 12.
- The host is FileMaker Server 12, FileMaker Pro 12, or FileMaker Pro 13.
- The script that is calling Perform Script on Server is running as a scheduled script.
- The file is opened locally by FileMaker Pro 13, FileMaker Go 13, or a runtime application.
Your script can check Get( LastError ) and handle the error by doing a regular Perform Script to perform the script on the client or perhaps display an appropriate error message if the script can’t be run on the client.
While the server-side script is running, Get( ApplicationVersion ) will return something like “Server 13.0v1″ and Get(ScreenWidth) and Get(ScreenHeight) will return 640 and 480, respectively.
Uncommitted data on the client side is not available within the server-side script. You may need to explicitly commit data in all windows if you want that data to be available to the script.
Perform Script on Server is a fantastic new feature for remote performance optimization and for executing plug-in features from within FileMaker Go. In a future article, we’ll share some specific examples and look at objective performance measurements to help you understand when to use this new tool. In the mean time, you may find some of our FMRPC articles and videos useful as you explore ideas for implementing server-side processing in your solutions.
Greg Lane is VP of Application Development at Skeleton Key and a FileMaker Certified Developer.
Skeleton Key is an accomplished team of technology consultants that solve problems. We're well-known as experts in FileMaker, and we have a lot of experience integrating PCs and Macs. We're also certified trainers who emphasize constant education for ourselves to best serve our customers.
Our job is to make your systems function smoothly, with all the right elements in place. We are solution-agnostic. That decision was one of our first as a company, and it makes us customer-centric in a way nothing else can.Website: www.skeletonkey.com