Don't make me cache system-settings...
From the v7.1.8 documentation for Data-Admin-System-Settings...
"If your application includes dynamic system settings that are frequently accessed, you can override the default load activity LoadDataSystemSettings for this Data Page rule [Declare_CachedDataSystemSettings] to include them on the data page rule."
Hold on right there, this is wrong. LoadDataSystemSettings is final. It calls LoadApplicationDataSystemSettings, which can be overridden.
But why should I have to do this in the first place? I was tripped up today for a half-hour trying to summon the right system settings to the "cache."
This is another place where Pega is undermining modularity. There should not be a function getCachedDataSystemSetting(). A caller wants the system setting, and it should be up to the system to check if it's in the cache (and, if not, check the database! The Pega function returns the empty string if not in the cache)
Furthermore I shouldn't have to override LoadApplicationDataSystemSettings in one of my rulesets (which has to be accessible to the accessgroup of the aforementioned Data Page, which could get complicated if more than override is needed). The best design would have a boolean value on the setting rule itself (Cached), which could then direct the engine to handle the caching.
Additionally, for fetching a System-Setting, there should be a Method & a Rule-Alias-Function, so that we could reference the settings directly.
Updated: 3 Aug 2015 15:45 EDT
Pegasystems Inc.
US
FDBK-12074 is now being tracked by the product DOC team.
The FDBK item links to this discussion and emphasizes that Pega code and rule issues, customer use case, and proposed solution need attention by the appropriate Pega product DEV team.
US-96538 has been generated from FDBK-12074 to track the Help topic update.
BNY Mellon
US
Thanks -- any progress on this?
This is affecting me right now -- the design as such is a mess, and I want to know why this was designed such.
Pegasystems Inc.
US
Jon:
US-96538 is still in the Doc backlog as status New.
I've posted a Pulse on the user story asking for an ETA (Pega 7.1.x) for the Help topic update.
I'll keep you posted.
Thanks for your patience.
-Mary
Pegasystems Inc.
US
I thought Data-Admin-System-Settings class (along with several others, e.g., Data-Admin-Operator-AccessGroup) is already cached. The question is, do we have a public API available?
BNY Mellon
US
If it is in 7.1.9, then let me know. But if you look at the design for LoadDataSystemSettings/LoadApplicationDataSystemSettings, you'll see kludgey design.
Pegasystems
US
>>> It calls LoadApplicationDataSystemSettings, which can be overridden.
>>> But why should I have to do this in the first place?
My understanding is that most of the time the answer is "you don't have to do this" because when you change a dynamic system setting, within 10 minutes, it will be updated, and that the only time you would need to over-ride LoadApplicationDataSystemSettings is if you need your change to be seen now rather than in 10 minutes.
Here's an example from my own usage: I maintain a tool that includes a self-test that can be run to make sure the tool is healthy. The tool includes a dynamic system setting for turning the tool on and off. The self-test includes a test of that setting, so it turns the setting off, attempts to run a tool function and makes sure it does NOT function, then it turns the setting on and calls the same tool function and makes sure it DOES function. That self-test needs to rely on its over-ridden LoadApplicationDataSystemSettings in order that the user not have to wait 10 minutes for the self-test to give time for the system to digest the change to the system setting !
/Eric
BNY Mellon
US
Eric - you misunderstand the problem. And your understanding conflicts with what the documentation says: "If your application includes dynamic system settings that are frequently accessed, you can override the default load activity LoadDataSystemSettings for this Data Page rule [Declare_CachedDataSystemSettings] to include them on the data page rule." and with the description for LoadApplicationDataSystemSettings: "Use this activity to allow the function getCachedDataSystemSettings to retrieve your setting."
That's what I was questioning.
This is poor design.
If I add [X}, then the underlying system should manage the cache for it, so when I ask for [X] it should check the cache first. If I change [X], the system should invalidate the cache.
For X=rules, Pega does the cache intelligently, thank you.
For X=D-A-System-Setting, it doesn't, it proposes this system which requires me to update an activity with reference to each cachable element.
Pegasystems
US
hi Jon,
I took a peek on Pega 7.1.9 at the history tab for the LoadApplicationDataSystemSettings extension point, and I see that it refers to nonexistent function getCachedDataSystemSettings, so that is likely to be a typo.
However, please review the history tab for existing function getCachedDataSystemSetting and see if the information there is of use to you.
Thanks. /Eric