SimpleMethod's call-service break-on-error="false" causes rollback

[Scott Gray-2]

I'm trying to use call-service's break-on-error="false" attribute but  
my simple method still returns an error at the end of the method, so  
break-on-error="false" seems to just delay the error instead of  
breaking straight away on the service call.  This happens because the  
service call errors end up in the method context which is checked to  
determine the success of the simple method.  I'm doubting this is the  
desired behavior because unless your simple method isn't wrapped in a  
transaction everything is going to get rolled back anyway regardless  
of the break-on-error setting.

Can anyone confirm or deny?

Thanks
Scott

HotWax Media
http://www.hotwaxmedia.com

[David E. Jones-2]

Yes, that's correct, it does not undo the error, it simply keeps it from interrupting the flow so you can do other things.

If you want to "undo" the error, or have it be independent, then technically it needs to run in its own transaction in addition to doing something to no pass the error up the stack.

-David


On Dec 11, 2009, at 1:23 AM, Scott Gray wrote:

> I'm trying to use call-service's break-on-error="false" attribute but my simple method still returns an error at the end of the method, so break-on-error="false" seems to just delay the error instead of breaking straight away on the service call.  This happens because the service call errors end up in the method context which is checked to determine the success of the simple method.  I'm doubting this is the desired behavior because unless your simple method isn't wrapped in a transaction everything is going to get rolled back anyway regardless of the break-on-error setting.
>
> Can anyone confirm or deny?
>
> Thanks
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>

[Scott Gray-2]

Okay thanks David, it just makes testing failure scenarios a bit of a  
pain using simple methods, you have to set break-on-error to false,  
require-new-transaction to true and then you also have to clear the  
responseMessage and errorMessageList after the service call.  But if  
that the way it's supposed to be then so be it.

Thanks
Scott

On 13/12/2009, at 3:45 PM, David E Jones wrote:

>
> Yes, that's correct, it does not undo the error, it simply keeps it  
> from interrupting the flow so you can do other things.
>
> If you want to "undo" the error, or have it be independent, then  
> technically it needs to run in its own transaction in addition to  
> doing something to no pass the error up the stack.
>
> -David
>
>
> On Dec 11, 2009, at 1:23 AM, Scott Gray wrote:
>
>> I'm trying to use call-service's break-on-error="false" attribute  
>> but my simple method still returns an error at the end of the  
>> method, so break-on-error="false" seems to just delay the error  
>> instead of breaking straight away on the service call.  This  
>> happens because the service call errors end up in the method  
>> context which is checked to determine the success of the simple  
>> method.  I'm doubting this is the desired behavior because unless  
>> your simple method isn't wrapped in a transaction everything is  
>> going to get rolled back anyway regardless of the break-on-error  
>> setting.
>>
>> Can anyone confirm or deny?
>>
>> Thanks
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>

[David E. Jones-2]

What are you trying to do?

-David


On Dec 13, 2009, at 12:32 AM, Scott Gray wrote:

> Okay thanks David, it just makes testing failure scenarios a bit of a pain using simple methods, you have to set break-on-error to false, require-new-transaction to true and then you also have to clear the responseMessage and errorMessageList after the service call.  But if that the way it's supposed to be then so be it.
>
> Thanks
> Scott
>
> On 13/12/2009, at 3:45 PM, David E Jones wrote:
>
>>
>> Yes, that's correct, it does not undo the error, it simply keeps it from interrupting the flow so you can do other things.
>>
>> If you want to "undo" the error, or have it be independent, then technically it needs to run in its own transaction in addition to doing something to no pass the error up the stack.
>>
>> -David
>>
>>
>> On Dec 11, 2009, at 1:23 AM, Scott Gray wrote:
>>
>>> I'm trying to use call-service's break-on-error="false" attribute but my simple method still returns an error at the end of the method, so break-on-error="false" seems to just delay the error instead of breaking straight away on the service call.  This happens because the service call errors end up in the method context which is checked to determine the success of the simple method.  I'm doubting this is the desired behavior because unless your simple method isn't wrapped in a transaction everything is going to get rolled back anyway regardless of the break-on-error setting.
>>>
>>> Can anyone confirm or deny?
>>>
>>> Thanks
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>
>

[Scott Gray-2]

I'm trying to call a service inside a simple method test and the  
expected behavior is for the service to return an error.  Because the  
service error is actually a test case success I don't want the simple  
method to return an error.

I actually committed it yesterday, you can see the code in  
QuoteTests.xml#createQuoteWorkEffortFail.

Regards
Scott

On 13/12/2009, at 7:42 PM, David E Jones wrote:

>
> What are you trying to do?
>
> -David
>
>
> On Dec 13, 2009, at 12:32 AM, Scott Gray wrote:
>
>> Okay thanks David, it just makes testing failure scenarios a bit of  
>> a pain using simple methods, you have to set break-on-error to  
>> false, require-new-transaction to true and then you also have to  
>> clear the responseMessage and errorMessageList after the service  
>> call.  But if that the way it's supposed to be then so be it.
>>
>> Thanks
>> Scott
>>
>> On 13/12/2009, at 3:45 PM, David E Jones wrote:
>>
>>>
>>> Yes, that's correct, it does not undo the error, it simply keeps  
>>> it from interrupting the flow so you can do other things.
>>>
>>> If you want to "undo" the error, or have it be independent, then  
>>> technically it needs to run in its own transaction in addition to  
>>> doing something to no pass the error up the stack.
>>>
>>> -David
>>>
>>>
>>> On Dec 11, 2009, at 1:23 AM, Scott Gray wrote:
>>>
>>>> I'm trying to use call-service's break-on-error="false" attribute  
>>>> but my simple method still returns an error at the end of the  
>>>> method, so break-on-error="false" seems to just delay the error  
>>>> instead of breaking straight away on the service call.  This  
>>>> happens because the service call errors end up in the method  
>>>> context which is checked to determine the success of the simple  
>>>> method.  I'm doubting this is the desired behavior because unless  
>>>> your simple method isn't wrapped in a transaction everything is  
>>>> going to get rolled back anyway regardless of the break-on-error  
>>>> setting.
>>>>
>>>> Can anyone confirm or deny?
>>>>
>>>> Thanks
>>>> Scott
>>>>
>>>> HotWax Media
>>>> http://www.hotwaxmedia.com
>>>>
>>>
>>
>