ode-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Kammholz" <...@arlanis.com>
Subject Re: CatchAll handler
Date Fri, 23 Feb 2007 08:39:01 GMT
Hi Alex,

thanks for the answer - that explains exactly my problem. But - as  
mentioned earlier - we are still using Pxe here. Is there a similar  
feature available for Pxe or is this for Ode only (I tried it with Pxe but  
it hasn't work)?
We work on switching to Ode, but it will take some more time and in  
between it would be great to have a solution (even a unlovely workaround)  
for Pxe.

regards,
Michael

Am 22.02.2007, 17:22 Uhr, schrieb Alex Boisvert <boisvert@intalio.com>:

> 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 <mka@arlanis.com> 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 <boisvert@intalio.com>:
>>
>> > 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 <mka@arlanis.com> 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=
>> >>  
>> com.fs.pxe.sfwk.impl.ServiceBackend$ServiceContextImpl@19d373,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
>> eM@il:  michael.kammholz@arlanis.com
>>
>> Amtsgericht Potsdam: HRB 19134 P
>> Steuer Nr.: 046 100 01292
>> Vorstand: Christian Metzger
>>



-- 
Michael Kammholz
Arlanis Software AG
Kurf├╝rstenstr. 15
14467 Potsdam

http://www.arlanis.com
Phone:  +49 331 27911-29
Fax:    +49 331 27911-1
eM@il:  michael.kammholz@arlanis.com

Amtsgericht Potsdam: HRB 19134 P
Steuer Nr.: 046 100 01292
Vorstand: Christian Metzger

Mime
View raw message