Posted: 20 Apr 2016 13:11 EDT Last activity: 17 Nov 2016 10:53 EST
PRPC 7.1.9 Expression Builder using functions
We recently upgraded from PRPC 7.1.7 to PRPC 7.1.9 in the upgrade we noticed that the expression builder has changed. I need some help figuring out a scenario that stays within the guardrails of the PEGA platform using the new expression builder (trying not to use the internal PEGA functions) without too much customization, any help would be greatly appreciated. The scenario follows below with screenshots:
First off we have an activity that based off of a when condition will either run the step after (Step 3) or jump to the "FIL" step:
Here is the When condition properties for step 2, this condition looks to a When Rule called SetSIMCardKitted:
Here is a screenshot of the When Rule, this rule uses the PEGA internal function "ObtainValue" (no longer usable with 7.1.9 expression builder) and looks to a Decision Table called "DetermineSIMCardKitStatus", if the table returns "True" then the When Rule evaluates to "True":
The Decision Table that is called returns a "True" or "False" value based off of a client parameter:
I am aware that in an activity we could just set a property based off of the decision table, but we also use these types of When rules in our UI visibility rules as well. I am trying to figure out a new design approach to this type of scenario that stays within the guardrails (minimal customization) as much as possible. The old PEGA internal functions are still able to be used, if you pull up the records you can find them there but its not very effective especially when your not sure of which function you are looking for and the syntax for it.
Generally "internal" would mean that the entity in question may not be documented for client use and can be subjected to change / deletion in future. So, there is a risk involved here when directly calling those kind of rules. But for applications like PEGA, I wonder, it might not mean much as the code doesnt need to run in different versions of PEGA at the same time. You would know when the function is pulled back in future versions during the upgrade smoke test. But one option to avoid the un-necessary routine of fixing broken references is that the developer can choose to duplicate the function in their own library to ensure that the function stays..