ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Goldhammer <Goldhammer.J...@gmx.net>
Subject Re: Error handling in bpel processes
Date Tue, 02 Oct 2007 18:31:09 GMT



Alex Boisvert wrote:
> 
> On 10/2/07, Jens Goldhammer <Goldhammer.Jens@gmx.net> wrote:
>>
>> I know there were discussions about faultHandlers, but I have not found
>> the
>> solution for my problem.
>> In my bpel-process I try to invoke several webservices. If a webservices
>> has
>> an internal error, it throws a defined error back to the bpel process. I
>> want to handle it by a local fault handler.
>>
>> Instead of replying with the message catch log Failure, ode invokes
>> nothing
>> and the process will not be terminated. The instance is still active!
>> (invoked the instancemanagement-api)
>>
>>
> 
> Hi Jens,
> 
> Please read the Activity Failure and
> Recovery<http://ode.apache.org/bpel-extensions.html#BPELExtensions-ActivityFailureandRecovery>section
> of our documentation.  From a process design standpoint,
> 
> 
>    - You should declare any business exceptions in your WSDL as faults.
>    These are always thrown as-is in the process.
> 
> 
>    - Technical failures [1] suspend the invoke activity (by default)
>    after a configurable number of retries and retry delay.  Once
> suspended, the
>    invoke requires explicit attention to retry, cancel, or skip the
> activity
>    (via the PM-API).   You have to explicitly set the "faultOnFailure"
>    attribute to "true" in order to react to a failure, in which case you
> should
>    be catching the "*ext:activityFailure" fault [2], or use a catchAll.*
> 
> alex
> 
> [1] Anything that goes wrong, including SOAP Faults not described in the
> WSDL, HostNotFound, ServiceNotAvailable, OutOfConnections, etc.
> 
> [2] Namespace URI is "http://ode.apache.org/activityRecovery"
> 
> 

Hello Alex,

thanks for your explainations. I have read the documentation already and
understand the differences between business faults which are thrown by the
services itself and ode faults which are thrown if technical errors occur.

I believe in my case that Axis2 cannot acces the fault which the service
responses to ODE back. Here the initial business fault become an ODE fault
and behave as you have described already.
Or does the stacktrace below has an other meaning?

org.apache.axis2.AxisFault: LogFaultException
        at
org.apache.axis2.util.Utils.getInboundFaultFromMessageContext(Utils.java:486)
        at
org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:343)
        at
org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:389)
        at
org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:211)
        at
org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
        at
org.apache.ode.axis2.ExternalService$1$1.call(ExternalService.java:148)
        at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
        at java.util.concurrent.FutureTask.run(FutureTask.java:123)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
        at java.lang.Thread.run(Thread.java:595) 

Thanks for your help.
Regards,
Jens

-- 
View this message in context: http://www.nabble.com/Error-handling-in-bpel-processes-tf4555881.html#a13004733
Sent from the Apache Ode User mailing list archive at Nabble.com.


Mime
View raw message