The idea of being able to off-load time consuming tasks from FileMaker Pro to FileMaker Server is as old as the scripting abilities of FileMaker Pro, which were introduced with the FileMaker Pro 3 release. But it was the FileMaker Server 13 that finally made this idea easy to implement.

The History

In the history, this need led to implementing a solution well known as a “robot machine”. Robot machine is a stand-alone FileMaker Pro client constantly connected to the FileMaker Server and regularly checking whether there is a task ready to perform.

Much better, safer, and correct in principle, solution was introduced with the release of FileMaker Server 9, the first version that allowed creation of server-side script schedules. At that time only a limited subset of script steps were compatible with server-side scripting, but some of the robot machines could finally be replaced by this feature.

Following versions of FileMaker Server were slowly extending the set of script steps supported by server-side scripts, until now, when almost all meaningful script steps can be used server-side. One of the few exceptions persisting, probably due to licensing issues, has been the Save as PDF script step, finally made available in FileMaker Server 16.

Server-side scripts could also benefit from server-side plug-ins almost from the beginning… Well, officially. But realistically, it was not very easy and safe to use them until the release of FileMaker Server 12, when the server-side scripting engine was completely separated from the database engine to make sure that even a disaster such as plug-in crash does not affect the main database hosting functionality of FileMaker Server. FileMaker Server 12 also finally supported multithreading, enabling you to run a labor intensive server-side script without significantly affecting performance of connected clients.

Script On Demand

One of the main drawbacks of server-side scripts has been that they had to be scheduled. There was no obvious way to run a server-side script on demand, and schedules could not be set up for shorter period than one minute. So to have a task processed by a server-side script you could have had to wait up to a minute. This was sufficient to replace the robot machine for long labor intensive tasks but could not be utilized to speed up short (under 1 minute) tasks, whose primary reason for slowness was the need to transfer a lot of data between the server and the client.

There was no obvious way but a few ways actually existed. One possible technique to use was to create a one-time server-side script schedule and then somehow remotely trigger the schedule through the fmsadmin command-line tool. This was, however very hard to set up without introducing security risks, and I don’t know of anyone actually using this technique.

Another way was to trigger scripts through the PHP web publishing. Scripts triggered this way are not really running the same way as server-side scripts, as they exist in the context of the web publishing session. But since it is relatively straightforward (if you have at least basic knowledge of PHP) to trigger a script this way and it does not take more than a few seconds (in the worst case of not yet initilized web publishing), and it is also naturally secure if you do it properly, this technique has actually been adopted quite widely, and even led to some companies introducing ready-to-use solutions. The most popular ended up being SkeletonKey’s FMRPC and 1-more-thing’s FMSDIFM.

However, even though being quite successful, these solutions were still too difficult to implement and deploy for an average developer.

Plug-In On Demand

Besides performance optimization, another common reason for triggering server-side scripts on demand has been to intentionally evaluate a plug-in function on server. Originally, this was primarily wanted to access and manage externally stored files on the server’s storage, but with the release of FileMaker Go this demand significantly grew because developers wanted to be able to use server-side plug-ins to provide missing (mostly computing) features to their mobile solutions.

Since the only way to trigger a PHP script (without switching to Safari) from within the first version of FileMaker Go was through the Web Viewer and it was not easy to process the result of such call, one more technique has been developed by CNS to trigger server-side plug-in features. The technique was based on performing a find which, for performance purposes, evaluated an unstored calculation in a field on the server.

This technique was however even harder to understand and implement for an average developer, so it did not get adopted very widely. Even the article where Jake Traynham explained this technique, is not available any more.

RIP 3rd parties, Live Long Perform Script on Server

Although this all has been an interesting, entertaining, and educating journey, all the above mentioned techniques now belong to the past.

The FileMaker 13 product family introduced, besides other new features, a new script step called Perform Script On Server.

Many developers I have discussed this new feature with agreed that if this was the only feature added to the product, it would be would be worth the upgrade price. That means something!

The new script step is as easy to use as the Perform Script step, and it even supports returning result, if you opt to wait for the server-side script to complete.

Yes, you can even decide not to wait and leave the server-side script running, which is great for lengthy tasks. It is also good for another reason – to prevent the user from being able to interrupt the server-side script. One disadvantage of waiting for the result is that when the client interrupts the current script (or disconnects from the server), the initiated script on the server gets interrupted as well.

I could write pages of text about how this feature changed everything and what value it can bring you, but that would not make you more capable of understanding the power of the Perform Script on Server script step.

The truth is as simple as this:

With FileMaker Pro 13 or later you can perform a script on FileMaker Server 13 or later on demand, and you can do it as easily as performing a script in FileMaker Pro.

Matt Petrowsky published a great video tutorial explaining how this new script step works and how you can use it. During the first 5 minutes of his video, Matt states that: “You no longer have an excuse to not use plug-ins.”

Actually if you don’t use Perform Script on Server and server-side plug-ins, you will most likely be missing more than half of the potential of FileMaker Server these days.

So watch Matt’s movie below, and learn how to performs scripts on server:

Then think about what might be the first plug-in feature you could benefit from having used server-side…

But don’t forget that every new possibility comes with a cost. And the cost of the Perform Script On Server script step is that it always creates a new session. So if just opening your database and establishing a new session consumes significant time and resources, then it still may not be the right thing for you. At least until you optimize the session creation. But that’s already a topic for another article…