OttoFMS version 4.14.0 was just released! This version includes a UI for the FileMaker Server Triggers that @john_r presented on at EngageU, as well as a number of bug fixes and small improvements. Check out the full changelog here.
This version also upgrades OttoFMS from Node version 20 to Node version 22, and as such there may be some issues on install. We have tested on the major supported operating systems, but unusual environments may cause an issue. Let us know if the install doesn’t work for you, and for now downgrading back to 4.13.1 should let you keep using OttoFMS with no issues.
Thank you, and let us know if you have any issue with the new version!
Thanks @kduval
There is likely to be a Server update soon which will bring these out into the open.
For those who want more detail on this, I am presenting at FMDiSC in December 12th and this will be a part (along with some advanced OData stuff)
I have tried setting up a trigger and I know my receiver endpoint is working fine, but no data is sent when I make changes to data or schema. Any ideas? OData and Data API are enabled, and the connection is successful when setting up the trigger…
Are you missing an authentication header or something similar? I’m not clear on how much logging there is for this feature or how easy debugging it is, @john_r may have some thoughts there. This may be worth opening a new thread on for discussion.
For testing I just left the endpoint open with no auth… tested sending to it in Postman and it just does one thing… create a record in Supabase and populate a field with the payload received… and that works fine… so no particular headers needed from what I can see… Would be great to see a log of triggers payloads sent, at least maybe the last ten as that log would get huge pretty quick I reckon!
Agreed! OttoFMS is just showing you UI for information FileMaker is storing, so we can’t add anything like that unfortunately. Any feature requests for the actual functionality of the triggers would need to go to Claris. We’ve just built the UI to work with them rather than having to use the API yourself.
The $filter needs something to tell the record under what conditions to fire the web-hook though surely.
thisField changes status, thisField is more than zero, these fields etc etc, or ROWMODID > 0 == anything changes
But having something that fires off on each an every change to every record in a mulit-user system is going to fal over at some point. Start small.