- How do you feed it the necessary data based on your FileMaker Data?
- How do you get a result back?
The examples in the blog posts mentioned earlier use that mechanism.
One of the big downsides of the fmp url mechanism is that it doesn’t work gracefully in WebDirect; it opens a new tab which spawns a new WebDirect session. And there are also URL length restrictions in play that limit how much data you can pass back to FileMaker as the script’s parameter. And to make matters more complex, the length of a URL varies by operating system from a few thousand characters to around 80,000.
With 19, you now have a new JS function FileMaker.PerformScript(). This new JS function works much better than using an fmp url, especially in WebDirect, and in general, it is now completely cross-platform as well. Plus it allows for enormous results to be returned. In our testing, we gave up after generating a result that was 100 million characters long.
Note that this JS function runs asynchronously: it does not wait for the FM script to finish, so you cannot use it to get a result back from the FM script.
Also, since FileMaker 16, the user’s privilege set had to allow for the “fmurlscript” extended privilege to use the fmp url mechanism. In 19, there is no such requirement since everything remains strictly within FileMaker itself, and that generally increases the security of your solution.
FileMaker 13 through 18
The web viewer (object name ‘wv’) gets set with precalculated HTML syntax:
The string that needs reversing is made part of this block of text that is then set as the web viewer’s source.
There is now no difference between macOS and Windows or iOS or WebDirect.
Your web viewer can now be a static library containing many JS functions because they can just sit there passively waiting to be called. The web viewer does not need to be loaded to activate them: you call them by name with the new script step.
First and foremost: despite its name, this script step does not call the FileMaker Server Data API REST service; the name is a bit unfortunate in the sense that “Data API” is already strongly associated with the REST service. It does use the same internal Data API engine in that it uses the same query syntax and the same JSON format for the resulting data.
This new script is somewhat similar to the executeSQL() function:
- You can use it to get data from any part of your solution, independent of the user’s current context.
- You cannot use it to create or edit data (this could change in a future release)
- You cannot use to run scripts (this could change in a future release)
But it is different in that you will get data back based on the layout you specify: all the fields, including portals that are on the target layout, will be returned to you.
The query syntax is described in the Data API help, it’s a JSON object, and in its simplest form, you specify just the layout you want to use and the number of records it should return. The query can, of course, be more complex in that you can specify multiple search criteria, limit and offset the found set, sort the data, and so on. See the Data API help for the options, but keep in mind that the options to run scripts, for instance, are not supported in this release.
The new script can, of course, also be used for many other purposes, including sending data to external APIs for purely for internal FileMaker consumption. This script step is fully supported on all clients, WebDirect, on server, and through the Data API.