Purge Data Integration Point

The Oracle Insurance Gateway stores a large volume of historical data related to events and exchanges. The purging operations described here support the user with managing 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 integration 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":"Y or N",
  "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, 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.

Exchanges outside of 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.

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.

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 OHI Components 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 usecase code 'PurgeNotificationClient'. Please see section Outbound RESTful Service Invocations in Integration Guide for the process and more properties.