FileMaker Black Box Scripts

"FileMaker Black Box Scripts" is a made up phrase that refers to Scripts that, once compete, can be called in different ways, without having to touch them.

Here is one work in progress example ↴

Calling buttons 1/2

_Called Script 2/2

For those that like lively user group conversations, here is a before and after demo that goes into more detail...
DIGFM: Code Review, ♫ It's Getting Better All the Time ♬ (5/9/2024)

Other use cases?

1 Like

I generally love the idea of black boxes. If we abstract and encapsulate our logic well enough to call it a "black box" then we're probably doing something right!

Every built in FileMaker script step/function is essentially a black box itself, with a friendly interface that we call, and we mostly don't worry about the "how" it does its job. I greatly appreciate when we strive for the same.

1 Like

I've found that "black boxes" can be especially useful as parameterized wrappers around FileMaker script steps that don't expose the calc engine for each option.

Print / Save as PDF

E.g. The Print and Save as PDF steps have various options like "append", and "current record only/current found set", which you cannot toggle programatically. This is a case where I see some value in wrapping the steps so to control them via parameters. All those If/Else things can get complex, and you don't want to rewrite this in every script that needs that flexibility:

Perform Find

Another use case is to encapsulate the plumbing of Perform Find/Constrain/Extend Found Set.

You can write a wrapper that takes a json parameter, resembling the format of what you might pass to the Data API, and then execute the find for you. This is useful in cases where you might have, say, a reusable picker UI card, but you need to perform some different default filtering based on the situation. For example, say you have a Picker that lets you select a Product from a list and users can also search in a field to narrow the results. Maybe in some situations they can search "all products" and in others they can only search "products on this invoice". This dynamic find black box lets you store the filter criteria as JSON, and you can apply the filter as a constrain after a user types a new query in the picker search field.

This script also lets you do stuff like "saved/configurable finds", so different users can have their own "favorites".

Example param:

JSONSetElement ( "{}" ;
	[ "finds[0].requests[0].fields[0].name" ; GetFieldName ( yourField ) ;JSONString ];
	[ "finds[0].requests[0].fields[0].value" ; "Josh" ;JSONString ];
	[ "finds[0].requests[0].omit" ; False ; JSONBoolean ];
	[ "finds[0].type" ; "" ; JSONString ] // constrain, extend, find(default)

Integration-specific HTTP Request scripts

This idea is similar to the ProofGeist HTTP script, BUT DIFFERENT. That script tries to handle all types of requests and in doing so becomes a relatively shallow, unopinionated wrapper around cURL options. I think opinionatedness is what makes these types of black boxes most useful! Most web services have a documented set of error codes/conditions/responses, along with a mostly consistent authorization scheme. You can write a low-level HTTP script specifically for that integration that:

  1. handles authentication, fetching creds(often with elevated privs to access user-restricted fields), refreshing tokens, tracking token age, retrying requests if auth fails due to token expiration
  2. handles known responses. I mentioned expired auth, but there are many other scenarios. E.g. Insert From URL throws an error on 201 (empty body), but that is often used as a success response for PUT/POST operations, so you can gracefully handle the fm error. The possibilities here are many, so I won't list them all.
  3. Translates errors into your consistent error format for your system. Different apis often use different formats for error response bodies (if any)
  4. centralizes logging with any appropriate secrets obfuscation for this particular api.

Once you've implemented this low level script, writing endpoint scripts is often just a couple lines of code wherin you pass the endpoint path and the endpoing-specific curl options needed, like the data your posting or a query string.

We use this pattern a lot:

Here's an example endpoint script. So short! BB: Projects: Delete ( projectId )


There are too many others to list and this post is already a novel!

I spoke to someone who did not like the name "FileMaker Black Box Scripts"

Is there a better name for Scripts that do NOT reference Fields (using Object Names instead)?

  1. FileMaker Context Free Scripts?
  2. FileMaker Object Name Scripts?
  3. Other?

Tony, we just refer to them as ‘generic’. JSON parameters have transformed the way we can build context free scripts


Shadow Script

Sealed Unit describes an item which isn't meant to be opened in the normal course of events.