Data Page Activity not called after migration
Hi,
currently we test whether we can upgrade from Pega 7.1.9 to 8.3 and ran into the following issue:
In our application we run an activity step which iterates over a page list. This pagelist property refers to a data page, and the data page gets it´s data sourced from an activity. This means that the mentioned pagelist property is only populated in case it can get / create its data by the mentioned data page activity. If not as you probably know the activity step is skipped since the property is not existing.
In 7.1.9 it works perfectly fine, we populate the data by using the mentioned data page (activity). In 8.3 somehow it doesn´t work for some pagelist propertys (we use different pagelists), for others it does work with the very same data page reference.
I traced it thoroughly and yet couldnt figure out why this is happening, also traced Pega engine rulesets. Here I realized that sometimes Pega checks for a specific Data-Admin-System-Settings instance with the following message : "Looking for instance Data-Admin-System-Settings DATA-ADMIN-SYSTEM-SETTINGS PEGA-ENGINE!DATAPAGE/NEWGENPAGES in the Instance cache " (Cache Hit not found). Maybe there is even no connection to my issue and this setting, however this is one difference I spotted when comparing my 7.1.9 vs 8.3 trace.
Hi,
currently we test whether we can upgrade from Pega 7.1.9 to 8.3 and ran into the following issue:
In our application we run an activity step which iterates over a page list. This pagelist property refers to a data page, and the data page gets it´s data sourced from an activity. This means that the mentioned pagelist property is only populated in case it can get / create its data by the mentioned data page activity. If not as you probably know the activity step is skipped since the property is not existing.
In 7.1.9 it works perfectly fine, we populate the data by using the mentioned data page (activity). In 8.3 somehow it doesn´t work for some pagelist propertys (we use different pagelists), for others it does work with the very same data page reference.
I traced it thoroughly and yet couldnt figure out why this is happening, also traced Pega engine rulesets. Here I realized that sometimes Pega checks for a specific Data-Admin-System-Settings instance with the following message : "Looking for instance Data-Admin-System-Settings DATA-ADMIN-SYSTEM-SETTINGS PEGA-ENGINE!DATAPAGE/NEWGENPAGES in the Instance cache " (Cache Hit not found). Maybe there is even no connection to my issue and this setting, however this is one difference I spotted when comparing my 7.1.9 vs 8.3 trace.
Are there any known issue with data pages after migrating? I did some rule revalidation for activities and data pages as well, didn´t help. Restarting the server also didn´t help ;-)
Many thanks in advance, any help would be highly appreciated.
Regards
Rasit
Accepted Solution
Updated: 31 Aug 2020 2:37 EDT
Allianz Technology SE
DE
Hi,
no, the properties are not optimized.
We now have a better idea what´s happening.
So the page list property gets used in our process before we run the problematic activity, so Pega caching obviously "thinks" this page list property already got data access via data page / activity, however the input values changed in the process too. So reloading would be the proper way to go.
How did we find out?
By removing the page list property via Property-Remove method in the first step of our problem activity. When doing this the page list property will call the underlying data page / activity. In Pega 7 this definitely worked different, when page list properties used data access via data page it always called the underlying data page, although the parameters are hard coded / didn´t change.
Anyway thanks for your help.
Regards,
Rasit
Pegasystems Inc.
US
Can you share any screen shots of how the data page is configured and how you are referencing it? When tracing with the Data Pages event type, what messages do you see when the Data Page is referenced?
Allianz Technology SE
DE
Sure:
Parameters are not missing btw.
To your point regarding tracing: I traced the activity combined with the data page, in Pega 7 it runs fine, in the tracer I can see all data page events:
But in Pega 8 as you can see the activity step is skipped although I checked out and traced the data page (with data page events activated):
Pegasystems Inc.
US
I tried a similar configuration on my system and saw the Data Page load. Can you enable the 'AutoPopulate Properties' event type in Tracer and see what that shows?
In my test I saw these messages in Tracer.
Allianz Technology SE
DE
I tried AutoPopulate too, it shows nothing, doesn´t even pop up in the tracer.
I tried many things, for example creating new page list properties in a higher ruleset version and switchting data access to copy. Also removing the Pega cache by truncating a bunch of (rules schema) sys tables which helped in the past in similar scenarios. Unfortunately it didn´t help.
The only thing which helped was creating new page list properties (with a new name). When I did this and implemented them in this problematic activity it ran as expected. But in our case this would be the worst case because this means we need to create new properties and change a lot of activities which reference these page lists.
Any other idea?
Pegasystems Inc.
US
Can you check the System-Declare-Changes instances and see if there is an entry for your page list property?
For my test, I have a Clients page list property that refers to a D_ClientsList Data Page. When I view the System-Declare-Changes instances, I see one entry for my property.
Allianz Technology SE
DE
Hi,
yes I could find even two instances for the very same property, one with instance index 0, and the other one with instance index 1. Could it be that this duplicate leads to problems?
Pegasystems Inc.
IN
Hi,
The pagelist properties for which issue occurs are optimized ? Duplicate entires in the index table could be the issue.
Please check if there's any duplicate in the index table which is mapped in the declare index rule.
Thanks,
Kaviya
Accepted Solution
Updated: 31 Aug 2020 2:37 EDT
Allianz Technology SE
DE
Hi,
no, the properties are not optimized.
We now have a better idea what´s happening.
So the page list property gets used in our process before we run the problematic activity, so Pega caching obviously "thinks" this page list property already got data access via data page / activity, however the input values changed in the process too. So reloading would be the proper way to go.
How did we find out?
By removing the page list property via Property-Remove method in the first step of our problem activity. When doing this the page list property will call the underlying data page / activity. In Pega 7 this definitely worked different, when page list properties used data access via data page it always called the underlying data page, although the parameters are hard coded / didn´t change.
Anyway thanks for your help.
Regards,
Rasit