1 Steps to add new table for purging
Note:
Purge (BatchProcess) Framework has also been modularized effective from OBAPI 21.1.1.0.0 release.
Each module can trigger Purging independently and tables belonging to only that module shall be purged.
The actual mechanism involved in Purge Framework remains unchanged.
- Create history table for table to be purged.
E.g. created history table for audit log –
DIGX_AL_AUDIT_LOGGING_HIST.sql
- 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
- 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 activityNAM_PURGE_TBL
: Name of table to be purgedFRQ_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 tableE.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 maintain inNAM_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. - 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. - After batch execution, following tables should get updated:
- digx_pu_shell_params
- digx_pu_statistics
- WebLogic setup:
- No separate deployable is now required for Purge (BatchProcess).
- Create new non XA data source named “BATCH” for purging.
- Restart the managed server.