Purge Data Integration Point

The Oracle Insurance Gateway stores a large volume of historical data related to events and exchanges. The purging operations described helps user manage the data volume in the application.

All operations described here are long-running operations. The progress of these operations can be monitored by the links provided in the response that is returned when the operation is successfully initiated. They are the hypermedia link with rel="monitor" and rel="operator".

Long-running operations are described in the "HTTP API/IP Concepts" chapter of the Developer Guide.

Purge Exchanges

This process is started by making a POST request to the URI:

http://<context:root>/api/purge/exchanges

This process is a long-running operation initiated through RESTful web service. The user requires an access grant on the purge exchange IP to invoke the operation described here.

Payload

{
  "periodUom":"D (days), M (months) or Y (years)",
  "periodLength":"",
  "integrationType":"",
  "integrationCode":"",
  "includeDataFiles":"true or false",
  "commitSize":"",
  "currentDate":""
}

  • periodUom and periodLength: These mandatory parameters specify the retention period. The unit of measure is specified as D (days), M (months) or Y (years). The reference date for the retention period is the system date. For example, when a 10-year retention period is specified all exchanges that are older than (based on the date part of the date-time attribute of the exchange) ten years (from the date that the purging process is executed) are selected for purging.

  • integrationType: This optional parameter specifies the integration type. Only exchanges with the specified integration type are purged.

  • integrationCode: This optional parameter specifies the integration code. Only exchanges with the specified integration code are purged

  • includeDataFiles: If Y (means set to true) then all data file sets and included data files that would be orphaned by the purge action and those that have been orphaned by a previous purge action are also removed from the system.

  • commitSize: This optional parameter gives the user control over the commit size. A larger commit size improves the performance of the purge long-running operation at the cost of requiring more computing resources, a larger undo tablespace. If unspecified each table is purged after 5000 statements per table, followed by a commit per table.

  • currentDate: This optional date is used as if it were the sysdate for the purpose of calculating the retention period. It is meant to facilitate test runs.

  • The system responds with HTTP 201 (Created) and a location header for the exchanges.

Exchanges outside the retention period and matching type or code are physically removed from the system. This includes related exchange steps and exchange logs, and (optionally) the Data File Sets and Data Files. This excludes any exchange events as these are included in the purge events operation.

Purge Events

This process is started by making a POST request to the URI :

http://<context:root>/api/purge/events

This process is a long-running operation initiated through RESTful web service. The user requires an access grant on the purge events IP to invoke the operation described here.

Payload

{
  "periodUom":"D (days), M (months) or Y (years)",
  "periodLength":"",
  "eventType":"",
  "commitSize":"",
  "currentDate":""
}

Parameters

  • periodUom and periodLength: These mandatory parameters specify the retention period. The unit of measure is specified as D (days), M (months) or Y (years). The reference date for the retention period is the system date. For example, when a 10-year retention period is specified all events that are older than (based on the date part of the date-time attribute of the exchange) ten years (from the date that the purging process is executed) are selected for purging.

  • eventType: This optional parameter specifies the event type. Only events with the specified event type are purged.

  • commitSize: This optional parameter gives the user control over the commit size. A larger commit size improves the performance of the purge long-running operation at the cost of requiring more computing resources, i.e., a larger undo tablespace. If unspecified each table is purged using a single statement per table, followed by a commit per table.

  • currentDate: This optional date is used as if it were the sysdate for the purpose of calculating the retention period. It is meant to facilitate test runs.

  • The system responds with HTTP 201 (Created) and a location header for the events.

Events that are older than the retention period and match the type are removed from the system. This includes related exchange events,

Purge Technical Data

Purging of technical data is started by making a POST request to the URI :

http://<context:root>/api/purge/technicaldata

This process is a long-running operation initiated through a RESTful web service. The user requires an access grant on the purge technical data IP to invoke the operation described here.

Payload

{
   "purgeDaysTask":"",
   "purgeDaysBatch":""
}

The input parameters define the retention period for the data expressed in days. The minimum retention period is 30 days. A value smaller than 30 for any of the input parameters results in an error.

The system responds with HTTP 201 (Created) and a location header for the technicaldata.

Optional: Purge Notification

The purge integration point provides a call back feature to a pre-configured endpoint. This feature provides the following response to the configurable endpoint once the purge triggered by an external system through IP has concluded. The structure of notification is as under. If the endpoint is not configured (generic or specific), the notification is not sent.

<notification correlationId="" workId="{workId}" status="Success/Failure" type="PurgeExchange">
  <links>
    ...
  </links>
</notification>

The generic notification endpoint can be configured as property 'ohi.purge.notification.endpoint' in the Oracle Health Insurance application’s properties file. The notification endpoint can be overridden for specific purge types, e.g. specify property 'ohi.purge.notification.endpoint.<PURGE TYPE>' to have the system deliver all notifications for a certain type to a specific endpoint. The possible types are 'PurgeEvent', 'PurgeExchange', 'PurgeTechnicalData'.

If the notification endpoint is configured on the specific type, all other properties are also fetched based on the type or else defaults are used. Similarly, if the endpoint for the notification endpoint is configured using generic property, then all other properties are fetched on a generic uses code PurgeNotificationClient. Please see section Outbound RESTful Service Invocations in the Security Guide for the process and more properties.