If you go looking for a FileMaker script step called Perform Script on Server on Server, you are not going to find it. Because this isn't a new script step, but rather the same Perform Script on Server (PSoS) that we have always had, except that now it is FileMaker Server-compatible.
This capability allows FileMaker to fire off other Perform Script on Server scripts (from an existing script that is running on server), and either wait for those to complete or not. I have been thinking that with this feature one could build a main controller script and a set of worker scripts. That is just one idea, of many, I am sure.
A Decade+ of PSoS - Looking Back
FileMaker 13 came out in December of 2013, and it included what has become one of my favorite features, ever: Perform Script on Server, aka 'PSoS'. I have written a number of blog posts about the use and benefits of PSoS over the years–below is a list. I won't repeat the information included in any of these. So if this is your first time working with Perform Script on Server, I would encourage you to look into the first couple of posts as that information is still relevant today.
Brief History of FileMaker Perform Script on Server (PSoS)
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
Perform Script on Server with Callback – Episode IV: Call Ya Later
FileMaker Log Files: Episode VII – PSoS Awakens
Imports without Tariffs. Natively, with FileMaker Server.
Architecting Flexibility and Control
PSoS running on FileMaker Server gives us much more flexibility to architect workflows that were not so easy, nor even possible, before. For example, you could fire off a script that is not going to wait to return a result, thus performing the script with 'wait off'. But once that script is running on the server it could in turn run some helper scripts to do some processing. For example, a while back when I used to use kayak.com to search for a flight, it would open up 3-4 'worker' windows and run queries for different airlines. With FileMaker, the 'workers' scripts would communicate with the main script that called them or report back to it.
Imagine you work at an insurance company and need to collect bids from different insurance agencies, so you fire off each worker to collect the bids for a client who is looking to get new car insurance. Once all the workers have completed their work then one can look at the results and compare.
Another scenario is to combine Perform Script on Server with Callback with the ability to use Perform Script on Server (on Server) with Wait On/Off. Then you can have those worker scripts gather data from different tables to feed it back into the Callback script. Once all the workers have done their work then the Callback script does what it is designed to do, which is to call the client back and run a script on the client. When the Callback script is run it calls Configure Local Notification to issue a notification. And when you click the notification you can then see the result, which could be a report.
I'll admit this is a contrived example. One might even think of this much like managing threads on a computer. Once all the workers report in to say they have completed their work, only then does the Callback get fired. The example doesn't include error trapping and timing out if one of the helpers doesn't complete, but those can be added.
Here's the demo, using our Movies example solution:
Account Name: Admin
Temp Password: admin
Host this file on your FileMaker 21.1 (or greater) Server ...
This example is just a proof-of-concept so you can see how this might be wired up.
Let us know if you have any questions with this.
Thanks!
- Vince
