Time-triggered purge transactions

There are several transactions that you can use to purge your database tables at specific time intervals.

Purge transactions determine when a table should be purged by determining the current date and subtracting the retention days specified by the purge. If the timestamp on the table is less than or equal to (current day - retention days) the table is purged.

In some cases, a purge may look at another field other than the table's timestamp. These are pointed out in the documentation.

When an entity is being purged, the related or dependent information that is present in other tables should be taken into consideration for purging along with it. For example, if a sales order with live shipments is being purged, any cross reference to that order is not accurate in the Order Shipment Console. As another example, agents such as Purge Order and Purge Order History also purge the records from extension tables, such as yfs_order_header_extension and yfs_order_line_extension, as well as their associated histories.

Some of the statistics collected and tracked in Release 9.1 for time-triggered transactions, monitors, and integration and application servers may change with the next release of Sterling™ Order Management System.

All Time-Triggered Purge Transactions have a CollectPendingJobs criteria parameter. If this parameter is set to N, the agent does not collect information on the pending jobs for that time-triggered transaction. This pending job information is used for monitoring the monitor in the System Management Console.

By default, CollectPendingJobs is set to Y. It can be helpful to set it to N if one particular time-triggered transaction is performing a significant amount of getPendingJobs queries, and the overhead cost is too high.