I want to return a error 503 “Service Unavailable” to all calls to BF including API calls whilst we migrate to the new FileMaker Server .
Can we do this in the BF site (that would be really cool)
If not, in which script should we set the header and reject the call?
Thanks
Returning errors can be a bit trick, since you want to return them from the script that is in the server being migrated.
But, what you can do,
cd
Will this approach work for BF API calls as well?
It would be really great if we could initiate to show the modal by specifying something in the Site data.
The API calls do not hit the web rendering engine so you would instead return a status code or response as you mentioned earlier.
This too can be set in the global hooks.
Charles, thanks for this. How do we prevent to actual API and Hook scripts from continuing after setting a return header or redirecting in the global before script?
Well, it is FileMaker, so in the apiCallback script check for your pref flag and handle there.
Charles, I’m just trying to establish where in the BF FileMaker script stack it is best to shortcut the process so we effectively don’t run any of the FileMaker processes that actually do stuff in the database. I’d like to be able to have a single point in the script chain the turn BF pages and API off for maintenance.
Also, I’m hoping to get best practice guidance from you for the benefit of all BF users.
Ideally, I’d like to turn off for maintenance by editing a single script for both regular BF and API access.
For regular BF UI hooks in the global before you can inject actions and also that same flag can be used to bypass all other hooks in the receiver script by editing the hookssetName
If you want to also return specific API headers and status codes, then you can do the same in the apiCallback hook.
If you inspect what the receiver script does, you can see its simply just dispatching based on vars$
We have just encountered another closely related scenario. How to return a useful error when the FileMaker Server is offline?
This would occur when a FileMaker Server or OS update is being installed or the server is being restarted for any other reason.
It would be incredibly useful to define an error to be returned in the BF environment.
Thanks
To better understand,
You would like an indicator within the BF editor that shows your FMS is offline?
The example of an update would mean you would already know, but I could see for unintended outages ( FMS failure etc )
Or, are you referring to an error page within the app?
If the FileMaker Server is unavailable for any reason, I want to be able to specify the error shown to a human user of the BF App AND the error code returned to an API user.
This is really important for the API user to avoid critical submissions being lost (I don’t have control over the API client)
I’ve been thinking about this topic as well lately. I was wondering if we can get an error returned by a runUtilityHook action when the hook failed. I’m already running a utility hook onAppLoad, so that would allow me to “detect” that FMS is unavailable and do some custom action like show a modal with a link to a status page. I’ve been thinking of setting up a service like https://status.fmbetterforms.com/ for our own apps and this would allow our users to directly access that and get updates when service interruptions are resolved.
Regarding the API, I would think a 5XX http status code should automatically be returned if FMS is unavailable.
These are some good ideas @dansmith65.
I think a catch-all error global error hook, something like onSystemError that can be used to trap fatal errors may be a good idea.
The idea solution is something that allows a dev to not have to do anything and the framework handles errors in a way that works for 95% of use cases, yet it allows full customization easily.
There are many types of errors that can happen and how they are handled. I think next steps is to document all of these and then plan base-code changes for them.
This week we have begun to plot out base-code optimizations and our devs are starting to turn their attention to the base code.
@earamizu and I will document this thread for later visits.
On this note, is there a way to outright disable a BF app/env within the betterforms editor? If I know I am going to be performing major maintenance or upgrading of a server, turning off the app at the client end would seem like the simplest solution rather than returning an error based off a failed server call.
There is not a direct way, but, we would like to hear how you think this could be added into the editor and framework.
In the interim, if the app has a single entrance page, you can simply create a new “Under maintenance” page and add that slugs id to the landing page. Since there is no onFormRequest, it will not error.