Hi Michael,
The type of fault/failure you get is important. Ode distinguishes between
fault that are declared in your WSDL definition (e.g. business-level faults)
versus other failure conditions that can arise such as transport-layer
problems. By default, Ode suspends the <invoke> activity if it encounters
an unexpected failure. The rational is to shield the process from transient
errors and allow the process to resume at a later time.
You may override the default behavior by using this extension:
<ext:failureHandling xmlns:ext="http://ode.apache.org/activityRecovery";>
<ext:faultOnFailure> *boolean* </ext:faultOnFailure>
<ext:retryFor> *integer* </ext:retryFor>
<ext:retryDelay> *integer* </ext:retryDelay>
</ext:failureHandling>
The faultOnFailure, retryFor and retryDelay elements are optional. The
default values are false for faultOnFailure, and zero for retryFor and
retryDelay. An activity that does not specify failure handling using this
extensibility element, inherits the failure handling policy of its parent
activity, recursively up to the top-level activity of the process.
When an activity is suspended, you can also use the Process Management API
to retry, fault or cancel it. This allows administrators to intervene and
decide how to proceed in exceptional circumstances.
I'll create a page on the wiki to document this behavior.
regards,
alex
On 2/22/07, Michael Kammholz <[EMAIL PROTECTED]> wrote:
Hi Alex,
it's a fault during the <invoke>. I give consciously wrong parameters to
the webservice (to test the fault handler) so the service throws an
exception when checking the parameters and returns a soap-fault. In this
case I expect the catchAll handler to be called, but nothing happens.
Michael
Am 22.02.2007, 16:44 Uhr, schrieb Alex Boisvert <[EMAIL PROTECTED]>:
> Hi Michael,
>
> Do you mean a fault is received during the process <invoke> or do you
> mean
> there is a fault in the process while it's processing a
<receive>-<reply>
> pair? Also, what kind of fault or failure happens?
>
> alex
>
>
> On 2/22/07, Michael Kammholz <[EMAIL PROTECTED]> wrote:
>>
>> Hallo,
>>
>> I have a problem with BPEL using fault handlers. The simple thing is -
>> they don't work (for me).
>> My fault handler looks as follows:
>>
>> <bpws:faultHandlers>
>> <bpws:catchAll>
>> <bpws:flow>
>> <bpws:sequence>
>> <bpws:assign name="assingFailureMessageToResponse">
>> <bpws:copy>
>> <bpws:from>does not work</bpws:from>
>> <bpws:to>$workflowResponse.ack</bpws:to>
>> </bpws:copy>
>> </bpws:assign>
>> <bpws:reply name="Return_From_Workflow"
>> operation="launchWorkflow" partnerLink="workflowProcess"
>> portType="lns:WorkflowProcessPortType" variable="workflowResponse"/>
>> </bpws:sequence>
>> </bpws:flow>
>> </bpws:catchAll>
>> </bpws:faultHandlers>
>>
>> But when a fault happens during an invoke, the flow stops, only returns
>> when the timeout has reached and the following message appears in the
>> console:
>>
>> Message-Exchange "{MessageExchangeFailureEventImpl
>>
>>
eventType=-1,mex=MsgExch[id=-8tfttudrff36iqnog3tbvn,channel=udcMapServiceChannel,op=convert],targetService=
>> [EMAIL PROTECTED],type=-1}"
>> failed.
>>
>> We are still working with PXE, because PXE is running in an embedded
>> environment here. So easy swapping to ODE is not possible. Although I
>> hope
>> you can help me - maybe there's any known issue about that.
>>
>> The used webservice is tested and running fine.
>>
>> Regards,
>> Michael
>>
--
Michael Kammholz
Arlanis Software AG
Kurfürstenstr. 15
14467 Potsdam
http://www.arlanis.com
Phone: +49 331 27911-29
Fax: +49 331 27911-1
[EMAIL PROTECTED]: [EMAIL PROTECTED]
Amtsgericht Potsdam: HRB 19134 P
Steuer Nr.: 046 100 01292
Vorstand: Christian Metzger
