Siebel REST Inbound - How to Have More Control Over Error Responses From the Business Service API (Doc ID 2803276.1)

Last updated on SEPTEMBER 07, 2021

Applies to:

Symptoms

Some more control over error responses from the Business Service API would be required to comply with internal and external standards.
Enhancements would be needed in the Siebel REST implementation, as currently there is no control over error responses from the Business Service API.

Scenarios considered:

1) HTTP Error Code control
The Business Object API of Siebel provides all kinds of different HTTP error codes for example 404 if the input was not found.
But with the Business Service API, everything is either 200 or 500.

2) HTTP Error body control
When an exception is thrown from the BS, there is a fixed {"ERROR": "description..."} response
Earlier Enhancement ENH <Bug: 32766785> was logged to ask for control over the formatting of the ERROR label itself as this does not comply with REST best practices.



The expected behavior for those 2 scenarios considered would be:

1) HTTP Error Code control
Here it would help to have some ways to control this in Siebel so that can align better to REST standards.

2) HTTP Error body control
In addition to what was requested in that earlier ENH <Bug: 32766785>, now the requirement is to be able to control the entire error response content in more detail.
For example, if trying to comply with RFC7807 in which a standard for 'problem JSON' is described and the requirement is to be able to comply with this standard with the APIs provided from Siebel.
This means more control is needed on the response message body.


The issue can be reproduced at will with the following steps:
1. Call a Business Service via Inbound REST request (using Postman for example).
2. Business service invokes a framework workflow to process the inbound rest request.
3. This workflow processes the inbound request.
  a. In case of success, this workflow is ended as expected via an 'End' step. The response returns an HTTP 200 status code and contains the response message (the naming convention of the message tags from the workflow is controlled).
  b. In case of a failure this workflow ends up in an error exception which points to a 'Stop' step. This stop step throws an error message and error code. The response returns an HTTP 500 status code and contains the error message and error code in the 'ERROR' tag.

Changes

Cause

My Oracle Support provides customers with access to over a million knowledge articles and a vibrant support community of peers and Oracle experts.