Concepts

Tasks

Settings

Introduction to Data Purging

APM administrators can set up purging rules to permanently remove large numbers of items that are no longer relevant from their APM databases. A purging rule identifies the type of object to be purged (for example, resource transactions or indicator readings) as well as the criteria used to select the instances to be purged. For example, you can purge all timecard transactions that are more than five years old.

Warning: When data is purged from the APM system, it is deleted from the database. There is no way to retrieve it other than to restore it from backup. Because the misuse of data purging can result in the loss of large amounts of relevant data, you must launch APM as an administrator to define and activate purging rules. For more information, see Logging on as an Administrator.

More than 300 APM classes can be purged. For example:

•	Audit information for most classes

•	Asset health readings

•	Attachments

•	Calculation results

•	Checksheets

•	Count sheets

•	Data import requests

•	Data loaders

•	Indicator collection reports

•	Indicator readings

•	Integration events

•	Mass update requests

•	ODC message logs

•	Receiving reports

•	Resource transactions

•	Scheduled action execution history

•	Synchronization history

•	Transaction entry forms

•	Upload transactions

•	Work requests

This topic explains how data purging works and the steps involved in setting up and working with purging rules.

Purging Rules

A purging rule consists of a set of instructions that is used to select instances of a particular type of object to be deleted as a group. For example, an APM administrator could create one purging rule for resource transactions, another for indicator readings, and so on.

Each purging rule identifies the type of object to be purged, as well as the criteria to use to select those objects. For example, you might want to define a purging rule that deletes all indicator readings that are more than five years old.

You can have any number of purging rules for the same class of object, but with different selection criteria for each one. For example, you might want to have one purging rule for deleting issue transactions (that is, where the transaction type is “issue”), a second for receipt transactions, and so on.

You can set up purging rules to be scheduled to run automatically according to a recurrence pattern, or you can trigger them manually on an as-needed basis. For example, you could schedule a rule to purge indicator readings that are more that five years old to run automatically at the end of every month.

Purging vs. Deleting

Fundamentally, there is no difference between deleting and purging an object. In both cases, the object is removed from the database. However, the actions are executed differently. Deletion is a manual task that is usually performed on a single instance for a specific reason on a one-off basis. In contrast, purging is usually an automated task that is carried out periodically according to a set schedule. Its goal is to free up disk space and improve performance by deleting a large number of instances that meet a set of predefined criteria. Typically, the data selected for purging is older and no longer relevant.

In both cases, the objects selected for purging or deletion must satisfy the deletion requirements that APM has defined. Otherwise, the deletion fails. For example, when you delete a resource transaction, the deletion fails if the transaction has not been posted.

However, the successful purging of an instance is not subject to the availability of the instance’s Delete method. That is, a user can be prevented from manually deleting an instance because the application has disabled its Delete method, but purging rules are not subject to this constraint. This means that any instance can be deleted using a purging rule, regardless of whether it can be deleted manually using its Delete method, provided it meets the deletion requirements specified in the purging rule. Indicator readings, for example, cannot be deleted manually once they have been processed (because the Delete method is disabled), but they can be deleted by a purging rule without restriction.

Effect of Purging on Related Objects

When an object is purged, objects that are related to it can be affected in some way, depending on the deletion rules that APM has defined for each relationship that the deleted object has with other objects. The possible choices are:

•	Delete the related object

•	Do nothing to the related object

•	On the related object, null the reference to the object being deleted

•	Fail the deletion

Whether an object is deleted manually by a user or is purged through the purging framework, the deletion behavior is identical.

Deletion Failures During a Purge

Occasionally, the deletion of objects that are selected for purging fails. This happens if the class’ deletion behavior prevents the object from being deleted. For example, the deletion behavior for indicator readings does not allow a reading to be deleted if it is the most recent reading for the indicator. It could also happen if the instance is locked by another user.

Whatever the cause of the deletion failure, when this situation arises during the execution of a purging rule, the purging function abandons the attempt to delete the item and moves on to the next item that satisfies the rule’s selection criteria. The user is not informed at the time that an item could not be purged. However, the purging history record that is created when the purging rule has finished executing includes a count of the number of selected instances that could not be deleted. You can also view audit reports of purged data and purge failures.

Setting Up and Executing Purging Rules

Setting up and working with purging rules involves the following steps:

•	Define data purging settings, if you wish to save audit reports of objects that are purged, objects that fail to be purged, or both.

•	Create one or more purging rules, which includes specifying the type of object, triggering method (manual or automatic), and selection criteria.

•	Preview the items to be purged to ensure that the selection criteria produce the correct result.

•	Activate each purging rule so that it is available for execution.

•	Manually execute a purging rule, if you wish. A purging rule can be executed manually whether its triggering method is set to manual or automatic.

•	Set up one or more scheduled actions to trigger purging rules automatically on a regular basis.

•	View each purging rule’s execution history and audit reports to monitor the purge results