nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Catching Web Service Task exceptions

perpetuum_mobil

Hello!
Is it possible to catch exceptions thrown by web service task?
My Web service defined in web service task may throw exceptions. And I want to catch them in the process and change the flow of process respectively.
From the userguide and forum I found out several ways to catch java exceptions thrown by java service task. But they are not suitable for web service task.
I tried to throw BpmnError from my web service and catch it in my process but execution of the process stopped by reason of my WS exception.
The only solution I see is to return from WS a spesial type containing WS result (if exists), error code and error messge (in case of exception). And then precess these results in script task.
Is there any other solution?

Find more posts tagged with

Comments

perpetuum_mobil

I want to add one more question..
How to catch exceptions in these situations:
1. I run process when my WS is down
2. I run process with WS task caling web-method, which no more exists in my WS
3. I run process with WS task with invalid parameter names/types

Activiti throws exceptions in these cases. These are cxf or activity exceptions.
I want to handle them in my process and continue process execution if any one occures.
Is it possible?

frederikherema1

The error thrown in a web service is wrapped in an ActivitiException and thrown to the calling thread of the API-method that caused the process to move on and execute the WS-task (e.g.. the thread that calls startProcessInstance(..) or completeTask(..)). By doing this, the exception forces the transaction to be rolled back, so at this point, you cannot have the process "solve" the problem by moving to a different step in the process.

BPMN and activiti have support for LOGICAL error-handling, an WS-call failing is considered to be a technical error, forcing a rollback regardless of the circumstances.

If you really want to threat the WS-call failure as a logical error (which you can handle in your process without having the transaction rolled back) you need to extend the web service-task -or use a custom JavaDelegate on a serviceTask- that executes the WS-call in a try-catch block and throws a new BPMNError() instead of the original exception. This way, the error-handling in activiti will handle the BPMNError appropriately.

pmsevestre

Hi,

Just a few thought on this subject based on my (short) experience with Activiti:

Recovering from system errors tend to be a recurring issue, specially when dealing with tasks that deal with external systems (eg: email, webservices, external commands, etc). I usually set the async flag on those tasks so, in case of a transient failure, I can retry the implicit job that the engine schedules to handle a given async task.

Maybe this error handling pattern could be made easier to implement by allowing one to define a global error recovery strategy at engine level. Such strategy would receive a DelegateExecution and a Throwable and return a value that instructs what how the engine should proceed. Something like:

DEFAULT - Do whatever the command chain is supposed to do (eg: rollback)
IGNORE - Ignore the error and pretend the execution was ok (useful during development)
ROLLBACK_AND_RETRY_NOW - Side effects can be an issue here…
ROLLBACK_AND_RETRY_LATER -Pretty much what happens when an async task fails, but the handler should have a way to inform when the retry should happen.

In order to avoid an infinite retry loop, local variables containing the number of failed attempts and the date of the last one should be made available to the recovery handler. In any case, the engine should have additional default settings to handle more-or-less gracefully double fault scenarios (eg: an exception in the error handler).

jbarrez

I like that idea. It's something we had in jBPM 3 too.

It does gets messy somehow with transactions.

cdeneux

Hi all,

I have the same problematic with Activiti 5.21.0. I have a web-service that can return custom faults (faults defined in its WSDL). Another faults can be thrown at the WS client stack.
In my mind, the custom faults could be associated to business error.

According to the source code of Activiti 5.22.0-SNAPSHOT (last commit: 8b914a1e3d597251b4ab6aecbb1d4ba008dddd48):

the WS client stack used is CXF,
exceptions associated to the fault are catched into org.activiti.engine.impl.webservice.WSOperation.safeSend(…),
and are just logged, without to be re-thrown

@frederikheremans, is your comment always valid with Activiti 5.22.0-SNAPSHOT ?

To add support of faults, I propose to you to create a contribution where:

I don't think that it is possible to sort business faults et technical faults, that why all faults will be thrown as BpmnError, in this way all faults will be catchable through an error boundary event,
the error code of the error boundary event will be set with the qualified name of the exception class associated to the fault

What do you think about that ?

Regards,
Christophe

cdeneux

Hi all,

I have just submitted the pull-request #1011 (https://github.com/Activiti/Activiti/pull/1011) that add fault management support to the web-service implementation of service-task

csharma

Is there a way to convert java exception to BPMNError . Tried to search but did not find any useful information

Not sure if this would have been a different question but felt it is related.

Thanks