Response Messages

Indicating Success

HTTP API/IP make use of HTTP status codes in the HTTP headers to indicate a success. The following table lists these status codes:

Code	Meaning	Description
200	OK	Request succeeded for GET, PUT and PATCH calls.
201	Created	Request succeeded for creation(POST) of a resource.
202	Accepted	Request accepted for asynchronous POST or DELETE calls
204	No Content	Request succeeded for deleting a resource or there is nothing that is fetched for GET

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:

1. Header "HTTP 200 OK", accompanied by a full response body or

2. Header "HTTP 204 No Content", without any response body.

By default, Oracle Health Insurance Components 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:

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

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

3. 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 Components 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 Components 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 (e.g. 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".