Hi All,
We have a complex page structure where .Charge() Page List.Config() Page Group .ConfigList() Page List .TariffList() Page List We are trying to save entries for TariffList.Instead of creating separate index table for each pagelist and page group, Do we have any other way?We tried referencing multiple things but that did not work for us and while pulling the data we have to make multiple joins to get the data back.
Thanks,
Rashmitha
There is no supported syntax that lets a Declare Index recursively index something like your case.
A Declare Index rule works well when the indexed page or page list is directly reachable from the source page. However, when the structure becomes deeply nested like:
.Charge() // Page List
.Config() // Page Group
.ConfigList() // Page List
.TariffList() // Page List
the Declare Index engine does not reliably traverse multiple nested Page Lists/Page Groups to detect changes in the deepest embedded pages. As a result, updates to .TariffList() often do not fire the Declare Index processing.
Reason - Declare Index monitors changes to the page specified in the indexed page path. It is not designed as a recursive object graph traversal mechanism.
If the business model allows, expose the Tariff objects closer to the work page, for example:
.ChargeTariffs()
instead of
.Charge().Config().ConfigList().TariffList()
Charge
↓
ChargeConfig Index
↓
ConfigList Index
↓
Tariff Index
Although it will introduce multple joins, this is the architecture Pega generally expects for deeply nested structures and scales better than attempting to index arbitrary object graphs.
Instead of relying on Declare Index:
Trigger an Activity or Data Transform on Save/Post Processing.
Iterate through the nested structure.
Save rows into a dedicated index table using Obj-Save or Savable Data Pages.
Example logic:
For each Charge
For each Config
For each ConfigList
For each Tariff
Create Index Row
Save
This gives you complete control over created rows, updates, deletesc composite keys and performance.
Instead of creating separate index tables for each Page List and Page Group level, consider Tariff as a dedicated data class and persisting each Tariff entry directly into a data table. Include the required parent identifiers (such as Case ID, Charge ID, Config ID, and ConfigList ID) in the Tariff record so that all Tariff data can be queried, reported, and retrieved efficiently from a single table without multiple index tables or complex joins.
Exactly, and building on @RameshSangili’s solution. Assuming you are Constellation, you can use the grouping feature to show that hierarchy.
See also Complex Data Visualization with Constellation - Knowledge Share - Pega Forums
Thank you all for your inputs.
Hi All,
As per this link nested pages are supported in declare index Declare Index form - Completing the Indexes tab. Is there any deviation in this case for which the index is not being triggered at all?
