Claris FileMaker 2024 Platform Version 21.1 – Executive Summary

This is the second release of FileMaker 2024, following up on the initial release in June this year. The internal version is now 21.1 (up from 21.0.2).

As usual, we will not make this an exhaustive list of every single change to the various products on the platform. You can check the release notes of FileMaker Pro, Server and Go for all the details. Rather, here you will find the features we like the most and think will have the biggest impact.

FileMaker Pro

Supported Operating Systems and Compatible Version of FileMaker Server

Besides the obvious support for macOS 15 Sequoia, the only change is that macOS 12 Monterey is no longer supported. You will now need macOS 13 Ventura or up to run your FileMaker Pro on Apple hardware. No changes on Windows (Windows 10/11).

To connect to a FileMaker Server, that server needs to be on version 19.4.2 or up. No change here, either.

Keep in mind, however, that support for 19.4 and 19.5 has already ended in December 2023 and June 2024, respectively. Ideally, you and your clients are not still using those versions.  Still supported are 19.6 (until December 2024) and 20.2 (aka version 2023, until April 2025).

Staying within support parameters is a strong reason to plan out these updates. Normally, each version expires two years after it is launched.

AI

The AI features that were introduced with 20.1 are receiving some updates.

Cohere has been added as a provider for embeddings, next to OpenAI and Custom (when you want to run the Large Language Model (LLM) locally).

In addition, you can now create embeddings on images (instead of just text). There are no new script steps and functions for this; it works with the existing ones. The Open Source model that ships with FileMaker Server (when you want to run LLM locally) has been updated to create embeddings on images. There is a new Save Result option for the Perform Semantic Find script step: it saves the resulting cosine similarity in JSON format.

The result that is saved is an array of record information for the found set of similar records; it contains the record id and the cosine similarity score:

With this data, you can easily rebuild the found set without having to run the semantic search again.

The Get(LastStepTokensUsed) function now works with local LLM (aka ‘open source’) provider. Tokens are the unit of measure for calls made to an AI provider, and you usually get billed based on tokens. In the simplest form, tokens are pieces of words. Tokens can apply to the input and the output, so the longer either of those is, the more tokens you consume.

Why we like this: often, you will want to prototype your AI functionality against a local LLM so that you do not run a bill as you are experimenting. If and when you want to consider using a commercial AI provider like OpenAI or Cohere, you will now be better armed with information about how many tokens your functionality uses, and you will be able to more accurately predict your costs.

New Defaults for Script Steps

Many script steps had default settings that we would change immediately. A good example is the Exit After Last step. The default was off, and that typically wasn’t the behavior we would want for this step. This step now defaults to on. There are about a dozen or so script steps with new default options.

Why we like it: it will save us time. In the short term, though, we may have to develop some new muscle reflexes and be a little more diligent when using these script steps. Nonetheless, we’re very happy to see these default behaviors updated to match the normal use cases. For an in-depth look at all the affected script steps, see this blog post.

Open Quickly

This feature got a big update in the last version (20.1), and some of it was slightly contentious since it sometimes revealed more to the user than the developer had intended.

In version 21.1, we see some useful refinements, including the ability to control some of this feature’s behavior from the user’s privilege set. For a full rundown of what is new, see this blog post.

Why we like it: as developers, we get more fine-grained control over the behavior. My personal favorite is the ability to search the relationship graph.

ExecuteSQLe()

This new function is a sibling to the ExecuteSQL() function we’ve had since FileMaker 12. This one, however, outputs a meaningful human-readable error if the SQL call fails instead of merely “?”.

More details are here.

Why we like it: troubleshooting these SQL calls is now a lot simpler, and refactoring existing code to use this new function is not too onerous.

Server-side Perform Script on Server

When you ask FileMaker Server to execute a script, either through a schedule or by using the Perform Script on Server (PSoS) script step, then that script could not use PSoS itself to spawn another server-side session. That limitation is now lifted.

As the saying goes, with great power comes great responsibility. It now becomes riskier to overload your server with runaway PSoS sessions, so tread carefully.

Why we like it: mainly because of the OData API. That API uses the fmse script engine, one of the three script engines available on the server. The other two are the dapi engine used by the Data API and the wpe engine used by WebDirect and the older XML API. Both of those engines could already use PSoS. The OData API uses the same script engine as schedules and PSoS itself and can now leverage PSoS.

This allows for an architecture, for instance, that allows any script called through the OData API to return a quick response to the caller (the equivalent of an HTTP response of 201 – Created or 202 – Accepted) and end the call after handing off the long-running process to a PSoS session with the “don’t wait” option. This is a design pattern that we could already use with the Data API but not with the OData API.

Fewer Folders for Secure Remote Container Data

This refinement affects performance. On the premise that all bigger FileMaker apps are hosted on FileMaker Server, it will affect the server’s performance more than the FileMaker Pro or Go client’s performance.

When you define your container field on the Storage tab, you have a new option available (off by default) when you choose Secure storage for data.

The performance impact comes from how operating systems deal with lots of files and subfolders in a single folder. Using this option can make saving and retrieving container data faster.

However, this option is not backward compatible, and you need to make sure that all your users are on version 21 of FileMaker Pro and Go:

Inserting the same 44MB file into a container set up old-style (red) vs. new-style (green) shows the following difference in folder structure:

Why we like it: Who doesn’t want more performance?

Constraining the found set faster

The Constrain Found Set script step has a new option to perform that constrain operation without involving the indexes of the table that you are reducing the found set for.

That sounds counterintuitive because using the index is supposed to be the fastest way to perform queries.

You are most likely to encounter a situation where this new option can be useful, when the total record count of the table you’re doing the constrained find on is big (more than a million records), and the found set right before the constrain is very small (say a dozen records). Using the new Constrain Found Set script step option is beneficial in these scenarios as it allows for a more efficient refinement of the smaller subset of records. This efficiency is achieved by bypassing the need to traverse indexes. Remember that when FileMaker creates an index, it includes every record in the table that contains a value for that field.  Consulting that index and scanning through it takes a certain amount of time, which may be more time than actually scanning through the initial found set that needs to be constrained.  Scanning a dozen records may be faster than scanning the index of a million records.

Previous methods of avoiding indexes in such scenarios included removing indexing on the queried fields or creating unstored calculation fields (those are never indexed) and then querying these unstored calculation fields, thereby skipping field indexes.

In our tests, the performance difference was not noticeable in most cases, but in some, Find Without Indexes sped up the Constrain Found Set step by more than 150 times.

Why we like it: any setting that helps us tweak performance is more than welcome.  But: test before using this; do not just assume that things will be faster.

Deleting the Classic Theme

Repeat after me: the Classic theme is evil.

It’s been known to cause many issues, and we try to find the time to remove it from all projects that we are asked to work on.

Annoyingly, even when you rework all the layouts to use another theme, the theme itself remained in the file. Because of that, there is always the risk that a new layout will be created using the Classic theme.

Now, you can delete the theme from the file when there are no remaining layouts that use it. If you try to delete it when there are still layouts in that theme, you will get an error:

Why we like it: good riddance.

Set the Client Cache in the Assisted Installer

With the Assisted Installer file, you can preset certain configurations for the FileMaker Pro clients. It can control settings such as prohibiting the creation of new FileMaker files, disabling the advanced tools, automatically launching your app when FileMaker Pro starts, disabling the use of plugins, and so on.

One new setting has been added in 21.1: setting the size of the local cache, which is the equivalent of this setting in FileMaker Pro’s preferences:

Why we like it: the Assisted Installer is a powerful tool to automate installing FileMaker Pro with consistent settings across many users. This adds to the usefulness of this tool.

More Control Over the Validation Message

When you set validation rules on a field, you can also add a message that will be shown to the user if they enter data that fails that validation. However, it was a hard-coded message. That now changes to a calculation.

FileMaker 20.2 and earlier

FileMaker 21.1

Why we like it: the validation failure message can now be crafted to be more meaningful to context, have different languages for different users, or have variations depending on the user’s role. Having said that, one consideration we will always make is whether we want to bury that logic at the field level. We can achieve the same result by using a scripted workflow with a card window or a custom dialog.

FileMaker Server

Supported Operating Systems and Client Versions

The only major change is that macOS 12 Monterey is no longer supported. You will now require macOS 13 Ventura or up to run your FileMaker Server on Apple hardware. No changes on Windows (Windows Server 2019 and 2022) and no changes on Linux (Ubuntu 20 or 22). We are somewhat surprised that there is no support yet for Ubuntu 24.

To connect to your FileMaker Server, Pro and Go clients will need to be on version 19.4.2 or up. No change here, either.

No More Data API Allotment

Metering and limiting the amount of data that you were allowed to retrieve through the Data API based on the number of licensed users has been a sore point since it was introduced. This limitation has now been removed. The same applies, of course, to the OData API.

While the allotment was generous, and we rarely came across projects where it got in the way, not having to worry about it makes for a smoother adoption path. If, however, you were in a scenario where you were exceeding the allotment, then we would encourage you to scrutinize the architecture and look for opportunities to cache the data requested from FileMaker Server. The use cases that we have seen that would push the Data and OData usage close to the old allotment limit, were use case where the same data was retrieved from FileMaker Server repeatedly and where caching that data would solve the issue and very likely also speed up operations. Talk to us.

HTTP Tunneling

The ability to have FileMaker Pro and Go clients connects on port 443 instead of the proprietary port 5003 was introduced a while ago, but it was limited to deployments that used Linux for FileMaker Server. This feature now comes to FileMaker Servers deployed on Windows and macOS.

Note, however, that this requires using Nginx as the web server, which is not very common on Windows and requires a manual installation of Nginx before installing FileMaker Server.

Why do we like it: it makes usage of the FileMaker platform easier in environments where IT does not want to open a port for FileMaker. By using the standard HTTPS port, that problem goes away.

Concurrent Backup Schedules

You can now run multiple backup schedules at the same time.

Why we like it: sometimes, one FileMaker Server hosts different apps for a variety of departments and workgroups. By segregating these into their own folders, you can assign sub-admin roles for each folder, for instance. Backup schedules can also easily target a folder of files, so now you can set up backup schedules for each different set of files without having to worry about the timing of these backups in relation to other backups.

This assumes, of course, that your server hardware has the spare capacity in processing power and disk i/o to allow for these concurrent backups to happen without affecting overall performance.

Only Open Files That Were Previously Hosted

By default, FileMaker Server is set to auto-host all available files at startup. You now have an additional toggle (off by default) that tells FileMaker Server to only host the files that were hosted when the server shut down.

For a more detailed breakdown of this feature, including how to use the Admin CLI and API to configure it, and information on how this feature behaves when you close and pause files, see this blog post.

Why we like it: sometimes, you want to have some file readily available on your server but not actively hosted — perhaps on an older copy of your solution. This new feature makes it easier to manage that without fear of accidentally making those files available to users at the next startup.

But: it’s a feature tied to the auto-host feature, and the long-standing best practice is to turn that feature off to avoid re-hosting files that were not closed properly on the last shutdown.

We still stand behind this best practice, and if you follow it then this new feature is of limited use.

Updating Java

Java is used heavily by Claris FileMaker WebDirect, and installing it and updating it has always been a bit of a dark art. We wrote previously about the two main methods to install Java for use by FileMaker Server. The first important change is that the Admin Console now displays the version of the Java SDK or JRE that is being used:

As a side note: there is very little reason to run anything but a version of the JDK since that unlocks the ability to run Garbage Collection and free up unused memory on your main server or WebDirect worker servers.

Another new feature is that you can replace or update the Java version easily from the Admin Console if you run FileMaker Server on macOS or Windows:

Starting the process will warn you that all WebDirect clients will be disconnected and that the web publishing engine will be restarted. The rest of the process is exactly like the initial installation of Java through the Admin Console.

Why we like it: this is an easy way to switch from the Java JRE to the JDK if Server was initially installed with the JRE and you want to have the Garbage Collection feature. It also facilitates updates.

Note: this option is not available on Ubuntu since FileMaker Server automatically installs Java system-wide, and updates can be done through normal channels. The same applies if you have used the JAVA_HOME feature to point FileMaker Server on Windows and macOS to use the version of Java installed at the operating system level. For details, see the blog post about the two ways to install Java.

Data API

As mentioned earlier, the single biggest change is that there is no more data metering for any data you consume through the Data API.

In the Admin Console dashboard, where you would previously see how much data you had consumed, you can now see how many Data API connections your server currently processes.

A small but neat addition is that the Admin Console will now display the link to the online Data API help when you enable the API:

There is one optional behavior change to the API calls themselves, specifically when you want to modify a field that has this setting toggled on:

Before FileMaker 21, any calls to the Data API would respect this setting. In this new version, you can control it during the call with a new options > prohibitmode element in the data API payload.

If the Prohibit modification setting on the field definition is toggled on, then the Data API call to modify the field will fail if the new options element is not there or if it is set to user. Both of these are the default legacy behavior.

If you set the prohibit mode option to script then the field is modifiable, overriding the field definition setting. That is the same behavior when a script touches the field instead of the user directly interacting with the field.

Why we like it: more granular control during an API is always better. For instance, we can now have fields that the user using FileMaker Pro and Go cannot update, but the Data API can. Granted, some of this can be controlled at the privilege set level, but the extra option at the field level is a nice addition.

Data API Client Count in the Admin Console Dashboard Update

In FileMaker 21.1, the Data API/OData annual limit section in the admin console dashboard has been replaced with just the Data API connection count.

The number of Data API connections was already available in:

• As a performance counter on Windows through the “FileMaker Data API Clients” counter

• In the Admin API, by filtering the clients by appType when listing clients /clients → $.response.clients[*].appType
• Indirectly available in the admin console clients list (“Databases” tab) where “Client” is “Data API”

The Logs/Stats.log file still does not contain a dedicated column for Data API clients. Its current client counters are:

• Pro Clients
• ODBC/JDBC Clients
• WebDirect Clients
• Custom Web Clients
• Go Clients

OData API

Here, too, the metering is abolished, which should see OData implementations get more traction.

Furthermore, the FileMaker OData API supports more of the OData 4.01 standard features:

• Parameter aliases
• Nested queries in $select, $expand and $crossjoin queries
• Type casting between different data types (string to int, etc…)

When you use OData to do batch updates, which is one of the great features of the OData API, the preference headers can now be set at the batch level and will be inherited by each request in your batch.

And unlike the Data API, which has its own script engine on the server, the OData API uses the fmse script engine. That is the same engine used by server-side schedules and Perform Script on Server (PSoS). That means that it also benefits from the PSoS-in-PSoS feature that we talked about earlier. A common design pattern where this fits is when you call a script through the OData API, but you do not want the API call to wait on the result of the script. Your script called through the API can now use PSoS-no-wait to do this. This is something that we could do only through the Data API up to now because the data API script engine already supported PSoS.

Why we like it: no metering, better support for the OData standard, and the ability to hand OData script calls off to a different session make the OData API a very strong candidate for work that we usually would consider the Data API for.

Admin Console

Some of the changes to the Admin Console were already mentioned:

• A new link to the Data API documentation
• Information on the installed version of Java and the ability to replace the Java version
• A new feature to configure FileMaker Server to only open the files that were open at the last shutdown

There are two more significant ones.

Email notifications: these can now include warning events, too. Before, these were limited to only errors.

Note, however: we highly recommend using a proper monitoring platform for your server though. These offer a lot more fine-grained monitoring, notification, and escalation features. (talk to us).

From the Admin Console, you can now filter to see files in any of the folders, additional folders, or subfolders that you have created:

When you have a particular folder selected, you can also create and delete (empty) folders.

Admin API

The admin API supports the new features that are introduced, like the ability to toggle the Host only previously hosted files.  Also supported is managing HTTP Tunneling and importing an SSL certificate, which can now be done as a multipart/formdata call. This saves you from having to first encode the line breaks in the certificate files.

Launch 21.1 Features in Your Application

Our team of FileMaker experts can help you leverage these new platform features for your application. Contact our team to talk with a consultant and learn more about how we can support the goals of your FileMaker solution and organization as a whole.