Alternative for Custom Java Code Functions

User Experience
1

This design review seeks guidance and validation on an implementation approach involving multi‑level embedded Page Lists with interdependent business logic. The current solution meets functional requirements but relies on custom Java, and clarity is requested on whether a more declarative or Pega‑aligned approach exists.

Data Model Context

The case data model includes the following embedded structure:

  • LoadCharacteristicsList

    • UnitsList

      • LoadsList

      • Additional embedded lists present at the same level as LoadsList

The logic spans multiple embedded levels and requires aggregation and UI restrictions based on user input.

Requirement 1: Gas Pressure Aggregation

GasPressureRequired is a property defined at the LoadCharacteristicsList level.
It must always reflect the maximum Delivery Pressure across all underlying embedded lists, including LoadsList and other sibling lists within all Units.

Current Design

  • Declare Expressions configured at individual list levels to compute the maximum Delivery Pressure per list.

  • A custom Java function implemented to determine the maximum value across all list‑level results and set it at the UnitsList level.

  • A final Declare Expression aggregates values across UnitsList and populates GasPressureRequired.

Requirement 2: Dynamic Table Visibility and Row Restriction

Within LoadsList, a table captures Load Type and Number of Devices through User Input.
Based on the selected Load Type:

  • A dependent table is conditionally displayed.

  • Users are restricted to adding rows up to the specified Number of Devices.

Current Design

  • Table visibility controlled via When rules based on Load Type.

  • A custom Java function retrieves the Number of Devices for the selected Load Type.

  • A When condition restricts row addition by comparing the dependent Page List length against the value returned by the Java function.

Design Review Discussion Points

  • The solution currently depends on custom Java to support aggregation and row‑restriction logic across embedded Page Lists.

  • Due to the deeply embedded and interdependent nature of the data model, suitable declarative or other PEGA alternatives could not be clearly identified during implementation.

Guidance Requested

  • Confirmation on whether custom Java is justified for the above requirements.

  • Recommendation on any PEGA patterns, declarative constructs, or supported design approaches that could replace or reduce custom Java usage in such scenarios.

  • Alignment with best practices for handling cross‑level aggregations and UI constraints in embedded Page List structures.

2

Can we try creating new calculated fields (declare expressions) at the parent level? These fields can calculate based on the sibling pagelist values. For ex, Units can have a new field say MaxValue which determines maxium value across all sibling lists and populate that field decaratively.

1 Like
3

Hi
Under UnitsList, I have LoadsList and along with that 8 other Pagelists
for Loadslist and 8 other pagelists I created, 9 different properties to get the max value from each individual pagelists, among those 9 properties can it be used to find the max and set it to a max property in unitslist, i couldn’t figure out a way other than java code
if you can suggest, please provide me with a reference

4

Hello Priyam, Absolutely that can work. I assume all of those 9 properties are in UnitList Item level. So Unit class can have a maxValue field which can be set to Max of first 2 fields. And then for the remaining 7 fields, individually you can check if they are higher than MaxValue, if yes replace the MaxValue with higher value. So at any point MaxValue will be largest known at that point. In the end it will have final largest value. You can use expression builder and inbuilt function instead of custom function if you want it declaratively like below

@max(
    @max(
        @max(.Prop1, .Prop2),
        @max(.Prop3, .Prop4)
    ),
    @max(
        @max(
            @max(.Prop5, .Prop6),
            @max(.Prop7, .Prop8)
        ),
        .Prop9
    )
)
5

I would say that custom Java is entirely justified in cases like this, so long as it is nicely wrapped in a reusable Function and performs a single, well-defined operation. Whilst it is generally recommended to minimise the amount of custom Java we write, it is by no means forbidden and in specific, well-articulated cases there is no issue with using it. In particular I would absolutely advocate for some simple, clear Java rather than writing a long, complex expression especially where they are going to be called both declaratively and iteratively - it’s easy to create massive declarative networks that can seriously impact performance when they are frequently recalculated.

6

@Priyam I asked some of our community about this when rule and hierarachy proble. @kopyp and @AndreasL17691108 kindly suggested two other approaches to looking at data in the level above using when rules:

  1. create data transform which will iterate over list (iterating recursively for embedded lists) and for every item will set property keeping reference to its parent e.g. for 1.2.1: .ParentReference=“pyWorkPage.List(1).List(2)” then use that reference as paramter for function @Utilities.pxCallWhenUsingPage(, .ParentReference, “true”) OR
  2. Slightly evolved version of above without need to keep parent page name persisted: @Utilities.callWhen(tools,“whenRuleName”,@pxGetParentPage(myStepPage))