Question
Data Page Scope Example
Can anyone please give me a specific example/scenario for each scope (thread, requestor, and node)?
1. Please use your own words instead of copying and paste things like this (the following information can be found easily. If it answers my question, I wouldn't even post here. There are few and limited resources out there for Pega, Pega team really need to expand the community/collaboration board by giving some real answers using own words, or at least try to explain things in different ways).
Node Level: If we specify a page in node level, then it can be accessed by all the requestors in the particular node. Requestor Level: If we specify a page in Requester level, then it can be accessed by all the threads opened by the requestor. Thread Level: If we specify a page in Thread level, then it can be accessed only by that particular thread
2. Please do not just give me a link due to the same reason -- if I could find the answer by myself, I wouldn't have asked here. I have already read the following post, so please please please do NOT post a link and say "this link will help with your question" (No! they won't help!). If you find a resource that's really helpful, at least add some of your own words regarding my question, please.
The resources I already found:
https://collaborate.pega.com/question/data-page-scope
https://myknowpega.com/2017/05/13/data-pages/
3. so far I can think of some examples for Node.
e.g. fetch exchange rates from a web service and make them available in the application using a data page.
e.g. an online application needs to display all available items for users to view and purchase. In that case, we will use Node scope for the data page that contains all the items.
Back to the question, what would be a good real-life example to illustrate Thread and Requestor?
@ChensuZ5
A Requestor-scoped Data Page is useful when the results of one trip to a data source will be reusable for the duration of the user's session, regardless of how many work items that user works on.
An example is gathering portal display preferences for a user. A Requestor-scoped Data Page assembles this data once per user session after the user has logged in, allowing these preferences to be referenced as needed from this Data Page for any case over the remainder of that user session.
A Thread-scoped Data Page then covers the scenarios where a result set is gathered that must be dedicated to the context of the current case, and would be inappropriate to share to other cases within the same user session.
For example, a Data Page that looks up the Net Worth of the Customer identified in the current Service Case would not be information appropriate to make available to other Service Cases worked on by the same user. So when each Service Case needs its own copy of a Data Page's result set, a Thread-scoped data page is the common approach.
People can often confuse appropriateness of sharing result sets across Threads and Requestors, with their volatility (how rapidly the source data changes). Whilst Node-scoped data pages are definitely good for data that hardly ever changes, highly volatile source data can still be managed using a Requestor-scoped Data Page, configuring its Load Management to consider the result set stale after (say) 5 minutes.
This strikes a balance between the number of (potentially slow) trips made to the data source and the freshness of this data, all whilst minimizing the amount of memory needed to hold the cached data. Consider this in scenarios where it is appropriate for volatile result sets to be sharable across all Threads for a Requestor (cases for a session).
Implementing this as a Thread-scoped Data Page - even with the same small "refresh interval" - in applications with a large number of concurrent users - can still result in a large number of copies of (virtually) the same data held in memory at once, retrieved using a larger number of data source lookups. This impacts the performance of your Pega application. Caching this data at Requestor-level - if appropriate - will consume less memory and make less calls to the database or APIs.