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

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.
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.
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
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".
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

People

Dates

  • Created:
    Wed, 15 Jul 2015 - 13:41:51 +0200
    Updated:
    Thu, 4 Jan 2018 - 11:16:37 +0100