Troubleshooting Archive and Purge, and specifying a specific ticket, in Service Desk Manager

Products

CA Service Management - Service Desk Manager CA Service Desk Manager

Issue/Introduction

The Archive and Purge functionality may be refined to act on specific records/tickets by the use of a SQL "Additional Query."

By default, the Archive and Purge Rules apply to all of the records within a table that meet the general conditions.

Sometimes it is needed to remove a specific record from the Service Desk Manager installation or it may be needed to remove a range of records.

Here is a simple example of removing a single ticket from the system.

Archive and Purge allows you to remove excess ticket information from the Service Desk Management MDB database in a regular, scheduled, controlled manner. This prevents excessive and unnecessary data from being stored in the database.

Best practice recommends the use of Archive and Purge (instead of direct database editing of Table Call_Req) to remove ticket information from the system, as this not only removes the record from the primary ticket table, but removes entries from related tables - such as the Activity Log table.

Removing data only from the primary table will leave orphaned entries in the other tables. It should be avoided as a general practice.

Orphaned entries typically do no harm, but do consume a small amount of database space per entry. Worse, they may prove confusing to those who need to examine the data at a later date, such as by reporting.

Modern database management should automatically consolidate tables when they become fragmented, such as after the removal of a large amount of ticket data over time.

Some examples where it may be required to refine the Archive and Purge Rule:

Remove a specific ticket
Remove a range of tickets
Remove tickets by Organization, Location or other criteria

Environment

Service Desk Manager 14.x and 17.x
All Supported Operating Systems

Resolution

Scenario: Remove Call Request "24."

Call Request "24" has been identified as a ticket that should never have entered the system.

It was created in error and the Administrator now wishes to remove the ticket completely.

1. From the Administrator tab, Archive and Purge, Archive and Purge Rules.

2. "Create New" and complete the standard Archive and Purge fields.

3. Add the Additional Query code to specify the specific ticket, of Call Request "24."

ref_num = \'24\'

NOTES: Single quotes are needed to escape the backslashes. The ticket number "24" is the Call Request number as seen through the web client interface.

In this example, the ref_num is being used, but other fields (i.e. "id") or any other criteria that enables you to uniquely identify the ticket can be used.

Troubleshooting of Archive and Purge

All of the normal rules of Archive and Purge must be satisfied for this example to run.

It is best practice to test new rules to confirm they work:

On a test server
In "Archive Only" mode until confirmed that they work.

If your query does not work, then check items such as:

The Object Name is right - Call Request rather than Incident, for example.
The Rule is set to run within a valid Schedule - A weekend only schedule will not let a rule run on Monday.
The Days Inactive has passed - You may reset the server time on a test server to test. Do not do this on production.
The ticket is Inactive as well as Closed.
Check there are no errors in the STDLOG or the archive log.
Make sure that the ticket is not a Template.
Check that all related information such as Child/Parent tickets or related tickets are Closed.
Check that the Child Tickets satisfy the same requirements as the Rule requires for the Parent tickets. For example, if the Parent tickets are Archived and Purged with a rule such as "resolve_date < 1451599259" then the Child tickets must also meet this requirement in order for the Parent tickets to Archive and Purge to be successful.
Check that all Workflows on the ticket are completed.
Remember that large Archive and Purge operations will take some time to run. Distinguish between the scenarios of "Running, but taking time" against "Not working at all" from the interface and logs.

If more details are needed, put on this tracing and examine the STDLOG again after re-running the rule:

pdm_logstat -n arcpur_srvr TRACE

and turn off when done with:

pdm_logstat -n arcpur_srvr

Additional Information

17.4 Archive and Purge Documentation