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:

Table 1. 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:

Table 2. Links
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:

Table 3. Indicate 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

Table 4. Failure Result Messages
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".