The recently introduced Stop action has been described as a logic gate for continuing or stopping a WF execution. A similar effect can be achieved with a Filter action (if no item passes the filter the WF halts).
Do these actions have a conceptual and practical overlap? Does one do something that the the other cannot do? In what cases is it recommended to use each of them?
The filter action is all based around an Aqs query and it outputs only the input items matching the Aqs query, thus acting as a filter. If no input item matches the filter then the chain stops, as described in the question.
A stop action is simply built to stop the chain based on its boolean parameter being true or false. The boolean parameter can of course be set through a computation, e.g. a workflow script, otherwise it would be pointless.
Considering this summary, the filter action main purpose is to filter out based on an Aqs query. While the stop action main purpose is to stop a chain based on a computation. The overlap is thus minimal.
Does this answer the question or did I misunderstand what it was about?
1 Like
This explanation is clear for me Nino, thank you. Both can halt the execution, but one does so with an AQS query that produces no output, whereas the other can also halt the query via a computation, which goes beyond what an AQS query can do.
Yeah that is right. The filter however is not only about stopping execution, but also about reducing the number of items that continue down the chain. Something that is not possible to achieve with the Stop action.
1 Like