FileMaker scripts and the FileMaker Data API

A FileMaker script is one or more instructions (script steps) that you define to automate repetitive or difficult tasks. When used with the FileMaker Data API, FileMaker scripts can allow web services to perform more tasks or a series of tasks. See Run FileMaker scripts.

To see script steps that the FileMaker Data API supports, in the FileMaker Pro Script Workspace, click the Compatibility button and choose FileMaker Data API. Script steps that are not dimmed are supported for the FileMaker Data API. Some script steps function differently or may not be supported in the FileMaker Data API. See FileMaker Pro Help.

Scripts run by the FileMaker Data API cannot run scripts in other FileMaker files unless the files are hosted on the same host. The other FileMaker files must have the fmrest extended privilege enabled.

In FileMaker Pro, both scripts and user actions (such as the user clicking a field) can activate script triggers. But in FileMaker Data API solutions, only scripts can activate script triggers. For information on script triggers, see FileMaker Pro Help.

Notes 

  • Consider the amount of data and the number of records a script may return, and define scripts accordingly. In FileMaker Pro, a script may return all the records from a table or from the current found set. But if a script returns all the records from a table, a web service may run out of memory trying to process the records.

  • In FileMaker Data API solutions, the OnFirstWindowOpen script trigger is not activated. The OnLastWindowClose script trigger is activated only when a script closes the last virtual window. You can run scripts manually using the script API endpoint or by including the script.prerequest, script.presort parameter, and script parameters in the request body.

  • Use accounts and privileges to restrict the set of scripts that a web service can run. Verify that the scripts contain only web-compatible script steps, and provide access only to scripts that should be used from a web service.

  • Consider the side effects of scripts that run a combination of steps that are controlled by access privileges. For example, if a script includes a step to delete records, and the web service does not log in with an account that allows record deletion, the script will not perform the Delete Records script step. However, the script might continue to run, which could lead to unexpected results.

  • In the Script Workspace, grant full access privileges to a script to allow the script to perform tasks that you would not grant individuals access to. For example, you can prevent users from deleting records with their accounts and privileges, but allow them to run a script that would delete certain records under conditions defined in the script.

  • FileMaker Data API endpoints are intended to immediately commit data changes, but scripts may leave records uncommitted. For example, one session could run a script that edits a record but doesn't commit it; the next session would then get an error when attempting to edit the same record. Or within a single session, one script could edit a record, then create a new window, then call a second script that attempts to edit the same record. Be sure to verify script results and check for script errors.

  • Any script that modifies data should include the Commit Record/Request script step, because data changes aren't accessible until the data is saved to the server. This includes script steps like Cut, Copy, and Paste. Many single-step actions should be converted into scripts to include the Commit Record/Request step. When designing scripts that will be run from a web service, include the Commit Record/Request step at the end of a script to make sure all changes are saved.

  • Open each script that web users might run, and verify that the script will run properly when the database is hosted as a FileMaker Data API solution. Check that the script uses only script steps that are supported by the FileMaker Data API, as described above.