This topic provides information on Steps to add new table for purging.

1. Create history table for table to be purged.

   E.g. created history table for audit log – DIGX_AL_AUDIT_LOGGING_HIST.sql

2. Write database function to do purging for table data, i.e. to insert data in history table and delete data from actual table based on date or you can add your own condition in where clause.

   E.g. create database function for audit log – AP_DIGX_AL_AUDIT_LOGGING.sql

3. Maintain seed entry for DIGX_PU_SHELL_PARAMS –

   Following are some important columns:

   COD_PURGE_ID: unique value in table and specify sequence of purging activity

   NAM_PURGE_TBL: Name of table to be purged

   FRQ_PURGE: specify time duration of purging .when again the purging activity will take place.

   E.g. if it is 1 then next day purging will take place, if it is 2 than after 2 day activity will take place

   PERD_RETENTION: Up to what date the data should be retained in actual table

   E.g. if it is 15 then current date - 15 days = date up to purge

   Up to that date the data will be present in actual table and previous data will be moved to history table

   NAM_PURGE_PROC: Name of database function which is responsible to do actual purging activity for this table (or related tables).

   E.g. AP_DIGX_AUDIT_LOGGING.sql

   FLG_MNT_STATUS: Indicates whether purging is active (A) or disabled/inactive (I) for each table.

   DAT_LAST_PURGE: Indicates when last purging occurred.

   DAT_NEXT_PURGE: Indicates when next purge will occur.

   DAT_PURGE_UPTO:-Gives information about date up to which data has been purged.

   TYP_PURGE:-It specifies purge type i.e. if purge type is ‘T’ then whole data will get deleted without backup and if type is ‘S’ then it will call appropriate database function which we have maintained in NAM_PURGE_PROC column .

   MODULE_ID:-Specify purging is for which module. The value in this column should exactly match the value of digx-module parameter in web.xml of that module.

   Example: Below entry for reference purpose will help to understand the implementation

   Figure 1-1 MODULE_ID entry for the implementation

   
   

   
   Description of "Figure 1-1 MODULE_ID entry for the implementation"

   
   
4. For each module that requires Purging, an entry should be made into DIGX_CM_TIMER table. The value in MODULE column should exactly match the value of digx-module parameter in web.xml of that module. Other columns of this table can be used to determine when to trigger Purge (BatchProcess) and the frequency for that module.
5. After batch execution, following tables should get updated:
   • digx_pu_shell_params
   • digx_pu_statistics
6. WebLogic setup:
   • No separate deployable is now required for Purge (BatchProcess).
   • Create new non XA data source named “BATCH” for purging. In case of entity specific database, ensure there is a BATCH_<entityId> data source created for each entity.
   • Restart the managed server.