What are the considerations for loading Data Pages via asynchronous or parallel processing?

Activities have a Load-DataPage method for when an Activity requires a Data Page to be loaded via background processing, enabling other processing to continue in the Activity until (using the Connect-Wait method) the asynchronously-loaded Data Page results are needed.

A Data Page "DP" with many slow-performing source systems to gather data from might delegate each of those to their own Data Page (D1, D2 ... Dn), and configure the Data Source for DP to be an Activity that uses Load-DataPage on each of D1, D2 ... Dn, and waits for them all to complete before assembling a unified result set. The outcome is:

• All other things being equal, the elapsed time for loading of DP is limited to the slowest of D1, D2 ... Dn; rather than the total of D1 + D2 + ... + Dn;
• The Activity is only needed for orchestrating asynchronous processing: a perfectly valid justification for the ensuing guardrail warning;
• Each of D1, D2 ... Dn are configured as regular (testable) Data Pages that may not need to utilize Activities to source their data, and may also encapsulate their Save Plan if the data is savable by Pega;
• Each of D1, D2 ... Dn can still be invoked synchronously by other use cases that can tolerate latency.

Discussion on this topic was sought from the LSA Data Excellence (Pega 8.4) webinar conducted in July 2020. The webinar and its full set of discussions that arose from it are available at LSA Data Excellence: Webinar, Questions & Answers.