BPM: Error Handling for Script Tasks

[hi-ko]

How could I handle runtime errors in Script Tasks? processes seem to always end silently if something goes wrong.
In the following workflow I already registered an "Error Intermediate Event" in a multi-instance-subprocess but that seems not to catch. On error in a script the the sub-process instance just ends and calls the next iteration.
In case the "store review results" script task fails I only see the error in the log

 ERROR: Process 641ae04776bb85c25 formula error: Formula bpm\createdEntity\attribute: Bad argument [] []

When I view the process instance in the browser (/#BpmnProcess/view/) I only see the workflow definitions but I would expect to see the instance values/variables.
It would be nice to be able to even edit the instance properties as admin to fix hanging processes.

[yuri]

Hi,

You need to catch the error in a particular activity. See the screenshot.

[hi-ko]

Yes, that would be more intuitive. I couldn't find any specifics in the [BPMN 2.0 specs](https://www.omg.org/spec/BPMN/2.0/PDF) for exception and compensation handling except it should be covered. It's more or less a common understanding of transaction handling: a transaction (task, subprocess) should always fail/roll back on error unless the exception has been catched. Any external calls need to implement a compensation.
Translated to a task: a task should not complete on error but throw an exception. This could mean that in the UI a user gets a message on submit with an error reference so an admin could analyse that error later and / or the user may reopen that task later once the issue is fixed (e.g. the called web resource is available again).

[hi-ko]

Transactional sub-processes may be an overkill with PHP but I would need something like an exception object to implement any error handling and notification. Maybe I just don't see how to do it? The only context I get in the Error Intermediate Event is that an error occurred since it took this path but not the error itself.

[hi-ko]

An idea on how to get around the transaction restriction: If we could add a post script in a user task definition (instead of a separate script task) we could run that script once the user submits the task. If that post script sets something like a failure flag and a failure note or if one of the script calls fails the user should get a failure note.

[yuri]

You can find current process variables in the browser console > network, when you open the process.



Or just open the URL https://your_espo_url/api/v1/BpmnProcess/{process_id}

[hi-ko]

cool. That was the missing bit. Very valuable input!
Now the flow uses the expected path.
I'm used to have an behavior the other way around: an exception would be always thrown and also roll back the task (transaction) unless catched. So in Espo workflows and bpmn tasks admins should add an "Error Intermediate Event (Boundary)" potentionally on any task.
So maybe in future it would be better to extend a bpmn task with a submit script which will run before a task completes and which will also have an exception handler.

How can I access the exception to e.g. run some compensation action and/or put the output into an error mail template to the admin? I can't find anything related to the error from the process REST endpoint or in the database.

The tip with the REST endpoint is also helpful. Now I see that you don't store the outcome of an completed task. So It would be quite helpful to get that result anyhow to debug failing processes.

[yuri]

As I mentioned before, I will likely add propagation of un-caught errors. Though the specs is not specific on it, I see that other implementations do it.

[yuri]

REST API error response codes (Task > Send HTTP Request) can be caught by boundary error events (with specific error codes).

[hi-ko]

I understood the Error Code more like a filter. I would like to read the error event including the error itself. Either for a failed http call or an internal script call.

[yuri]

> Now I see that you don't store the outcome of an completed task.

I don't understand what do you mean by 'outcome'.

[yuri]

Result variables for sub-processes are available by another ID (the same endpoint, but sub-process ID).

[hi-ko]

with outcome I meant the return from the task execution which may be empty on success or contains the exception.
e.g.
[{"ERROR",{"Process": "641ae04776bb85c25", "formula error: Formula bpm\createdEntity\attribute: Bad argument [] []"}]

[yuri]

BTW what do you think about Compensation activities? They are part of the standard that we didn't implement. Would you use them? We didn't receive any requests on them. Their purpose is the ability to revert (by defining explicit actions in the compensation activity) specific completed activities. In the case of not using transaction sub-processes, they can be triggered only by Compensation throw events.

[rabii]

I was not aware of the compensation activities, after reading about it. they seems useful especially when you want to undo what you have done at the beginning of the flowchart. As i understand you can use compensation event to trigger a compensation activity.
From your perspective you think they are easy to implement ? if yes then i think they might come handy.

Thanks

[hi-ko]

compensation activities are usually required for distributed systems / external calls. In your case they could be a workaround for missing transactions (in some use cases). We are still in the experimental phase with Espo's BPM and don't use (yet) modifying calls to external systems. However, before we think about compensation activities, exception handling (with full exception objects) would be more important. These would be necessary for compensations anyway.
We also use "real" BPMN engines (Java). However, we also appreciate the advantages of Espo and your BPM concept (clean, extensible entity model, pre-integrated workflow model, low-code approach). At least I see it pragmatically

[yuri]

Compensations are necessary part of transactional sub-processes in BPMN. Technically the only difference between the regular sub-process and transactional is that the latter supports cancel events. It's quite small difference which could be achieved by using error events instead had we implemented compensations. Database transactions has nothing to do with BPMN transaction sub-processes as far as I know.

[yuri]

I'll add the ability to view a caught error code and message in the Flow Log, for the Error Catch Event and Error Start Event.

[yuri]

Not sure whether we need passing the whole exception object (serialized). It could be accessed only with PHP, but PHP is not available in the BPM.

[yuri]

Regarding accessing caught error data further in the flow (with formula), I'll investigate.

[hi-ko]

sounds promissing - thanks!

[yuri]

I'll also add activity compensation support in the next version. I don't know any other CRM or ERP with such an extend of BPMN standard implementation. And it's impossible to find us in Google by relevant requests.

[hi-ko]

I'll write a blog post to change that ;-)
The combination of automation (espocrm wording: workflow), http hooks and BPM (preintegrated with entities) is quite a promissing toolset
Thanks!

[yuri]

That would be great. Thank you.

[item]

I will not "interrupt" your conversation/ehancement ..

Yuri have make a incredible tools !
hi-ko thanks for the blog.. i am waiting the link

[yuri]

Compensations and error handling improvement in the new v2.14 release. https://forum.espocrm.com/forum/exte...age5#post86498

[rabii]

thanks
will try the new feature.

[hi-ko]

Very cool - thank you!
will also try asap ...