problem solved. Thanks Dushan for guidance
regex based on [1]
<filter source="get-property('ERROR_CODE')"
regex="[1|3|4][0-9][0-9][0-9][0-9][0-9]">
<then>
<property name="HTTP_SC" value="400" scope="axis2" />
</then>
</filter>
[1] http://docs.wso2.org/display/ESB460/Error+Handling+and+Error+Codes
On Tue, Feb 11, 2014 at 10:48 AM, Dushan Abeyruwan <dus...@wso2.com> wrote:
> Hi
> You can setup HTTP_SC in axis2 context set 400 (which represents bad
> Request)
>
>
> On Tue, Feb 11, 2014 at 10:42 AM, Krishantha Dinesh
> <kr...@krishantha.com>wrote:
>
>> Hi Dushan,
>> Thanks for prompt reply.
>> I do agree with you. my concern is http response got which client get on
>> transport headers.
>> pls refer below
>>
>> This is what client get as exception
>>
>> <Response xmlns="http://cd-rhettige/services/paypal_lookupSale";>
>>
>> <error_code>101503</error_code>
>>
>> <error_message>Error connecting to the back end</error_message>
>>
>> </Response>
>>
>>
>> ========================================
>> this is the raw content. pls pay your attention for http status code
>>
>> HTTP/1.1 200 OK
>>
>> Authorization: Bearer OQaph7mMZJbvNDJ-8u9ICVm4Q4kkJmNj.w5dQJZ5u8E
>>
>> Host: cd-rhettige:8280
>>
>> Accept-Encoding: gzip,deflate
>>
>> Content-Type: application/json
>>
>> Date: Tue, 11 Feb 2014 05:06:58 GMT
>>
>> Server: WSO2-PassThrough-HTTP
>>
>> Transfer-Encoding: chunked
>>
>> Connection: Keep-Alive
>>
>>
>>
>> { "error_code":"101503",
>>
>> "error_message":"Error connecting to the back end"
>>
>> }
>>
>>
>>
>> On Tue, Feb 11, 2014 at 10:04 AM, Dushan Abeyruwan <dus...@wso2.com>wrote:
>>
>>> Hi,
>>> No its wrong, we shouldn't response with 200 OK for exceptions. IMO
>>> ideal way as I think, to do this by keep the catalog of connector specific
>>> error code and embedded in the error message and explain those _ _connector
>>> specific error _ _ catalog in documentation more specifically, and
>>> returning a generic error with status code to client.
>>>
>>> for error catalogs you could refer [1][2]
>>> [1]http://www.twilio.com/docs/errors/reference
>>> [2]
>>> http://www.stormpath.com/blog/spring-mvc-rest-exception-handling-best-practices-part-1
>>> e.g
>>>
>>>
>>>
>>> {
>>> "status": 404,
>>> * "code": 40483,*
>>> "message": "Oops! It looks like that file does not exist.",
>>> "developerMessage": "File resource for path /uploads/foobar.txt does
>>> not exist. Please wait 10 minutes until the upload batch completes before
>>> checking again.",
>>> "moreInfo": "http://www.mycompany.com/errors/40483";
>>> }
>>>
>>>
>>>
>>> On Tue, Feb 11, 2014 at 9:51 AM, Krishantha Dinesh <kr...@krishantha.com
>>> > wrote:
>>>
>>>> Hi Dushan/Dev
>>>> I tried ur solution and its work. but i have other question. when it
>>>> catch FAULT (500 error) on return message of client http code is 200 OK
>>>> for example let say endpoint is fail the it catch that fault. but in
>>>> client point of view http respond code of his response is 200
>>>>
>>>> other than 500 client getting correct http response code. the problem
>>>> may be this is originate by ESB it self than come as response to ESB. btw
>>>> is there any solution for this.
>>>>
>>>>
>>>>
>>>> On Sat, Feb 8, 2014 at 7:30 PM, Dushan Abeyruwan <dus...@wso2.com>wrote:
>>>>
>>>>> Hi Kirshantha,
>>>>> Handling fault has two flavors,
>>>>>
>>>>> - Handle internal fault such as service EP not available and all
>>>>> the issues related .
>>>>> - Handle Service faults.
>>>>>
>>>>>
>>>>> Ideally when BE is SOAP and if it returns SOAP fault in order to
>>>>> handle such queries we normally append FORCE_ERROR_ON_SOAP_FAULT property,
>>>>> this works only of BE return Service faults and when such happen if we
>>>>> need
>>>>> to divert such responses to the faultSequence that we have defined.
>>>>> On the other hand if that is RESTful BE, we do not have a inbuilt
>>>>> function to determine whether its a fault at transport level, so the
>>>>> workaround that we normally do is to use the Filter base on the HTTP_SC.
>>>>> If you look at [1] status codes represents 100 series and 200-
>>>>> series regards as non faulty responses, and other than that we can
>>>>> determine them as faults or defect, to overcome such station when deal
>>>>> with
>>>>> RESTful services personally I am using filters i.e
>>>>>
>>>>> OutSequence ..etc , below logic just evaluates the response and if
>>>>> that not falls between 200 series normally you can add your customize
>>>>> faulty response logic ..
>>>>>
>>>>> <filter source="$axis2:HTTP_SC" regex="^[^2][0-9][0-9]">
>>>>> <then>
>>>>> <log level="custom">
>>>>>
>>>>> - can include payload
>>>>> - can setup HTTP_SC to axis2 context
>>>>> - can use <respond> mediator to reply client with error.
>>>>>
>>>>> ..............
>>>>> ..............
>>>>>
>>>>> </then>
>>>>> </filter>
>>>>>
>>>>>
>>>>> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Feb 7, 2014 at 7:54 PM, Krishantha Dinesh <
>>>>> kr...@krishantha.com> wrote:
>>>>>
>>>>>> I have used following code to handle error on soap call
>>>>>>
>>>>>> proxy
>>>>>> ==============
>>>>>>
>>>>>> <faultSequence>
>>>>>> <makefault version="soap11">
>>>>>> <code xmlns:tns="
>>>>>> http://www.w3.org/2003/05/soap-envelope";
>>>>>> value="get-property('FAULT_CODE')" />
>>>>>> <reason expression="get-property('ERROR_CODE')" />
>>>>>> <detail expression="get-property('ERROR_MESSAGE')" />
>>>>>> </makefault>
>>>>>> <send />
>>>>>> </faultSequence>
>>>>>>
>>>>>> Output
>>>>>> ==============
>>>>>> <soapenv:Envelope xmlns:soapenv="
>>>>>> http://schemas.xmlsoap.org/soap/envelope/";>
>>>>>> <soapenv:Body>
>>>>>> <soapenv:Fault>
>>>>>> <faultcode xmlns:tns="
>>>>>> http://www.w3.org/2003/05/soap-envelope";>123456</faultcode>
>>>>>> <faultstring>abc</faultstring>
>>>>>> <detail>xyz</detail>
>>>>>> </soapenv:Fault>
>>>>>> </soapenv:Body>
>>>>>> </soapenv:Envelope>
>>>>>>
>>>>>>
>>>>>> I need to know what is the best approach to handle exception on REST
>>>>>> calls.
>>>>>>
>>>>>> i tried to apply same way just for try but it only give ERROR_MESSAGE
>>>>>> not another...
>>>>>>
>>>>>> my expectation is to deliver all exception to client (caller). eg:
>>>>>> transport error due to unavailable endpoint.. etc
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Dev mailing list
>>>>>> Dev@wso2.org
>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dushan Abeyruwan | Associate Tech Lead
>>>>> Integration Technologies Team
>>>>> PMC Member Apache Synpase
>>>>> WSO2 Inc. http://wso2.com/
>>>>> Blog:http://dushansview.blogspot.com/
>>>>> Mobile:(0094)713942042
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Dushan Abeyruwan | Associate Tech Lead
>>> Integration Technologies Team
>>> PMC Member Apache Synpase
>>> WSO2 Inc. http://wso2.com/
>>> Blog:http://dushansview.blogspot.com/
>>> Mobile:(0094)713942042
>>>
>>>
>>
>
>
> --
> Dushan Abeyruwan | Associate Tech Lead
> Integration Technologies Team
> PMC Member Apache Synpase
> WSO2 Inc. http://wso2.com/
> Blog:http://dushansview.blogspot.com/
> Mobile:(0094)713942042
>
>
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
