Response Messages
Showing Success
HTTP API/IP uses HTTP status codes in the HTTP headers to show success. The following table lists these status codes:
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 accepted 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. |
In the case of successfully creating a resource next to a 201 status code, the server returns the Location URI. In the HTTP specification, it is optional whether the server sends the representation of the newly created resource. In many cases, it will send a full response body as it may contain further processing instructions for the client in the form of hypermedia links.
In the case of successfully updating a resource, according to the HTTP specification the server has to respond in one of the following ways:
-
Header "HTTP 200 OK", accompanied by a full response body or
-
Header "HTTP 204 No Content", without any response body.
By default, Oracle Health Insurance applications will send "HTTP 200 OK" and a full response body. After updating a resource the server does not return a Location URI.
In the case of successfully deleting a resource, according to the HTTP specification the server has to respond in one of the following ways:
-
Header "HTTP 200 OK" if the response includes an entity describing the status; Oracle Health Insurance systems use this option if a sub-entity was deleted to return the modified (master) entity.
-
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
When responding to requests, Oracle Health Insurance applications may add URI links to the response message payload. 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 containing element. |
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 first 'page'. Only applicable if the current 'page' is not the first. |
next |
For pagination of results: for navigation to next 'page'. Only applicable if the list contains additional items. |
prev |
For pagination of results: for navigation to previous 'page'. Only applicable 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. |
Indicating Failure
An HTTP IP service response message to an 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 table lists the HTTP status codes for indicating failure:
Code | Meaning | Description |
---|---|---|
400 |
Bad Request |
The request could not be understood by the server due to malformed syntax (for example, when 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 matching the Request URI |
405 |
Method not allowed |
An HTTP method is invoked that is not supported by the resource. |
406 |
Not acceptable |
The resource identified by the request is only capable of generating response entities which have 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 that 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 |
500 |
Internal Server Error |
Something went wrong on the server, check server status and logs and/or 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 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 the response of 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. These messages are described below.
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 2 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 1 or 2 arguments, the first to compare against, and the second character to escape |
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}".
Lastly, 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".