"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.
>>> 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 - 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.
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.