Question
Capgemini
CA
Last activity: 26 Nov 2020 14:27 EST
Purge/Archive Work objects into another database table
Hi everyone,
We have a requirement to Purge/Archive the work objects of our application into another database and also provide the ability for the user to search these work objects and open to see the details.
Approach what we are thinking:
Use Pega OOTB wizard for Purge/Archival and then import the work objects into archival DB using an agent. Unzip each zip file created by Pega and open each WO, update the work class with archival work class and push it into archival DB.
This approach will be fine for our daily load of 15000 resolved cases. But, the issue is our application went into production in 2015 and 7 million work objects got piled up and all these records also need to be purged and archived. With our approach above, it will take ages to archive millions of these work objects with 15k daily load adding on top of it. So, is there any better approach we can go with? Any temporary approach to just archive the 7 million work objects also works.
What we are thinking is move these 7 million work objects within DB from current tables to archived tables. But with this approach the work class will be same in both DBs for all work objects so it may give errors when user tries to open the archived requests.
Appreciate any help. Thank you very much.
Durga Prasad
Accepted Solution
Updated: 26 Nov 2020 14:27 EST
Capgemini
CA
Hi All,
We decided to go with Pega OOTB for daily archival and Agent to import the records by opening the Zip files and iterating through each record, Page change class each record with archival class and push into archival tables. As the average number of resolved cases per day are 15000 Pega OOTB will be the best option even it addresses half of our requirement (only purge/Archive).
For historical 7 million cases, we are yet to decide on Pega OOTB or DB Export/Import (DB Cursor Load would be a better option for huge data migration. Check with your DBA for best option). But for my question above for the DB Export/Import, yes once the records from actual DB of work class are moved into archival DB we need to run an agent to update all the records with archival class. When we open each record and Page-Change class and save, it will be saved as a new instance to archival class. So, still the old record with work class exists which should be deleted. Means, in the agent we have to open each record, page change class with archival class, obj-save and delete the existing work class instance.
Schedule and leave this agent run till the 7 million requests are updated and then disable it on production.
Thank you
Durga Prasad