Petals BC REST

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.

Reopened to improve the consumer side

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

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

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.