Question
375008155608
US
Last activity: 9 Jan 2018 18:43 EST
Agent Processed Data Pages
This is in response to the post that I found at https://pdn.pega.com/support-articles/thread-level-datapage-loading-incorrect-data
I am running into a similar issue, and disagree that this is "expected behavior". My scenario is as follows:
- A very common DCR data page is defined at MyCo-Data-ClassRef. This defines all classes that extend from MyCo-Data-ClassRef.
- At the implementation layer, the loading data transform changes the data page to instead be of class MyCo-Impl-Data-ClassRef. It does so by updating .pxObjClass. This works completely if a normal user references the data page.
- If an SLA triggers a rule that references the data page, the MyCo-Data-ClassRef version runs, even though according to the application, it should be running the other version of the rule.
To me, it seems like thread/requestor level data pages, whether editable or read only, should always be flushed when an agent fires. Any given run of an agent could potentially run under a different application's scope, and it is not the job of the rules triggered by the agent to know that they need to flush these data pages, or to know that they were ultimately triggered by an agent. This should be handled by the agent.
***Edited by Moderator Marissa to update categories***
Pegasystems Inc.
IN
Hi Jerome,
I have checked on this use case and to put the words in other way, the use case is working as per the design :)
I also observe that there are multiple posts regarding the same https://community.pega.com/support/support-articles/threadinteraction-data-pages-not-cleared-sla-processing
For the data page to reload for every interaction you may use an editable data page. Let me know if you have any queries.
375008155608
US
Note: My issue is about regular thread level data pages, not ones that refresh per interaction, however the observed behavior is the same.
The timestamp param solution would work, however I have one big issue with it. If I wanted to be 100% correct, I would have to add a timestamp param to every data page that refreshes per interaction, and really, since my problem is that thread level data pages are not refreshing in general, I would need to do this for all thread level data pages. I realize that to solve my current issue, I would only have to do this for the one or two problematic data pages, however for any given data page, at dev time, I cannot assume that at run time that data page would never be triggered via an agent. Additionally, I don't necessarily want the data page to refresh every time that it is referenced. I just want these to refresh as new when the agent runs.
As for making the data page editable, will doing that cause the data page to refresh when the agent runs? In normal scenarios, the editable data page only populates itself the first time that it is referenced, and in order to make it repopulate, you have to do a page remove on it. Making the data page editable may solve the issue when referenced by an agent, however it will cause issues for all other scenarios where it is normally referenced (not from an agent).
Note: My issue is about regular thread level data pages, not ones that refresh per interaction, however the observed behavior is the same.
The timestamp param solution would work, however I have one big issue with it. If I wanted to be 100% correct, I would have to add a timestamp param to every data page that refreshes per interaction, and really, since my problem is that thread level data pages are not refreshing in general, I would need to do this for all thread level data pages. I realize that to solve my current issue, I would only have to do this for the one or two problematic data pages, however for any given data page, at dev time, I cannot assume that at run time that data page would never be triggered via an agent. Additionally, I don't necessarily want the data page to refresh every time that it is referenced. I just want these to refresh as new when the agent runs.
As for making the data page editable, will doing that cause the data page to refresh when the agent runs? In normal scenarios, the editable data page only populates itself the first time that it is referenced, and in order to make it repopulate, you have to do a page remove on it. Making the data page editable may solve the issue when referenced by an agent, however it will cause issues for all other scenarios where it is normally referenced (not from an agent).
When a rule that is ran declaratively/dynamically does not exhibit the same behavior all of the time, it makes me very skeptical that I should be using that type of rule. Data pages should be able to be 100% agnostic about what, where, and when they are going to be referenced.
Pegasystems
US
>>> regular thread level data pages, not ones that refresh per interaction
Wouldn't regular thread-level data pages automatically go away when the thread goes away? And therefore if a new interaction makes a new thread, the data page would be created anew, and therefore effectively "refreshed"?
If there's any difference between how code behaves in SLA agent context vs non-agent context, I would think the most likely differences would be due to one of these:
(I just tried to click the "bullet" icon and no bullets are appearing!)
(hmmm, number-icon not showing numbers either)
1) SLA's run under operator "system" instead of actual operator name, so anything that keys off of "current operator" will generally not work properly
2) The ruleset list for SLA's, as well as the access group, may be different than for non-agent context
3) It is possible to have some specific code that says "if in an SLA, take this alternate path".
You may be able to do a detailed Pega trace of your SLA agent and your interactive run and pinpoint whether they are using different versions of rules, or taking different paths.