The FileMaker command Perform Script on Server offers a powerful tool for speeding up performance by keeping the process local to the server. This option can greatly improve situations where significant data must be handled or where the server connection is slow.
The script command has a simple syntax and offers the option of whether or not to wait for completing the script before the user regains control of their session.
Perform Script on Server [ Specified: By name ; {script name} ; Parameter: {parameters} ; Wait for completion: off ]
Deciding on whether to select the Wait for completion option depends on whether the script must complete before the user can continue with their current process. For example, the script might need to prepare a list of addresses before the user can check off which addresses to select. However, in a surprising number of cases, waiting for completion is not necessary and the user experience can be improved significantly by turning Wait for completion off.
Server Talkback
Running a server script without Waiting for completion sets up an independent user session on the server to complete the script. The downside is that the user can lose control over the script process and cannot see progress during completion. Server talkback can provide a channel to communicate with the user and even provide user control over the script in process.
Server talkback sets up a channel for the server to communicate information back and forth with the user. In this approach, server talkback is achieved by sharing a session record between the user and the server that includes the information required. A method that we use works as follows:
A session record is issued to a user when they log onto the application with a UUID that can be shared with the server. This UUID is passed as a parameter to the server when the Perform Script on Server command is called. The record includes all the control and reporting fields required for the server to communicate with the user.
Javascript object notation (JSON) provides a handy mechanism to pass script parameters in this manner. The server script captures the session ID and sets up a corresponding connection to the session record. An easy way to control access to the session record is for both the user and the server to use a global field “selector” to identify the session that will be used to communicate. This global connection can be set in one or more places as required in the relationship graph. In this example, a global in the system (SYS) table has an equi-join relationship to the Session table.
Since the server and the user now both have access to the session record, data can be easily passed back and forth as needed. An absolutely fundamental requirement of this approach is to always commit session record changes as soon as they happen. This procedure will ensure that the session record is not locked and that the user’s data is refreshed right after the server commits.
Some useful functions that we have been using include: debugging server scripts by building a script trace log and transmitting it back to the user; providing progress reporting on a long batch runs and allowing the user cancel; sending commands to a star controller on the server to perform various outcomes; and reporting back API batch processes. We will dive into some of these use cases in more detail in the future.