FileMaker 2023: Perform Script On Server with Callback (PSOSWC)

Claris has departed from the tradition of sequentially numbering its product releases. They decided to use the year of the release in the name of their latest release – FileMaker 2023. Yet, a word to the wise, while the name of the software is FileMaker 2023, the version number internally to the software is FileMaker 20.x.x.  

Claris FileMaker 2023 includes many new features. The Perform Script On Server with Callback (PSOSWC) function is arguably the most exciting new script function we’ve seen in years.

PERFORM SCRIPT ON SERVER WITH CALLBACK

This script step instructs the server to trigger a script back on the client that initiated the event after performing a script on the server, thus, a callback. Nonetheless, there are a few technical details/caveats to be aware of as we explore this feature for our apps.

• This feature will only work if the server and client run FileMaker 2023.
• The callback script will only run when the client is idle and no other scripts are running.
• WebDirect supports PSOSWC.

Why is this exciting for FileMaker developers? Well, sending a script to PSOS before was a bit of a black box. Unlike using the script debugger in the client, we can’t step through a script and see the errors that it returns. We can refer to the log on the server and see them there, but that can often be tedious to sift through, and sometimes our access to the server is limited. Using a callback, we can script error trapping that can be sent back to the client with the native FileMaker error codes. We can also customize the data we send to test if our script is doing what it should while running on the server. Of course, it was possible to do this using Script Results before, but the callback is more elegant and easier to implement. 

Another use case for this feature, which can benefit developers and end users alike, is when we have a script that requires a long time to run. Rather than tie up the client with this activity, we can send that script to run on the server. Then a callback script can notify the user when it’s complete.  

So how do we set this up? To use this feature, we need three scripts:

1. One script to call the PSOS script step
2. Another script to run on the server
3. A final script to run on the client as a callback. 

As a demo/test, we’ve created a sample file with one million records. We’ve written the three scripts above. 

The first script – PSOS – Set New ID – will call the new Perform Script On Server with Callback script step: 

The second one is the meat of the process; this will replace the contents of a field with Get(UUID). Again, doing this via the client on a hosted file would take forever. Doing it via PSOS will take much less time but still consume resources, so it would be nice not to have to wait for the script to finish.

The third script notifies the user that the script is complete. 

As a test, we started the “replace” script manually, running the replace script step in the client locally. This method was prolonged and would have taken much of the day to complete. 

The next test was to run the PSOSWC script step. Seeing it fire off was a bit disconcerting, with no expectation that we had to wait around for it to complete. But the minute it started, we could see records updating in our client. We left FileMaker running but proceeded to do other things like check e-mail. We could have been using FileMaker as well at the same time. Within about 5 minutes, our last script fired, and a dialogue box popped up to alert us that the script was complete. We are amazed at how productive this technique is. It’s like having another computer at our disposal. 

There’s one other interesting feature to review with this: Script Results. With the old PSOS, we could pass our script results back to our original script. What happens with PSOSWC? The script result from the PSOS script gets passed to the callback script. Since the original script runs asynchronously, there’s no place for the results of that script to go except the callback script. So, to demonstrate, we adjusted our main script again:

First, we limited the record count to 100,000 to speed up the processing time for this demonstration. Second, we captured the replace operation’s start and end times to record how long it takes to run this script. This script is an example of local variables and data that will not be stored but are still valuable information that we can distill and transmit. We’ll pass the total elapsed time to the callback script and display that in the pop-up dialog box. 

And this is the final message:

What a gift to developers! This minor feature will have major benefits. Anyone using PSOS will likely convert to PSOSWC. We can’t wait to see what the FileMaker developer community does with this and the productive workflows they develop.