Scott Wiemers (ScottW85)
Not Displayed

Not Displayed
ScottW85 Member since 2021 1 post
Not Displayed
Posted: 3 weeks ago
Last activity: 1 week 5 days ago
Posted: 27 May 2021 10:20 EDT
Last activity: 5 Jun 2021 16:57 EDT

Function pzDeleteAllInstancesOfDeclarativePage, Requestor-level Pages


I have a reference data configuration mechanism in an application which will allow certain users to update reference data which is in the application via data pages. One of those pages depends on specific information directly tied to the currently-logged-in user.  This page is defined as a Requestor-Level Data page.

When an "admin" of this reference data logs in and makes changes, I would like to be able to signal the system to invalidate all copies of this Requestor-Level Data Page, so that, upon reference, each request will re-load the page so that the newly updated configuration is available without each user having to log out and then back in.

Originally, I thought that @pzDeleteAllInstancesOfDeclarativePage() might be a good way to do this, however, general consensus amongst other Pega Professionals that I've spoken with is that, as with most processes, the @pzDeleteAllInstancesOfDeclarativePage() is governed by internal security and the request to invalidate the Data Page will not be carried out beyond the current Requestor -- which I agree makes sense, though I was hoping this was not the case.

Unfortunately, the function definition cannot be opened (or at least I have not been able to open it), and with no documentation and being unable to actually review the code, we have questions.

I believe that we have established that this function will flush Node-Level Data Pages.

So, that is my question:

Will someone from Pega Dev confirm or revise our belief that the @pzDeleteAllInstancesOfDeclarativePage() function is in fact Requestor-safe (and Thread-safe for that matter), or in fact that it will send a system-wide signal to invalidate all instances of the Requestor-Level (and/or Thread-Level) Data Page?

Assuming that the function is Requestor-/Thread-safe, it would be my supposition that, in the event of a configuration change like this, and a desire to invalidate Requestor-/Thread-Level pages across the entire system, the only way to accomplish that would be to make a call the "POST /nodes/{nodeID}/caches/declarative_page/clear" REST endpoint... forcing the entire declarative page cache to be cleared...   (something we would not want to do because we rely on Data Pages for a great deal of processing power, and to invalidate the entire cache would undoubtedly cause noticeable delays on the system for users.

Will someone from Pega Dev also confirm that please?

Thank you in advance, Scott

***Edited by Moderator: Pooja Gadige to add platform capability tags***
Pega Platform 8.5.3 Case Management Data Integration System Administration Lead System Architect