@ViscusiMaurizio Thanks for the finding. I would suggest to raise an incident ticket with Pega Support to verify the behavior of pzAddCaseExclusionFromArchival activity.
@GuhanathanV4521 What is the Pega ruleset name where pzOpenArchivedWorkObject is saved?
@SairohithT17629295That’s correct. pxForceCaseClose doesn’t have a timestamp param. We use Obj-Browse to fetch all open/pending cases whose last commit timestamp (.pxCommitDateTime) to database is older than one year. Then loop through the results to open each case and set its .pyResolvedTimestamp property to the last commit timestamp so that they can be archived in the next job run (assuming the archive policy of the case type is older than 365 days).
@SairohithT17629295 That is an interesting question. I’m not aware of OOTB rule to retrieve the exact archived count. I normally export the latest case list (using a report definition) to Excel, and then after the archival, export another case list to Excel to compare using Excel features. Regarding pxRetrieveSearchData activity, Step 9 sets the max record. Perhaps you can private checkout the activity and modify .pyMaxRecords to >1000 and retry.
@SairohithT17629295 My understanding is that once a case is archived, BIX cannot extract it anymore because BIX extracts data from live Pega tables. In general, you should extract all required data before archiving them.
@Will Cho
When opening the child archived case, it doesnt populate the parent archived case in pyWorkCover page by default.
The OOTB activity used to open any archived case (Parent or Child) is pzOpenArchivedWorkObject. This doesnt have any logic to populate pyWorkCover and this is Final rule which can not be modified.
Is this the expected behaviour?
Thanks!
Guhan
@GuhanathanV4521 That is the behavior i’m also seeing. I don’t see pyWorkCover after opening a child archived item.
pxCoverInsKey is still there to identify the parent ins key.
@Will Cho Thanks! I have raised SR with GCS.
INC-B31997
@Will Cho
Looking for some clarity on a data archival scenario in Constellation (SI AAA Framework) and would appreciate your guidance.
-
We have two case types: DISP and ORCH in OOTB Frame Works
-
These case types are parallel and do not have a parent–child relationship
-
DISP creates ORCH, and there is a dependency between them
-
The requirement is that DISP should be archived only after the related ORCH case is resolved
From my understanding:
-
Pega handles archival dependency automatically only for parent–child case types
-
For parallel case types, business-condition–based retention options are available in the archival policy
-
However, I’m not clear how this approach is intended to handle archival dependency between parallel case types, since there is no built-in relationship like parent–child
I’m trying to understand what the expected or recommended approach is for this kind of scenario in Pega, especially within Constellation / SI AAA Framework.
Any clarification or guidance would be really helpful. Thanks!
@GopalakrishnanIyyavu From my understanding, Pega OOTB archival mechanism enforces the archival dependency only when they have parent-child relationships. Parent case can be archived only when its child cases are resolved. Your scenario above may not be possible using the Pega OOTB archival job. If possible, consider parent-child relationship if this archival dependency is a must-have requirement.