Triggering a server-side script Part I

FileMaker does most of its processing client side. That means when a client wants to do a find, or show the result of a calculation, the data necessary to do the action is transferred from the server to the client and the client calculates the result. This is handy because you don’t need super powerful servers and the amount of load put on the server itself is reduced. But there’s a tradeoff, in some circumstances, it can also be extraordinarily painful. If a lot of data needs to be moved, the transfer becomes a huge bottleneck.

There is a solution to this. A FileMaker Pro ( or Go ) client can trigger a server-side script using a call to the web publishing engine. This is real handy if you want have a task that touches a lot of records or is otherwise data intensive. A script that would take minutes locally, takes seconds on the server.

The solution is to use the FileMaker 12 script step, Insert From URL[], to place an XML call to the Custom Web Publishing Engine. That XML call specifies the script to be run by the server. Pre-12, I believe you can use Set Web Viewer[] for similar results.

To implement this:

1) Enable Custom Web Publishing with XML on the server.
2) Write the script you want to run on the server. It can only use Custom Web Publishing compatible script steps. Check “Run script with full access privileges”.
3) Enable the [Guest] account in Manage Security. Allow only the XML Extended Privilege. Give access to no records, no value lists, and all layouts. You should choose to allow access to only the specific server side scripts you want to call.
4) Write your calling script. The calling script is what will run on your client. The core script step is Insert From URL[]. That should take a URL of the format http://HOST.IP.ADDRESS/fmi/xml/fmresultset.xml?-db=FILE.NAME&-lay=LAYOUT.NAME&-view&-script=SERVER.SCRIPT
5) Run your calling script from the client!

Part II will include a custom function to create your URL, an example of a feeder script to manage the process, and an explanation of why the Guest account is necessary.

Part III will be an exploration of how this process can be used to create FM Go “updateable apps”.

3 Comments

  1. Scott says:

    Thanks for posting, David. I am anxiously awaiting parts two and three.

    – – Scott

  2. David,
    Thanks for the explanation – and for your earlier comment on my TT post – this is really helpful and much appreciated – I also enjoyed browsing some of your other blog items.
    Cheers
    Nick

  3. David says:

    Hey Nick,
    Thanks for reading!
    DJ

Leave a Reply