Server Side Scripting With A Dedicated Execution File

I am still wrestling with a 100+ legacy database solution. I haven't been able to consolidate or re-write yet but have been slowly, version by version starting to deploy new Filemaker features. One thing I did, was set up a Filemaker file who's sole purpose is to call and execute server side scripts.

Now that we have script triggers firing off, God knows where (on file open, on layout load, on object enter... for example), you really have to make sure that stuff isn't firing off for a server side script and you don't always have time to review all of the dependencies of executing scripts from a given database file. If you do and do not do your homework, you may be calling incompatible script steps which could hang your server script or create loads of errors in your logs.

I wanted a simple, fast and safe way to call scripts across the 100+ file solution and be sure that on window open scripts didn't fire. Typically, the on file open scripts tend to do things like call custom menu sets or other non-server-side script compatible steps. So, knocking those out of the picture this way was a big plus.

Setting up my server side scripts to run from the dedicated execution file, each call remote scripts through out the solution, seems to be doing the trick. When performing REMOTE scripts the remote file ON OPEN scripts don't run.

When writing the worker scripts, that live in the remote files, I will typically create a clean layout - one that that has no bells and whistles attached to reference.

I also like the fact that you can go to the dedicated script execution file and see all the various server side scripting routines at play or in development. Also, a good place to document the scripts and organize in folders. I like to use a PRODUCTION folder and TESTING folders. It's also cool when you have more than one developer. Using a consistent naming scheme for server-side-scripts located across the 100+ files in the solution will make it easy to locate them in a pinch on a file by file basis or even from a DDR perspective.

Not everyone would want to have an extra file in their solution for this purpose but in this use-case I have 100+ what's 1 more, to me nothing. It's kind of nice quick way to move ahead when working on a massive system that sprawls over a decade of FM versions and code. It does require following a development process for server side scripts:

1. Use a naming convention for your worker scripts, so you can find them
2. Always run your worker scripts off lean utility layouts that don't have script triggers
3. Make sure you aren't calling other scripts that will do incompatible script steps or incidentally reference layouts that call scripts that do incompatible things
4. Create a script in the dedicated execution file to call/RUN your main worker script

I'm working on a new server side script and was reminded again that this method I had come up with a while ago, does seem to be working well. I avoided some headaches of having to review what on open routines were doing that could cause me pain and it actually saved me some time. An idea I tried a while ago is paying off today.