Context
We use the rest api to call an “aggregation WF”.
Issue
The WF which triggers the api call is an App Endpoint. It possibly gets executed frequently.
Question
Can i put a “debounce” on the rest call, or somehow the WF itself, such that the aggregation executes max. every 30seconds?
(Image shows the aggregation-rest-call in the endpoint WF)
I don’t know how to make a WF wait, in case it was triggered recently.
But maybe the disable feature of the Apps Execute Button might help to solve your problem anyway (assuming that the frequent triggers are caused by the same user, not by many different).
If that does not fit your use case, I can imagine a very hacky solution with a PL that checks in a first step, how old the latest job is. But you will definitely lose some seconds there
Is it possible to migrate the WF into a Function?
The WF approach to me seems a bit overkill for triggering another WF. That’s actually what Functions should provide. Inside a function, it is possible (but not recommended) to store the last execution/trigger time (last call to the function) in a global variable (note that this only works as long as there is no scale-out via function replication and load balancing in place (currently not implemented)).
Another approach would be to fetch the last execution time via API upfront in your function and deciding according to the response there. Adds a bit to the RTT but imho is the cleanest solution.
If you want to stick to the “WF calls WF” solution instead of the “Function calls WF” solution that Flogge suggested you could create a new table with one timestamp column “latest_execution” or similar. In your workflow you could then load this table and if the maximum timestamp in the “latest_execution” column is more than 30 seconds in the past, you could append the current timestamp as “latest_execution” to the table and trigger your aggregation WF. If the latest execution was less than 30 seconds in the past, you could just do nothing.
@jakob.franz your solution might work when triggering the WF execution in the REST call processor is quick. If it is a blocking operation, we might have the situation, that the append is not performed before the rest of the WF has completed. During this timespan, subsequently triggered WF executions would still read the “old” timestamp max and therefore trigger execution of the called WF, too.
However, if this approach (for some reason) needs to be taken, combine it with the isolation group feature (see Isolation-Groups : ONE Service Desk & Manual) to make sure that execution of the calling WF is blocked and lets a previos job of itself finish first. Thinking of it, if the executioon of the called WF is blocking (executed as microservice), then adding the calling WF to an arbitrary isolation group only containing itself might already suffice if you just want to prevent parallel executions of the called WF. If you rather want “to do explicitly nothing” before a certain time interval has passed between executions, it will need some decision logic, too.
Still, my go-to would be a Function for such conditional logic.
I didn’t fully understand the use-case, but you might exploit the soon-to-be-released feature “event-based scheduler”. It explicitly has a debounce parameter.
It allows you to trigger a WF execution off of an update to a datatable. Spoiler: Functions are not supported
edit: the feature is already available on internal, if you want to test it. It’s “hidden” in the scheduler dialogue
