Is there any way how to ‘catch’ exceptions in some workflow step / block, so that long running workflows are possible? E.g. excel service fails to load an excel sheet because of a wrong data in it. Or a data service raise some unexpected error, e.g unique key constraint.
There is a ‘failure’ and ‘finish’ depenendency, but it doesn’t work with exceptions.
My use case is to implement a robust job which has to run N sub workflows for each tenant of system and M sub workflows for each row of the tenant. I don’t want it to be stopped in the middle, I want to ignore errors (log and skip failed rows) and finish the work.
The only way how to work with exception that I am aware of is:
a) process subtasks asynchronously using dedicated WorkQueue class and queue. (my featured way, but it means a lot of work)
b) might be possible to improve services so that they return error messages and don’t throw an exception (rather idea, a lot of rework)
c) call the sub-functionlity via API where it’s implemented as a workflow page. Hack, not sure if it helps, moreover it’s not clear from the doc (Send Request) whether HTTPService fails when the endpoint returns HTTP500
Currently there is no way how to catch exceptions and to decide based on the type of an exception. Ther is only the Failure connnection by which you can handle failures but without actually knowing what failure.
To do it properly I think a deeper thought would be needed.
Without it all the other options you proposed are relevant. The one I like the most is using queues as these
Split the functionality so it is not “long” anymore
Have a good error handling already with errors even persisted in the database
Did you mean start event Failure in WorkflowTaskDependency?
As far as I know the event Failure is triggered when a start rule of dependency source Task failed (returned false).
I was not aware it could catch an unhandled exception in the dependency source Task
Is it really possible to catch an exception and then resume normal operation, e.g. run next task?
How can I distinguish whether the dependency source Task raised an exception or start rule just didn’t pass?
When start rule evaluates false, the task (and any following tasks with Success dependency on that task) won’t run. But any task with a dependency Finish will run. So Finish means success or not executed because of the start rule.
If you want to detect that the task did not run because of the start rule you have to construct a reverse rule, which will substitute else which we do not have.
Now the Failure path executes only when exception is being raised. The whole meaning of this is to support “reverse” in case of a failure. For example if you need to delete any records or send an email if a task fails.
The only issue here is that after the failure path is finished, an exception is raised anyway (re-throwed). So if you compare it to standard exception handling it’s a kind of finally. We don’t really have catch yet.