By Daniel Wood, 16 December 2021
When developing and maintaining client solutions a really common task is to write a script to either add, modify or delete data for the user. This is usually a time consuming batch style operation that is often faster to run on the server rather than the client.
To run a script on FileMaker Server you have the option of either setting up a scheduled script via the admin console, or running it using the Perform Script on Server (PSOS) script step.
The latter option is the fastest option when needing to quickly run a one-off script.
There's always a catch. To run a script on server via PSOS, you first need to run a local script that can itself run the Perform Script on Server step to call your server-side script – what a drama!
For a long time I used a piece of code that I would always write out at the top of these scripts to achieve this:
Technically speaking there is nothing wrong with this code, I just got tired of writing this all the time. I wanted to abstract this out to a single reusable script. One that could be placed at the top of any other script to force that script to run on the server.
This is what I came up with:
Here we are passing the name of the script to execute on server as a parameter.
This helper script will terminate if already running on server (to prevent repeat recursive PSOS calls).
If it is being initiated by the client, it will perform script on server by name, using the name passed as a parameter.
The halt is to terminate the script that initiated the call. The initiating script is actually the one that is going to be run on server, so we don't need to also continue to run it on client.
Thus, in order to run a script on server, it just requires the below step as its first script step. The rest of the script can be written as if it is to be run on server.
A single step at the top of any script to have it run on server.
The PSOS helper is really optimised here to be run for one-off scripts. It is Asynchronous in that it does not wait for the currently running script.
To run this as part of a solution where certain scripts are run PSOS, then first thing you'll need to do is remove the Halt script step on line 23. This will allow further execution of other scripts to occur. If you wish this to be Synchronous, then change the PSOS call on line 22 to wait for completion. Usually a PSOS that waits for completion expects to get a result back, so in order to achieve this you can exit here and return Get ( ScriptResult ).
As always an example is included. This file doesn't really do much other than contain some. further information around the script, as well as the helper script itself so that you can put it in your own solutions.
No one has commented on this page yet.
RSS feed for comments on this page | RSS feed for all comments
Jeff Henry 29/12/2021 1:22pm (1 year ago)
I've used something like this too to avoid having one script to call a PSOS session and another to process the PSOS call. Except, I usually hardcode the script name with the dropdown because there are times when we may give two scripts the same exact name by accident.
In regards to Dan's comment, when I need to troubleshoot a PSOS, I usually just add an if/else statement with a PSOS call and a Perform Script call and pass a parameter into my Perform Script call to bypass the check for the Server.
Something like :
If [ True ]:
Perform Script on Server [ My Script ; "" ]
Perform Script [ My Script ; "1" ]
Then, if I am using a script debugger, I just move to the Perform Script call.
In My Script, I will have my script do:
If [ Pattercount ( Get ( ApplicationVersion ) ; "Server" ) > 0 OR Get ( ScriptParameter ) ]:
... Proceed with the work.
... Call the script server-side with no parameter.
Dan Rosenstein 20/12/2021 12:15pm (1 year ago)
That’s really smart Daniel! Thanks for sharing.
I would probably add a debug variable flag to override, since it’s hard to debug PSOS.