Pega OOTB purge functionality not working v 8.6
Pega v 8.6 :Requirement is to purge all Resolved Cases aging for 365 days
.I have configured the Purge wizard as per Pega articles and selected only Purge as we do not require Archiving with aging days since 173 days in order to validate a small number of cases for testing the Purging functionality.
The Job Scheduler pyPegaPurger has been saved in our application RS and the access group has been updated to the application Ruleset.
However when the Job Scheduler runs there aren't any updates on the DB side, even if cases are falling within the criteria I do not see them getting deleted from work table. When traced, I can see the pega api getting called from the JS's activity.
Is there additional setting required for Pega OOTB feature to run for an application?
below DSS settings have been updated:
dataarchival/purgeQueryLimit = 50
dataarchival/batchSize = 25
dataarchival/purgeForceLoggingEnabled = true
Can anyboby suggest what am I missing out on,which all rules need to be updated befor eth efunctionlaity could work?
Early response is greatly appreciated.
***Edited by Moderator Marije to add Capability tags***
***Edited by Moderator Marije to add Support Case Details; ***
Accepted Solution
Updated: 23 Feb 2023 5:29 EST
Pegasystems Inc.
GB
Updated: 1 Jun 2022 6:44 EDT
Pegasystems Inc.
GB
@PriyaK20 can you confirm you followed these documents?
Case archiving and purging overview
,Purging and archiving old work items (please use the troubleshooting techniques listed in chapter 'Testing the Purge/Archive wizard) ,
Selecting archive settings and
If you are performing the Purge functionality then you can check the respective work object instances, to make sure they are getting removed or not from database.
Valid status can be any resolved status like Resolved-Completed/Cancelled/Rejected,etc. It states that any work object with resolved status and pyResolvedTimeStamp older than specified days, eg 20 days.
Suggest:
@PriyaK20 can you confirm you followed these documents?
Case archiving and purging overview
,Purging and archiving old work items (please use the troubleshooting techniques listed in chapter 'Testing the Purge/Archive wizard) ,
Selecting archive settings and
If you are performing the Purge functionality then you can check the respective work object instances, to make sure they are getting removed or not from database.
Valid status can be any resolved status like Resolved-Completed/Cancelled/Rejected,etc. It states that any work object with resolved status and pyResolvedTimeStamp older than specified days, eg 20 days.
Suggest:
- Enable Rule_Obj_Activity.ProcessConfig.PegaAccel_Management_Archival.Action class to DEBUG mode
- (PegaAccel-Management-Archival.ProcessConfig is the activity which is being used by this feature during purge/archive).
- Check the log after the purge functionality has been executed
- Provide us with the exact parameters you set (as per Phase 1 and Phase 2 descriptions in the documentation)
- Provide us with a concrete example of work object (and full history) that you were expecting to see purged, and which DB tables you queried to verify this)
UBS
IN
@MarijeSchillern Yes I have followed the above documents and implemented. The weird thing that I see is that when I am scheduling the Purge , I do not see the Show Summary screen to confirm the purge settings,the same has been attached here,though I could see the same in a different application in 8.3v. Is it because I am not able to confirm the settings, the purge isn't happening at all?
I have enabled the logger as mentioned by you and also checked the logs when the Job Scheduler, pyPegaPurger is run,nothing in the logs.
below is the query I use to verify whether purge has happened or not .
select pxcoveredcountopen,pystatuswork,now()-pxUpdateDatetime as ResolvedDays, pxInsName,pxCoverInsKey,pxCreateDateTime,pxUpdateDatetime from {work object table}
where pystatuswork='Resolved-Completed'
order by pxupdatedatetime desc ----- I have cases falling within the criteria but they are not getting removed from work table.
Also can you please tell whether we need to update the pyPegaPurger or let it be as it is.I had saved it in our RS to edit the timings
Your help is greatly appreciated
Updated: 6 Jun 2022 6:36 EDT
Pegasystems Inc.
GB
@PriyaK20 I have alerted an SME to take a look.
However for the sake of efficiency I believe it might be an idea to log a support incident for this if you need this particular issue to be looked at in detail.
Please can you provide the INC id here so that we can help track it?
UBS
IN
@MarijeSchillern I have raised INC-226541 and it is being worked upon but haven't got the solution yet.
Pegasystems Inc.
GB
@PriyaK20 I see that you logged the support question 5 days ago already. I was not aware of that.
The support team is actively looking into the Tracer you provided and will take this matter further from here.
UBS
IN
@MarijeSchillern Thanks for your support
Accepted Solution
Updated: 23 Feb 2023 5:29 EST
Pegasystems Inc.
GB
@PriyaK20 I can see that the support ticket was closed with the following investigation notes:
IssuePega api does not purge cases even if there are cases falling within the Purge Criteria. Creating this task to capture ui sme efforts on analysis.
Analysis: Post Analysing the network and pega logs from the client:
Found 403 status in server call & empty CSRF token error in pega logs. CSRF token is a dependency for this purge action as the serve was expecting a token instead it received an empty token.
Attempted solutions Purge wizard is now working without breaking the section after a config change, Configure->System->Settings-> unchecked Cross-Site Request Forgery.
Root cause: Configuration issue
Outcome: Issue fixed after a config change, Configure->System->Settings-> unchecked Cross-Site Request Forgery. For now the users were asked to uncheck the CSRF token check to use the Purge functionality of Pega.
@PriyaK20 I can see that the support ticket was closed with the following investigation notes:
IssuePega api does not purge cases even if there are cases falling within the Purge Criteria. Creating this task to capture ui sme efforts on analysis.
Analysis: Post Analysing the network and pega logs from the client:
Found 403 status in server call & empty CSRF token error in pega logs. CSRF token is a dependency for this purge action as the serve was expecting a token instead it received an empty token.
Attempted solutions Purge wizard is now working without breaking the section after a config change, Configure->System->Settings-> unchecked Cross-Site Request Forgery.
Root cause: Configuration issue
Outcome: Issue fixed after a config change, Configure->System->Settings-> unchecked Cross-Site Request Forgery. For now the users were asked to uncheck the CSRF token check to use the Purge functionality of Pega.
https://docs.pega.com/security/86/enabling-and-configuring-cross-site-request-forgery-settings
https://docs.pega.com/user-experience/85/corb-error-chrome-80-samesite-cookies
For the Purge issue the "Enable CSRF token check" needs to be unchecked, as it will affect the present Purge wizard configuration. We will be upgrading the Purge wizard in the future where this dependency will be removed.
Outcome:
Disabling csrf has solved the current issue but product improvements were logged to handle the dependency issue with current purge workflow. .
Note : UI refactoring is a major exercise and cannot be done in patch release. Purge Archive is deprecated as of 8.5 (PegaCloud) and in 8.7 in favour of case archival.
@PriyaK20 I can see that the support ticket was closed with the following investigation notes:
IssuePega api does not purge cases even if there are cases falling within the Purge Criteria. Creating this task to capture ui sme efforts on analysis.
Analysis: Post Analysing the network and pega logs from the client:
Found 403 status in server call & empty CSRF token error in pega logs. CSRF token is a dependency for this purge action as the serve was expecting a token instead it received an empty token.
Attempted solutions Purge wizard is now working without breaking the section after a config change, Configure->System->Settings-> unchecked Cross-Site Request Forgery.
Root cause: Configuration issue
Outcome: Issue fixed after a config change, Configure->System->Settings-> unchecked Cross-Site Request Forgery. For now the users were asked to uncheck the CSRF token check to use the Purge functionality of Pega.
@PriyaK20 I can see that the support ticket was closed with the following investigation notes:
IssuePega api does not purge cases even if there are cases falling within the Purge Criteria. Creating this task to capture ui sme efforts on analysis.
Analysis: Post Analysing the network and pega logs from the client:
Found 403 status in server call & empty CSRF token error in pega logs. CSRF token is a dependency for this purge action as the serve was expecting a token instead it received an empty token.
Attempted solutions Purge wizard is now working without breaking the section after a config change, Configure->System->Settings-> unchecked Cross-Site Request Forgery.
Root cause: Configuration issue
Outcome: Issue fixed after a config change, Configure->System->Settings-> unchecked Cross-Site Request Forgery. For now the users were asked to uncheck the CSRF token check to use the Purge functionality of Pega.
https://docs.pega.com/security/86/enabling-and-configuring-cross-site-request-forgery-settings
https://docs.pega.com/user-experience/85/corb-error-chrome-80-samesite-cookies
For the Purge issue the "Enable CSRF token check" needs to be unchecked, as it will affect the present Purge wizard configuration. We will be upgrading the Purge wizard in the future where this dependency will be removed.
Outcome:
Disabling csrf has solved the current issue but product improvements were logged to handle the dependency issue with current purge workflow. .
Note : UI refactoring is a major exercise and cannot be done in patch release. Purge Archive is deprecated as of 8.5 (PegaCloud) and in 8.7 in favour of case archival.