Purging Historical Data
The Landmark system generates a large amount of data for such things as action requests, database session debug logs, message queues, and effective dated group processing. Because it is usually not necessary to preserve all of this data, Landmark provides schedulable actions for purging the data.
For a current list of the delivered framework purge actions, see the Maintenance Requests tab in the Async Framework. This tab displays the business class to which the data belongs and the specific action that is performed.
Many of these schedulable actions are delivered in an enabled state, and with settings for the scheduling frequency (weekly) and how far back to preserve data. Some, however, are delivered in a disabled state. You have the option of enabling all of the purge actions or enabling the disabled ones one by one. You can also modify the delivered settings. For example, on the initial running of a purge action, if you know that a large amount of data will be purged and you want to avoid a long-running process, you could adjust the setting for how far back to maintain data. You could start by preserving data from two years ago and onward, and then rerun the action with a setting that preserves data from one year ago and onward, and so on.
One important action that is delivered in an enabled state is a Purge action that will remove AuditLogEntry records. This action is meant to prevent the potential large accumulation of these records. AuditLogEntry records will be purged weekly based on the following:
- Records that have a FrameworkType set will be purged if they are older than 180 days.
- Records that do not have a FrameworkType set will be purged if they are older than 30 days.
You can purge archived AuditLogEntry records regardless of the date by selecting the Include Archived Framework Type Records and Include Archived Non Framework Type Records check boxes on the Purge Entries form.
If you want to archive any of the data that is to be purged, set up data replication for the business classes that the purge actions apply to, and run the data replication before the purge action runs.
Some of these actions may already have queues and queue mappings set up for them. For the others, there is a System Purge queue that will be used.