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.

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 maintain 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.

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.
   • Restart the managed server.