API: Webhooks Status Return Feature
Hi,
I've been working with some integrations using webhooks and I've missed a way to return a status to the user whenever the webhooks fails. It would be nice to have a way to pop-up a status message in FotoWeb in the event of an error.
-
Thank you for your feedback. There are several things to consider here...
First of all, what is the use case?
If the use case is to detect and act upon technical failures in the workflow, then the status of the webhook is probably more interesting to administrators, rather than regular users running actions. Administrators already have an interface to manage and monitor webhooks, but it requires them to actively look into it, so maybe a notification would be helpful, either in the FotoWare UI or by email or both.
However, there are other ways to detect webhooks failures, which are already possible today, such as by monitoring the receiving application itself. If the receiving application is a cloud service, such as Zapier or Azure Functions, then that service should already have ways to detect, monitor, and alert about failures. For example:
- Zapier can alert about failures in Zaps.
- Azure Functions can be monitored with Application Insights
- A custom application that is written using Microsoft ASP.NET (Core) can be monitored with Microsoft Application Insights
- etc.
If the use case is such that regular users may be interested in the status or result of a webhook, then we would like to hear more details about what you have in mind.
Please also note that webhooks are sent in the background, so an immediate status notification is not possible and would make actions that trigger webhooks take longer, as FotoWare would have to wait for the status to become available. The only way to inform users or administrators about failed webhooks would be via notifications.
-
Hi Florian, the use case is pretty simple. A user selects one or more assets in FotoWeb and click on a custom action which calls a webhook that submits those assets info for a face/object recon service. The service, then saves the metadata from the image/object recon back to the assets. In case of success, a marker is shown to indicates that the asset was processed by recon. The problem is that when it fails, the user does not receive any messages saying why it failed. He knows it failed since the marker does not appear, but the reason of the failure is not reported back. For instance, in some specific case, one of the functions only accepts images with only one face at it. I'd like to report an error saying that the recon service identified more than a face on the pict. There are some other situations, like: "no valid contract found", or "image limit reached", etc...
-
Understood.
A possible solution with the current architecture would be to write the result (and reason for failure) into metadata from within the webhook procedure. Such metadata could then be used, for example, as follows:
1. Show an "error" marker, so users do not try to send these assets to the action again.
2. Have an archive with an auto search, or a smart folder, or a taxonomy item to allow users to search for assets for which processing has failed.
With this approach, a user has to actively search for "failed" assets. However, in an organization, this can be a job done by a dedicated person or team, so that "regular" users do not have to do it, or it can be done once a day, once a week, etc.
If you still want users to be automatically notified, then this can also be done from within the webhook procedure, for example by sending an email to either the user who ran the action, or to a dedicated person, team or mailing list.
A limitation of this approach is that it only works if the webhook procedure is actually called, and the webhook procedure itself detects an error or problem. It cannot be used for operational failures, e.g., if the webhook server cannot be reached, or where the webhook procedure fails with an exception. However, we still think that such failures would be more interesting to IT administrators rather than regular users, and should rather be addressed using the existing tools for monitoring webhooks.
-
Thanks, Florian. This is a good workaround. But it would be great if you could implement a simple API function that would pop-up a message to the end user. This would be a very good way to give the interacting user some feedback. A message/progressbar function would be even better...
Please sign in to leave a comment.
Comments
5 comments