by Kate Waldhauser
The Execute FM Data API Script Step – A Use Case
One of the newest script steps in FileMaker (added in FileMaker 19.0) is the Execute FileMaker Data API script step. With the initial release of 19.0, this script step was not yet documented in the help documentation, but recently Claris quietly and formally added it here. The script step is quite powerful as it allows us to easily interact with the FileMaker Data API by making requests and returning data without having to go through the hoops of creating and authenticating a session. Basically you can use the script step to call a limited set of the FileMaker Data API on the current file you are logged in to. Below I describe some of the limitations and benefits as well as a use case of how to apply this new script step.
Limitations: Currently the script step can only be used to retrieve metadata and reading data for the current file. It has not been extended to the capability to update or delete records. It runs only in the current user’s login session, so it’s not possible to use an alternative account when running this step. Also, be sure that the user who is logged in has the FM REST extended privilege, which is necessary to use the FM Data API.
Benefits: It’s compatible with every product, including WebDirect and FileMaker Go. It’s context-independent and great for returning records without having to switch layouts – similar to SQL queries, but the results are formatted in JSON. It works fine returning data from tables that are using external data sources within the same file.
Use Case: Loading Data on Demand
Problem: In working on some code that performs a one way sync from a hosted FileMaker file to a local mobile iOS app built with the FileMaker 19 iOS SDK, I encountered some performance issues when attempting to parse large amounts of JSON. With smaller chunks (roughly under 100 objects in an array) the time it takes to parse the JSON and create new records is negligible, however some of the data I had to retrieve included over 4,000 objects.
Solution: The solution was to parse only the data that was to be displayed on the UI at the time it was to be viewed. So, for example, instead of loading all contacts and their related records at one time, it’s only necessary to load one contact at a time – when they are viewed. The same goes for their related data. When the layout is accessed which displays the contact’s related records, only those are loaded. I used Execute FM Data API to retrieve data about the layout I was on, and then determined which records to load. This is all done dynamically using the new script step.
When specifying a request for the current layout and using the offset and limit parameters to request only the current record, I can retrieve the current record count, names of any portals on the layout and their record counts as well. This tells me if the data has loaded or not. Because the Execute FileMaker Data API is contextless, I can actually pass in any parameters to grab data from any layout, but in this case I wanted the context of the data API query to be the layout the user is currently on so I simply used Get(LayoutName). I wrote a simple wrapper script that requires a parameter of the “request” and then checks for errors and returns those errors or the retrieved JSON as the result.
If my script runs without error, it will return something that looks like the below JSON object. As you can see, this result tells me the number of records on the current layout and the number of records in the portals on the specified layout. From here, I can call my script to create and load the related data I need for this record.
This is just one example of the power of the Execute FileMaker Data API script step. There are many more options and parameters to return different metadata and results from queries. I’m excited to see the next use case for this cool new script step.
Get In Touch!
If you’d like to learn more about mobile app syncing and integrations with your FileMaker application, please get in touch!