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 purging job is also included in the Auto Purge (disabled by default). The auto purge process deletes all the exchange data regardless of the integration Type or event type that meets the configured retention period.

The auto purge does not remove the datafiles associated with the exchanges.
The user must manually enable this job to be included in the auto-purge process by changing the enabled attribute through the autopurgemetadata generic API.

This process is started with the POST request to the following 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 to track the progress of the purge 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.

Monitor the Purge Exchanges

Tracking the progress of a purge exchange is possible through the location header returned in response to the request to purge exchanges.

The progress can be monitored with a GET request to the following URI:

http://<context:root>/api/purge/exchanges/{id}

The response structure is as follows:

{
  "correlationId" : "${correlationId}",
  "workId" : "{workId}",
  "status" : "Success/Failure/In Process",
  "type"   : "PurgeExchange",
  "links" : [
     {
        "rel" : "monitor",
        "href" : "http://[hostName]:[portNumber]/[api-context-root]/purge/exchanges/{id}",
        "httpMethod": "GET"
     },
     {
        "rel" : "operator",
        "href" : "http://[hostName]:[portNumber]/[api-context-root]/generic/tasks/{workId}",
        "httpMethod": "GET"
     },
     {
        "rel" : "self",
        "href" : "http://[hostName]:[portNumber]/[api-context-root]/purge/exchanges/{id}",
        "httpMethod": "GET"
     }
     ...
  ]
}

Purge Events

This purging job is also included in the Auto Purge (disabled by default). The auto purge process deletes all event data regardless of the event Type that meets the configured retention period.

The user must manually enable this job to be included in the auto-purge process by changing the enabled attribute through the autopurgemetadata generic API.

This process is started with the POST request to the following 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":"",
  "excludeUnhandledEvents":"true or false",
  "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.

  • excludeUnhandledEvents: This optional parameter specifies if unhandled events should be excluded from being purged. If set to true, events that have not been processed by an exchange are excluded from being purged. Only events that have been processed by an exchange are purged. If set to false, events are purged irrespective of the fact if they have been processed by an exchange. The default value is false.

  • 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 to track the progress of the purge events.

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

Monitor the Purge Events

Tracking the progress of a purge event is possible through the location header returned in response to the request to purge events.

The progress can be monitored with a GET request to the following URI:

http://<context:root>/api/purge/events/{id}

The response structure is as follows:

{
  "correlationId" : "${correlationId}",
  "workId" : "{workId}",
  "status" : "Success/Failure/In Process",
  "type"   : "PurgeEvent",
  "links" : [
     {
        "rel" : "monitor",
        "href" : "http://[hostName]:[portNumber]/[api-context-root]/purge/events/{id}",
        "httpMethod": "GET"
     },
     {
        "rel" : "operator",
        "href" : "http://[hostName]:[portNumber]/[api-context-root]/generic/tasks/{workId}",
        "httpMethod": "GET"
     },
     {
        "rel" : "self",
        "href" : "http://[hostName]:[portNumber]/[api-context-root]/purge/events/{id}",
        "httpMethod": "GET"
     }
     ...
  ]
}

Purge Technical Data

Purging of technical data is started with the POST request to the following 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 to track the progress of the purge technical data.

Monitor the Purge Technical Data

Tracking the progress of a purge technical data is possible through the location header returned in response to the request to purge technical data.

The progress can be monitored with a GET request to the following URI:

http://<context:root>/api/purge/technicaldata/{id}

The response structure is as follows:

{
  "correlationId" : "${correlationId}",
  "workId" : "{workId}",
  "status" : "Success/Failure/In Process",
  "type"   : "PurgeTechnicalData",
  "links" : [
     {
        "rel" : "monitor",
        "href" : "http://[hostName]:[portNumber]/[api-context-root]/purge/technicaldata/{id}",
        "httpMethod": "GET"
     },
     {
        "rel" : "operator",
        "href" : "http://[hostName]:[portNumber]/[api-context-root]/generic/tasks/{workId}",
        "httpMethod": "GET"
     },
     {
        "rel" : "self",
        "href" : "http://[hostName]:[portNumber]/[api-context-root]/purge/technicaldata/{id}",
        "httpMethod": "GET"
     }
     ...
  ]
}

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 the notification is as described below. If the endpoint is not configured (generic or specific), the notification is not sent.

{
  "correlationId" : "${correlationId}",
  "workId" : "{workId}",
  "status" : "Success/Failure/In Process",
  "type"   : "PurgeExchange/PurgeEvent/PurgeTechnicalData",
  "links" : [
     {
        "rel" : "operator",
        "href" : "http://[hostName]:[portNumber]/[api-context-root]/generic/tasks/{workId}",
        "httpMethod": "GET"
     }
     ...
  ]
}

The generic notification endpoint can be configured as property ohi.purge.notification.endpoint either in the Oracle Health Insurance application’s properties file or using generic properties API. The notification endpoint can be overridden for specific purge types; for example, specify the property ohi.purge.notification.endpoint.<PURGE TYPE> to have the system deliver all notifications for a particular type to a specific endpoint. The possible types are PurgeEvent, PurgeExchange, and 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.