Response Messages
Indicate Success
The HTTP API/IP uses the HTTP status codes as a response in the HTTP headers to show the success of the API/IP. The following list provides the HTTP status codes that indicate success:
Code | Meaning | Description |
---|---|---|
200 |
OK |
Request succeeds for GET, PUT, and PATCH calls. |
201 |
Created |
Request succeeds and creates (POST) a resource. |
202 |
Accepted |
Request accepts for asynchronous POST or DELETE calls. |
204 |
No Content |
Request succeeds and deletes a resource, or the target resource is unavailable. |
300 |
Redirect Message |
Request succeeds with a redirection URL. It is optional to use the URL. |
304 |
Not Modified |
Request succeeds with a redirection URL. It is optional to use the URL. |
In the case of the successful creation of a resource with the 201 status code, the server returns the destination URI. In the HTTP specification, whether the server sends the representation of the newly created resource is optional. In many cases, it will send a full response body as it may contain further processing instructions for the client in hypermedia links.
In the case of successful updation of a resource, in accordance with the HTTP specification, the server has to respond in one of the following ways:
-
Header
HTTP 200 OK
(with a full response body) -
Header
HTTP 204 No Content
(without any response body)
By default, Oracle Health Insurance applications will send HTTP 200 OK
and an entire response body.
After the updation of the resource, the server does not return a location URI.
In the case of successful deletion of a resource, in accordance with the HTTP specification, the server has to respond in one of the following ways:
-
Header
HTTP 200 OK
if the response includes an entity that describes the status; Oracle Health Insurance use this option to return the modified (primary) entity if a sub-entity was deleted. -
Header
HTTP 202 Accepted
if the action has not yet been enacted; Oracle Health Insurance systems use this option if the entity is deleted at a later stage. -
Header
HTTP 204 No Content
if the action has been enacted but the response does not include an entity; Oracle Health Insurance systems use this option if the entity was deleted successfully.
Requests that GET one or more resources will have a response structure specific to the integration point.
Links
Oracle Health Insurance applications may add URI links to the response message payload while responding to requests. Links have the following attributes:
-
rel: description for the type of link
-
href: the actual hypermedia reference that the client may activate
Oracle Health Insurance applications return absolute URI links.
The following link types are distinguished:
Link Type | Description |
---|---|
self |
Self reference: identifies a resource equivalent to the element it contains. |
file |
Reference to a file that will be streamed to the client when the link is activated. |
messages |
List of messages resulting from processing a request or activity. |
first |
For pagination of results: for navigation to the first page.' It only applies if the current page is not the first. |
next |
For pagination of results: for navigation to the next page.' It only applies if the list contains additional items. |
prev |
For pagination of results: for navigation to the previous page.' It only applies if the current page is not the first. |
actions/… |
Denotes actions that are executed when the link is activated. For example: 'actions/startprocessing' to start an activity. |
Indicate Failure
An HTTP IP service response message to a unsuccessfully processed request message will have the following structure along with appropriate HTTP status codes unless it is explicitly required to have more information to be part of the response of the integration point:
<?xml version="1.0" encoding="UTF-8"?>
<exceptionDetail xmlns:o="http://www.oracle.com/insurance/exception">
<o:errorDetails>
<o:errorDetail o:errorCode="OHI-ERR" title="Title" />
</o:errorDetails>
</exceptionDetail>
The following list provides the HTTP status codes for indicating failure:
Code | Meaning | Description |
---|---|---|
400 |
Bad Request |
The server could not understand the request due to malformed syntax (for example, when the unmarshalling of the request failed) or a security vulnerability was detected. |
401 |
Unauthorized |
Request failed because the user is not authenticated. |
403 |
Forbidden |
Request failed because the user is not authorized. |
404 |
Not found |
The server has not found anything that matches the Request URI. |
405 |
Method not allowed |
An HTTP method is invoked, but the resource does not support that. |
406 |
Not acceptable |
The resource identified by the request can only generate response entities with content characteristics not acceptable according to the accept headers sent in the request. |
409 |
Conflict |
The resource identified by the Request URI is not in a state where it can be processed for the desired operation. |
415 |
Unsupported Media Type |
The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method. |
422 |
Unprocessable Entity |
The syntax of the request is correct (thus, a 400 (Bad Request) status code is inappropriate), but the server was unable to process the contained instructions because the data violates business rules. |
429 |
Too Many Requests |
The server is too busy to accept more requests; please try again later. |
500 |
Internal Server Error |
Something went wrong on the server, check the server status, logs and then report the issue. |
Failure Result Messages
Result messages are common or specific. Inside the element <resultMessages> (described above), there may be zero, one, or more result messages. The purpose of these messages is to clarify why a request message was not processed successfully. The message text contains the message text in which the substitution parameters have been set.
For example, the Activity Integration Point’s synchronous response message, which failed to start the activity process as the activity code was unknown, would be:
<exceptionDetail xmlns:o="http://www.oracle.com/insurance/exception"> <o:errorDetails> <o:errorDetail o:errorCode="ACT-IP-ACTY-001" title="ACT-IP-ACTY-001: Activity code abc is unknown" /> </o:errorDetails> </exceptionDetail>
-
Integration Point Specific messages can only occur in response to a specific Integration Point. Such messages are described in the description of the concerned Integration Point.
-
Messages common across Integration Points can occur in the responses of many Integration Points. These messages relate to common functionality, like the use of dynamic fields.
The following is a description of these messages:
Messages common across Integration Points |
Code | Severity | Message | Description |
---|---|---|---|
GEN-ACRE-001 |
Fatal |
Access restriction code {code} is unknown. Request cannot be processed |
|
GEN-TRAS-001 |
Fatal |
A reference may only be provided in combination with a transaction source |
|
GEN-TRAS-002 |
Fatal |
Transaction source code {code} is unknown |
|
GEN-CURR-001 |
Fatal |
Currency code {code} is unknown |
|
GEN-DYNA-001 |
Fatal |
The dynamic field: {dynamicFieldUsageName} should have unique values. There is already a record with value: {value} |
|
GEN-DYNA-002 |
Fatal |
{dynamicFieldUsageName}: There is already a value present in this period of time ({startDate} - {endDate}) |
|
GEN-DYNA-003 |
Fatal |
Cannot insert same value for the flex code in case the dynamic field is multivalue |
|
GEN-DYNA-006 |
Fatal |
Dynamic field flex code definition code {code} is unknown. Request cannot be processed |
|
GEN-DYNA-007 |
Fatal |
The flex code {code} is unknown to dynamic field {dynamicFieldUsageName}. Request cannot be processed |
|
GEN-DYNA-009 |
Fatal |
{endDate} should be later than or the same as {startDate} for {dynamicFieldUsageName} |
|
GEN-DYNA-010 |
Fatal |
{dynamicFieldUsageName} should have a value and a {startDate} |
|
GEN-DYNA-011 |
Fatal |
{dynamicFieldUsageName} value {value} does not belong to flex code definition {code} |
|
GEN-DYNA-012 |
Fatal |
{dynamicFieldUsageName}: the same value {value} is present in another period ({startDate} - {endDate}) |
|
GEN-DYNA-015 |
Fatal |
The field {dynamicFieldUsageName} is not allowed to be empty |
|
GEN-DYNA-018 |
Fatal |
Usage {dynamicFieldUsageName} can only have a record when the condition defined evaluates to true |
|
GEN-DYNA-019 |
Fatal |
Usage {dynamicFieldUsageName} should have at least one record |
|
GEN-DYNA-020 |
Fatal |
Key field {flexCodeFieldUsageCode} should have unique value for Dynamic record {dynamicFieldUsageName} |
|
COD-FCFU-101 |
Fatal |
Dynamic Records should specify the value for key field. Dynamic Record {dynamicFieldUsageName} does not specify value for key {flexCodeFieldUsageCode} |
|
GEN-HTTP-001 |
Fatal |
Value {value} is not part of domain |
|
GEN-HTTP-002 |
Fatal |
LookupFailed. Could not find {resourceName} |
Raised when the lookup of a dependent object fails. Say Brand cannot be found when inserting a claim with the provided information in the payload. |
GEN-HTTP-003 |
Fatal |
Expected single match but found {number} matches for {resourceName} |
Raised when the lookup of a dependent object fails. Say Multiple Brands are found when inserting a claim with the provided information in the payload. |
GEN-HTTP-004 |
Fatal |
Not authorized for this operation on this resource. Please contact your system administrator |
|
GEN-HTTP-005 |
Fatal |
Value {0} is not of type {1} |
Raised when the provided property in the payload is of incorrect type. |
GEN-HTTP-006 |
Fatal |
It is not allowed to delete reference data: {0} with {1} |
Raised when trying to delete a resource that is referenced by another entity and hence cannot be deleted. |
GEN-HTTP-007 |
Fatal |
Search Expression Parsing Error: Unknown operator {0} |
|
GEN-HTTP-008 |
Fatal |
Resource {0} cannot be resolved |
Raised when sending in a request for a resource and the resource cannot be resolved. So, the request comes to /generic/abc, and abc is not a valid resource. |
GEN-HTTP-009 |
Fatal |
Arguments cannot be null |
Raised when querying using Generic API, and the query arguments cannot be null. |
GEN-HTTP-010 |
Fatal |
Search Operator between accepts two arguments. The current arguments are {0} |
|
GEN-HTTP-011 |
Fatal |
Operator {0} expects single argument, but multiple values given |
|
GEN-HTTP-012 |
Fatal |
If the arguments are null, operator can only be eq and neq and not {0} |
|
GEN-HTTP-013 |
Fatal |
Operator cannot be null |
|
GEN-HTTP-014 |
Fatal |
Attributes or Arguments cannot be empty |
|
GEN-HTTP-015 |
Fatal |
Limit value {0} cannot be more than {1} |
|
GEN-HTTP-016 |
Fatal |
{0} {1} is unknown |
Raised when a request is done with parameters that should point to an existing entity, but that entity cannot be found. Example: "Unfinalize Reason" "ABC" is unknown |
GEN-HTTP-017 |
Fatal |
Mandatory property {0} is missing |
|
GEN-HTTP-018 |
Fatal |
Aggregate Function could not be determined |
|
GEN-HTTP-019 |
Fatal |
Alias Name for the aggregate function {0} cannot be empty |
|
GEN-HTTP-020 |
Fatal |
Aggregate Function {0} does not define the attribute to aggregate on |
|
GEN-HTTP-021 |
Fatal |
Alias names need to be unique. {0} is used more than once |
|
GEN-HTTP-022 |
Fatal |
Like operator should have either one or two arguments, the first to compare against, and the second character to escape |
|
GEN-HTTP-030 |
Fatal |
Expected single match but found more than one match for {resourceName} |
Raised when the lookup of a dependent object fails. Say Multiple Brands are found when inserting a claim with the provided information in the payload. |
Besides these messages, business rule messages may also occur in the responses of Integration Points. Business rule messages are raised in the validation layer of the Oracle Health Insurance application and are common to both the User Interface pages_ and the Integration Points. For example, business rule GEN-TMVL-001: The start date should lie before the end date for {dynamicFieldUsageName}.
Following that, technical error messages may be returned through the responses of Integration Points. For example, database message GEN-ORA-01400: "NAME" column is mandatory for table "REL_PROVIDERS".