This can (at the moment) only be fired from a sub deployment but the payload contains
“isSubDeployment” :false
It may be a feature of wha tI am posting to but teh message is cut off after a Copy local just in time build to inbox section
The next object is
{“leve”:“info”,"message
Hey John,
The “isSubDeployment”:false is saying that your deployment is only running a single sub-deployment. It is mainly included so that you could branch the handling based on whether you have a single sub-deployment or multiple.
As for the body getting cut off, I have not seen that before and there’s no reason I could think of that OttoFMS would do that. If you get it sent through to OttoFMS webhooks (a match made in heaven for handling the deployment webhooks in FileMaker), I’d be interested to investigate further.
-Kyle
@Kyle
RTFM
Messages are currently limited to 1024 4-byte UTF-8 characters, with a title of up to 250 characters. Supplementary URLs are limited to 512 characters, and URL titles to 100 characters.
That why I needed a test!! In terms of notifications to me I need a lot less data that the webhook sends of course, I can pipe the somewhere else too with the node-red flow.
Wow that is a strict limitation set. I’ll add the test button next go around! I could probably also add a “includeLog” option that will turn off sending the entire deployment log, thats probably most of the data thats pushing you over the limit
-Kyle
That seems like a good idea!! I don’t ‘need’ the log for the purpose of notification only TBF
What I can do is then filter the incoming to only send a notification if it is a ‘completed’ or ‘failed’ one , both have their uses.
Hey John,
OttoFMS 4.10.1 removes the full log from the webhook payload and instead passes a path to get the sub-deployment information from the OttoFMS API. Let me know if there’s anything else you think could be useful in the webhooks!
-Kyle
That sounds like a good move @kduval
The point here is for notification and not necessarily a fuller web view of all the data as the first thing
For long-running deployments or one with lots of sub.sub.sub then I want to know 2 things
did it finish?
did it finish with no errors?
I only need to ‘do’ something about the second, but I might have to let users back in after the first.
I like the idea of sending the link to full log, which could also be an OttoAPI call to get the information??
Yeah the OttoFMS API path we’re sending now is the call that will get you the full log. Its not pre-signed, so presumably you’d need to have an API Key stored wherever the webhook handling is happening, but that seems reasonable