Petals BC REST

Properly handles business faults from/to REST

Details

  • Description:
    Hide

    Following PETALSBCREST-1, we should now properly handle business faults in the REST BC.

    On provider side, now the HTTP code different from 20x are transformed into JBI errors. We should be able to generate fault on HTTP codes that have such a meaning.

    On consumer side, on fault, a HTTP code 500 is returned. We should be able to return different HTTP code according to the received fault.

    Show
    Following PETALSBCREST-1, we should now properly handle business faults in the REST BC. On provider side, now the HTTP code different from 20x are transformed into JBI errors. We should be able to generate fault on HTTP codes that have such a meaning. On consumer side, on fault, a HTTP code 500 is returned. We should be able to return different HTTP code according to the received fault.
  • Environment:
    -

Issue Links

Activity

Victor NOËL made changes - Wed, 15 Jul 2015 - 13:41:57 +0200
Field Original Value New Value
Assignee Christophe DENEUX [ cdeneux ] Victor NOËL [ vnoel ]
Victor NOËL made changes - Wed, 15 Jul 2015 - 13:42:23 +0200
Link This issue depends on PETALSBCREST-1 [ PETALSBCREST-1 ]
Victor NOËL made changes - Wed, 15 Jul 2015 - 13:48:02 +0200
Link This issue blocks PETALSDISTRIB-133 [ PETALSDISTRIB-133 ]
Christophe DENEUX made changes - Thu, 29 Dec 2016 - 10:46:04 +0100
Priority Major [ 3 ]
Description Following PETALSBCREST-1, we should now properly handle business faults in the REST BC.

For now the HTTP errors are Errors, business Faults should be recognised as such, it's not clear how.
Maybe there is some kind of norm to recognise a business fault from a normal answer in REST.
Following PETALSBCREST-1, we should now properly handle business faults in the REST BC.

On provider side, now the HTTP code different from 20x are transformed into JBI errors. We should be able to generate fault on HTTP codes that have such a meaning.

On consumer side, on fault, a HTTP code 500 is returned. We should be able to return different HTTP code according to the received fault.
Hide
Christophe DENEUX added a comment - Thu, 29 Dec 2016 - 10:52:34 +0100 - edited

On provider side, we will add the following configuration in the SU JBI descriptor to process HTTP codes different from 20x:

<rest:mapping>
   ...
   <rest:operation name="ged:consulter">
      ...
      <rest:on-http-status code="404">
         <rest:xsl as-fault="true">404.xsl</rest:xsl>
      </rest:on-http-status>
      ...
   </rest:operation>
   ...
</rest:mapping>

Where:

  • on-http-status defines the processing to apply when the HTTP code given by the attribute 'code' is returned,
  • xsl defines the XSL to execute on the given HTTP code. The XSL transformation result will be returned as fault or normal response according to the attribute 'as-fault'.

Note:

  • for MEP 'RobustInOnly', the XSL transformation result will be returned as fault only because the pattern does not support normal response. A warning will be logged if the configuration defines to generate a normal response.
  • for MEP 'InOnly', no XSL transformation is needed. When receiving a HTTP code different from 20x, if a configuration 'on-http-status' exists for it, the status DONE will be returned, otherwise the status ERROR.
Show
Christophe DENEUX added a comment - Thu, 29 Dec 2016 - 10:52:34 +0100 - edited On provider side, we will add the following configuration in the SU JBI descriptor to process HTTP codes different from 20x:
<rest:mapping>
   ...
   <rest:operation name="ged:consulter">
      ...
      <rest:on-http-status code="404">
         <rest:xsl as-fault="true">404.xsl</rest:xsl>
      </rest:on-http-status>
      ...
   </rest:operation>
   ...
</rest:mapping>
Where:
  • on-http-status defines the processing to apply when the HTTP code given by the attribute 'code' is returned,
  • xsl defines the XSL to execute on the given HTTP code. The XSL transformation result will be returned as fault or normal response according to the attribute 'as-fault'.
Note:
  • for MEP 'RobustInOnly', the XSL transformation result will be returned as fault only because the pattern does not support normal response. A warning will be logged if the configuration defines to generate a normal response.
  • for MEP 'InOnly', no XSL transformation is needed. When receiving a HTTP code different from 20x, if a configuration 'on-http-status' exists for it, the status DONE will be returned, otherwise the status ERROR.
Christophe DENEUX made changes - Thu, 29 Dec 2016 - 10:52:35 +0100
Status New [ 10000 ] Open [ 10002 ]
Assignee Victor NOËL [ vnoel ] Christophe DENEUX [ cdeneux ]
Christophe DENEUX made changes - Thu, 29 Dec 2016 - 11:55:40 +0100
Status Open [ 10002 ] In Progress [ 10003 ]
Hide
Christophe DENEUX added a comment - Thu, 29 Dec 2016 - 11:56:41 +0100 - edited

On provider side, HTTP codes different from 20x are now correctly managed in trunk.

Show
Christophe DENEUX added a comment - Thu, 29 Dec 2016 - 11:56:41 +0100 - edited On provider side, HTTP codes different from 20x are now correctly managed in trunk.
Christophe DENEUX made changes - Thu, 29 Dec 2016 - 11:56:41 +0100
Status In Progress [ 10003 ] Resolved [ 10004 ]
Fix Version/s 1.0.2 [ 10696 ]
Resolution Fixed [ 1 ]
Hide
Christophe DENEUX added a comment - Thu, 29 Dec 2016 - 11:57:01 +0100

Reopened to improve the consumer side

Show
Christophe DENEUX added a comment - Thu, 29 Dec 2016 - 11:57:01 +0100 Reopened to improve the consumer side
Christophe DENEUX made changes - Thu, 29 Dec 2016 - 11:57:01 +0100
Status Resolved [ 10004 ] Open [ 10002 ]
Resolution Fixed [ 1 ]
Christophe DENEUX made changes - Thu, 29 Dec 2016 - 17:32:58 +0100
Link This issue blocks PETALSBCREST-8 [ PETALSBCREST-8 ]
Christophe DENEUX made changes - Wed, 25 Jan 2017 - 17:17:43 +0100
Link This issue depends on PETALSBCREST-29 [ PETALSBCREST-29 ]
Hide
Christophe DENEUX added a comment - Tue, 14 Feb 2017 - 17:57:17 +0100

The definition explains below is not sufficient. In some usecases, we can have an error HTTP code with an HTTP body to use to generate the right fault, error or OUT message according to the HTTP body content.
A definition as following should be sufficient and opener:

<on-http-status code="500">
   <fault order-id="2">
      <condition>
         <xpath>...</xpath>
      </condition>
      <transformation>
         <xsl>xslfilename.xsl</xsl>
      </transformation>
    </fault>
    <out order-id="1">
      <condition>
         <xpath>...</xpath>
      </condition>
      <transformation>
         <xsl>xslfilename.xsl</xsl>
      </transformation>
    </out>
    <error order-id="3">
      <condition>
         <xpath>...</xpath>
      </condition>
      <transformation>
         <xsl>xslfilename.xsl</xsl>
      </transformation>
    </error>
    <otherwise-out>
      <transformation>
         <xsl>xslfilename.xsl</xsl>
      </transformation>
    </otherwise-out>
    <otherwise-fault />
    <otherwise-error />
</on-http-status>

The expression defined by <condition /> must return a boolean value. If true, the associated transformation is applied, and the result is put in OU message, fault message or as error according to <out />, <fault /> or <error />. The attribute order-id is required and defines the order of condition evaluations.

For error, the transformation must return a String.

<otherwise-out />, <otherwise-fault /> and <otherwise-error /> are exclusives and optional. This transformation is applied if no condition is evaluated to true.

If no condition evaluated to true and no default transformation::

  • if 20x:
    • if InOut: OUT with the content of HTTP body of the REST response,
    • else (InOnly or RobustInOnly): DONE,
  • sinon: ERROR with a message as "No specific processing found for HTTP Code '500' and current HTTP body".
Show
Christophe DENEUX added a comment - Tue, 14 Feb 2017 - 17:57:17 +0100 The definition explains below is not sufficient. In some usecases, we can have an error HTTP code with an HTTP body to use to generate the right fault, error or OUT message according to the HTTP body content. A definition as following should be sufficient and opener:
<on-http-status code="500">
   <fault order-id="2">
      <condition>
         <xpath>...</xpath>
      </condition>
      <transformation>
         <xsl>xslfilename.xsl</xsl>
      </transformation>
    </fault>
    <out order-id="1">
      <condition>
         <xpath>...</xpath>
      </condition>
      <transformation>
         <xsl>xslfilename.xsl</xsl>
      </transformation>
    </out>
    <error order-id="3">
      <condition>
         <xpath>...</xpath>
      </condition>
      <transformation>
         <xsl>xslfilename.xsl</xsl>
      </transformation>
    </error>
    <otherwise-out>
      <transformation>
         <xsl>xslfilename.xsl</xsl>
      </transformation>
    </otherwise-out>
    <otherwise-fault />
    <otherwise-error />
</on-http-status>
The expression defined by <condition /> must return a boolean value. If true, the associated transformation is applied, and the result is put in OU message, fault message or as error according to <out />, <fault /> or <error />. The attribute order-id is required and defines the order of condition evaluations. For error, the transformation must return a String. <otherwise-out />, <otherwise-fault /> and <otherwise-error /> are exclusives and optional. This transformation is applied if no condition is evaluated to true. If no condition evaluated to true and no default transformation::
  • if 20x:
    • if InOut: OUT with the content of HTTP body of the REST response,
    • else (InOnly or RobustInOnly): DONE,
  • sinon: ERROR with a message as "No specific processing found for HTTP Code '500' and current HTTP body".
Christophe DENEUX made changes - Tue, 14 Feb 2017 - 17:57:26 +0100
Status Open [ 10002 ] In Progress [ 10003 ]
Christophe DENEUX made changes - Tue, 14 Feb 2017 - 18:01:26 +0100
Status In Progress [ 10003 ] Resolved [ 10004 ]
Resolution Fixed [ 1 ]
Hide
Christophe DENEUX added a comment - Tue, 14 Feb 2017 - 18:01:57 +0100

Reopened to improve the consumer side

Show
Christophe DENEUX added a comment - Tue, 14 Feb 2017 - 18:01:57 +0100 Reopened to improve the consumer side
Christophe DENEUX made changes - Tue, 14 Feb 2017 - 18:01:58 +0100
Status Resolved [ 10004 ] Open [ 10002 ]
Resolution Fixed [ 1 ]
Component/s Consumer mode [ 10403 ]
Component/s Provider mode [ 10404 ]
Christophe DENEUX made changes - Thu, 4 Jan 2018 - 11:16:37 +0100
Fix Version/s 1.1.1-BC [ 10768 ]
Christophe DENEUX made changes - Thu, 15 Feb 2018 - 14:48:49 +0100
Fix Version/s 1.1.2-BC [ 10821 ]
Fix Version/s 1.1.1-BC [ 10768 ]
Christophe DENEUX made changes - Thu, 26 Jul 2018 - 16:45:54 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Hide
Christophe DENEUX added a comment - Thu, 26 Jul 2018 - 16:46:10 +0200 - edited

The consumer side is fixed by PETALSBCREST-65. Please see PETALSBCREST-65 to know how to configure the HTTP response according to the JBI response of the service provider.

Show
Christophe DENEUX added a comment - Thu, 26 Jul 2018 - 16:46:10 +0200 - edited The consumer side is fixed by PETALSBCREST-65. Please see PETALSBCREST-65 to know how to configure the HTTP response according to the JBI response of the service provider.
Christophe DENEUX made changes - Thu, 26 Jul 2018 - 16:46:10 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Resolution Fixed [ 1 ]
Transition Status Change Time Execution Times Last Executer Last Execution Date
New New Open Open
532d 22h 10m
1
Christophe DENEUX
Thu, 29 Dec 2016 - 10:52:35 +0100
Open Open In Progress In Progress
1h 3m
1
Christophe DENEUX
Thu, 29 Dec 2016 - 11:55:40 +0100
In Progress In Progress Resolved Resolved
1m 1s
1
Christophe DENEUX
Thu, 29 Dec 2016 - 11:56:41 +0100
Resolved Resolved Open Open
20s
1
Christophe DENEUX
Thu, 29 Dec 2016 - 11:57:01 +0100
Open Open In Progress In Progress
47d 6h
1
Christophe DENEUX
Tue, 14 Feb 2017 - 17:57:26 +0100
In Progress In Progress Resolved Resolved
4m
1
Christophe DENEUX
Tue, 14 Feb 2017 - 18:01:26 +0100
Resolved Resolved Open Open
32s
1
Christophe DENEUX
Tue, 14 Feb 2017 - 18:01:58 +0100
Open Open In Progress In Progress
526d 21h 43m
1
Christophe DENEUX
Thu, 26 Jul 2018 - 16:45:54 +0200
In Progress In Progress Resolved Resolved
16s
1
Christophe DENEUX
Thu, 26 Jul 2018 - 16:46:10 +0200



People

Dates

  • Created:
    Wed, 15 Jul 2015 - 13:41:51 +0200
    Updated:
    Thu, 26 Jul 2018 - 16:47:00 +0200
    Resolved:
    Thu, 26 Jul 2018 - 16:46:10 +0200