FileMaker 2023 introduces Perform Script on Server with Callback, a new asynchronous method to execute scripts with FileMaker Server. Now we have a way for FileMaker Server to execute another script, a “Callback” script, when one script is done processing via Perform Script on Server. It’s like calling your virtual assistant and instead of waiting on the phone for 5 minutes for info, they basically call you back when they are ready with an answer.
The end result is improved performance, better management of complex script workflow, enhanced user experience, and new possibilities for handling integration with APIs, email and services like Claris Connect.
And yes, the photo above is a rotary telephone ☎️ – which goes to show you how long I have been around for!
Perform Script on Server, now with Callback
Introduced almost a decade ago, Perform Script on Server (aka “PSoS”) – the ability to run scripts via FileMaker Server – forever changed the way we approach developing Claris® FileMaker® solutions.
Extending that even further, FileMaker 2023 introduces Perform Script on Server with Callback…
…or, as we like to refer to it, PSoSwCB
What is “Callback”?
So you’re wondering what is the big deal about the “with Callback” part?
Before today, we had two choices to perform our scripts on the server: synchronously (Wait for completion: On) and asynchronously (Wait for completion: Off).
The “Off” option is “asynchronous” in the sense that, once executed, it works alone. It may do something useful and efficiently (without waiting), but it wouldn’t otherwise continue running a script, nor respond, such as to execute other scripts.
The “On” option comes with the advantage of continuing to run its own script, but comes with the drawback that you need to wait for completion to continue a script. PSoS is fast, when FileMaker Server is fast, but technically involves “freezing the client”, while we wait for completion.
In fact, here’s how FileMaker Pro Help describes the new option:
Perform Script On Server with CallbackPerforms a script on the server that is hosting the current file without freezing the client and performs the specified callback script when the server script is done.
And, PSoSwCB isn’t an extension of the already existing script. With Callback, it is running a brand new script:
You’ll notice that we don’t have an option to wait for completion:
And that is because PSOSwCB is inherently asynchronous. When you configure it you are actually defining two scripts: both the script you want to perform the work, and the script that will get a Callback once the work is completed.
PSoSwCB vs. PSoS: The Same Rules Apply
Most of the same rules apply to PSoSwCB, as before with PSoS. So, let’s provide some background on PSOS.
One of my favorite features in Claris FileMaker, Perform Script on Server was added in version 13 (my favorite number, btw). Here are a few of the blog posts we have already done on this topic:
100x Faster – Flight Testing FileMaker Perform Script on Server – Episode I
What Are Your Imports Waiting For? FileMaker Perform Script on Server – Episode II
Logging PSoS Activity: Episode III – Return of the JSON
FileMaker Log Files: Episode VII – PSoS Awakens
Wow, four posts already and this one makes five. I skipped “Episode IV”, so I figured I would use it for this blog post. I’m sticking with this numbering, unlike Star Wars.
It’s not necessary you read these in a particular order, except if have never used PSoS (don’t know how you could!), then I would recommend you read Episode I. It goes into great detail on the things to watch out for with PSoS , and those rules also apply to PSoSwCB.
Here’s are some things important to understand:
Exiting File Options Script Triggers
Whenever you run a script on Server, what is happening under the hood is that another session is being constructed. This is like a mini client of you, with your same access credentials, running on the server. Because of that if you have any of the File Options script triggers enabled – then each of them will run!
@Claris – might be a good time to make this window slightly taller so we don’t have to scroll!
A best practice is to exit out of these File Options script triggers as soon as they run. Here is what the main block of our start up scripts look like. Note that I’ve used Single Pass Loops everywhere, and generous helpings of emojis 😎! This is to help call out attention🧑🏼✈️ and 🚧 warnings to things 🥬.
IsServer is a custom function with the following in it:
PatternCount ( Get ( ApplicationVersion ) ; "server" ) > 0Important: If you have a long startup (On First Window Open) script, consider that all of it will run … every time you execute PSoS. Exiting will help speed things up for your PSoS scripts.
Security Considerations
The second important point is that of security 🪪! Normally we load some values into globals on start up for a particular logged privilege set. And in the record-level access calculations we check to see if the user is allowed to view, edit or delete certain records. The easiest and fastest way we do this is by loading some values into a global, and then checking that global against data in the record.
Let’s say you have different vendors who are able to log in and see some sales records, but you only want a vendor to see their own records. A simple calculation might be the following:
GLOABL::VENDOR = SALE:VENDOR
That global value would get populated by a startup script. However if you exit out of it, then when your PSoS script tries to run a report for that vendor’s sales, no records will be accessible. This is because no value got loaded into the VENDOR global. Make sense! So you might want to execute some small part of the startup script — just enough to load your globals and exit. Thus, your startup script might look something like this:
Trust me…These are the two most important things not to forget so you can enjoy your PSoS ride. And if you don’t pay attention to both of these, your PSoS experience and the experience for your users may be a frustrating one. I have had many doh! moments with both of these issues, but mostly with the security one 🤦🏻♀️🤦🏽🤦🏼♂️.
Performance Benefits
If you have users on a WAN, then you’re always looking for ways to make certain that FileMaker performance is optimal. I have given many talks/presentations on the topic of transactions, and seen other great presentations in the Claris Community on this topic. The reason I bring it up in this context is because we rely on PSoS to perform transactions. I invite you to check these resources out:
DIGFM (12/8/22) Native Script Transactions in Claris FileMaker! [Vincenzo Menanno – Beezwax]
DIGFM (6/10/21) The Benefits & Value of Transactions, Part 2 [Vincenzo Menanno – Beezwax]
DIGFM (2/11/21) The Value and Benefits of Transactions, Part I [Vincenzo Mennano – Beezwax]
The New Horizon: Script Transactions in Claris FileMaker [Vincenzo Menanno – Beezwax]
Imports on FileMaker Server, using PSoS
We also pioneered running imports on the server also using PSoS. Read this blog post to learn more:
What Are Your Imports Waiting For? FileMaker Perform Script on Server – Episode II
In my great deal of experience improving performance of solutions using PSoS, I have learned a lot. This includes the fact that you can also abuse PSoS if you are not careful, and should plan out what you are doing. Having too many long running PSoS sessions ‘may‘ have a negative impact on performance. You have been warned!
Claris FileMaker 2023 – Perform Script on Server with Callback: Examples
Example 1 – Simple Perform Script with Callback
Let’s look at three ways in which we can benefit from using PSoSwCB. It behaves the same way that PSoS without wait option so it runs asynchronously. The nice benefit is that once it completes it then can run a script, and that script can do pretty much anything you would want it to do. It can receive a parameter as well using the Exit Script Step.
Here is an example of this simple workflow:
As I mentioned at the beginning, with this new PSoSwCB script step – it is inherently asynchronous. So once you invoke it it will trigger the script to run on server and return control back to the script and continue executing the rest of the script.
So in the case above, once the Generate Report script completes that already knows what script to send the callback to. And the you can use the Exit Script step to send back a parameter.
Note: This convenience that it calls you back and runs a script is great. However, once invoked and the script takes a while to generate the report, when it finally calls you back it would be nice if it did it in a polite way.
What if the Callback option wasn’t a FileMaker script but rather an OS notification instead? So, if you got busy entering data, when the Callback script runs it would kick you out of your data entry mode. Unfortunately we don’t have this option available to us. But what we can do is trigger an AppleScript that will send off that notification. This introduces a very, very slight delay and doesn’t get you out of what you were doing. This means if you were in a field typing, you would be able to continue typing. It also doesn’t change context etc. I only got this working on the Mac but I am sure something similar can be also done on Windows.
If on the other hand you are currently running a script it will wait till that script completes and then run the Callback script. Here is what that notification script might look like:
And here is the AppleScript code:
"display notification " & Quote ( $_title ) & " with title " & Quote ( $_message ) & "¶" &
"-- delay is required as script must be active when notification is shown" & "¶" &
"delay 0.5"
Here is an example of how the notification looks like when it is displayed.
Example 2 – Controller Script with Helpers
Let’s look at another use case. Let’s say you wanted to have a script create a report but it needs to collect data from 5 different sources. You could architect it something like this.
The Main Script calls a PSoSwCB script and sends a UUID along with the number of workers. The Controller ( a PSoSwCB script ) creates a record and stores the UUID along with the number of workers and then sits waiting in a loop. Each time a worker completes its task of gathering data it will then update that Controller record. Once the Controller loop script sees that all the workers have completed then it exits the loop and triggers the Callback script on the client.
You could also architect this using a script schedule, but this is more direct and connected to the user. Plus you get the added benefit of the Callback when the task is completed.
Example 3 – Making use of Trigger Claris Connect Flow
This example takes advantage of another new features in FileMaker 2023, and that is triggering a Claris Connect Flow. They have done a great job with this new feature too.
In the past when trying to set up a trigger to a Claris Connect Flow you might have had a script that looked like this prior to FileMaker 2023:
Now with taking advantage of the new script step in FileMaker 2023 to accomplish the same result your script would look something like this. So one less step, simpler and easier to implement and you won’t have to fuss with cURL options… which can be frustrating for many users 😖.
The new script step is also Server Compatible so that allows for some interesting flexibility as demonstrated with the example below.
Conclusion
Having the new Perform Script on Server with Callback in FileMaker 2023 is a fantastic addition to the ever growing set of features we have to improve performance, better manage complex scripts, enhance user experience, and open new possibilities for building custom solutions using the entire Claris Platform. Hopefully the examples provided will help you to imagine more uses for PSoSwCB for your solutions. If you find some creative ideas for this, please let us know, we would love to hear from you.