Can you fully qualify Function Aliases?
I created a series of activities to validate various rules on "Save" for functions containing a RuleSet and Library (e.g. @PageExistsWithClass(1,2) should now be @(Pega-RULES:Page).PageExistsWithClass(1,2)). This has, however, caused me to encounter a some issues that are impeding progress going forward.
Function aliases such as @if and @and cannot be fully qualified.
1a. Can we fully qualify function aliases?
1b. If function aliases cannot be fully qualified, how could we dynamically exclude all of these so that they will never appear in the warning message upon validation (without having to hard code each of these individually)?
***Updated by moderator: Lochan to close post***
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Accepted Solution
Pegasystems Inc.
US
Interesting to note that this issue was first identified in Pega-6.3. When you run a rule the first time, it assembles. In 6.3 version, during this assembly time , we would convert this unqualified function invocation to a qualified one. Once this assembly is done , there is no cost difference between unqualified vs qualified. So i am surprised that you could actually notice the performance difference when you converted unqualified calls to qualified ones.
Anyways, thanks for all the inputs here. As mentioned before,some of these function calls are intrinsic (@if and @and) and there are no list of these functions which are accessible.So having a full proof warning message might not be feasible.
Thanks again for all the inputs here.
Pegasystems Inc.
US
Hi,
I am not completely sure of what the requirement is here. Are you creating activities which on rule saves would convert a unqualified call to function ( e.g @PageExistsWithClass(1,2)) to a qualified version (e.g @(Pega-RULES:Page).PageExistsWithClass(1,2)) ??
- Can i ask why you would need to do something like this? Why are you trying to convert these unqualified invocations to qualified ones? Are you having any issues with using unqualified invocations? If so , solving them might be a better solution rather than converting all of these calls to qualified invocations.
- Also , functions such as @if and @and fall under special category of functions (intrinsic functions) . These are special category of functions and if i am not wrong the behavior of these functions are directly inlined into the assembled code. Thats probably the reason why you are not able to convert these calls to longhand
- There is no list of these intrinsic functions which are accessible .
- You mentioned some warning message upon validation. Can you please elaborate on that? Any screen shot of the validation error can also help us understand the situation
- Lastly , can you please mention which version of prpc are you using?
Thanks
Auto-Owners Insurance
US
The requirement is to inform the developer on "save" via warning on the top of rule forms. Nearly all of our function calls were without the complete qualifications and we found a significant performance increase when the function was fully qualified with the ruleset and library. We are currently using Pega 7.1.7
<< Screenshot of the warning >>
<< Screenshot of condition>>
Pegasystems Inc.
US
Thanks Samuel Fox for this information.
When you say significant performance increase, are you talking about performance during @ runtime(when you actually running the rule) or @design time (when you developing/saving rules) ?
Assuming it is runtime,
- When using unqualified invocation of functions, Pega-7 would need to resolve to the correct ruleset and library that this function belongs too. This resolution happens @ runtime
- Once we resolve to the correct ruleset and library for a given function , we cache these results so that any future invocations on this same function calls are faster as we just fetch the results from cache
So in your observations, is it just the first time that you run the rule that references functions using unqualified syntax that it is slow? Or is it always slow no matter how many times you run the assembly?
If it is always slow ,
Thanks Samuel Fox for this information.
When you say significant performance increase, are you talking about performance during @ runtime(when you actually running the rule) or @design time (when you developing/saving rules) ?
Assuming it is runtime,
- When using unqualified invocation of functions, Pega-7 would need to resolve to the correct ruleset and library that this function belongs too. This resolution happens @ runtime
- Once we resolve to the correct ruleset and library for a given function , we cache these results so that any future invocations on this same function calls are faster as we just fetch the results from cache
So in your observations, is it just the first time that you run the rule that references functions using unqualified syntax that it is slow? Or is it always slow no matter how many times you run the assembly?
If it is always slow ,
- Is it just in the dev environment? Or is this slowness observed in production as well? If development , do you guys deal with a lot of functions?
- Are you experiencing this slowness after upgrade to 7.1.7 or was this observed before too?
Anyways thanks for reporting this issue. We would certainly like to deep dive into this to figure out and solve this issue. I guess this issue warrants an SR to figure out slow performance of unqualified invocations of functions.
Thanks
Auto-Owners Insurance
US
The performance hit is at runtime all the time, no matter how many times assembled. Since our recent upgrade from Pega63 to Pega71 we haven't noticed a big performance increase, functions included to my knowledge. This issue was first identified in Pega63.
A fellow developer mentioned did some digging previously and reported the following (hence our move to fully qualifying functions):
A simple baseline test of a very basic activity revealed that approximately 90% of that activity’s execution time was resolution, so the theory was to do the work where there’s only one possible result (as in functions) so that Pega doesn’t have to. In fact, Pega’s documentation recommends this approach for function calls.
Expanding the test, I then took one of our relatively simple screens and changed nearly every function that is invoked on load and leave and ran 10 identical tests, split between declaration and resolution. (We invoke a LOT of functions!) Declaration was consistently faster.
Result: Total average execution time to load and leave of a screen was *reduced* by ~8.8 seconds. Not only was it measurable, it was noticeable.
Accepted Solution
Pegasystems Inc.
US
Interesting to note that this issue was first identified in Pega-6.3. When you run a rule the first time, it assembles. In 6.3 version, during this assembly time , we would convert this unqualified function invocation to a qualified one. Once this assembly is done , there is no cost difference between unqualified vs qualified. So i am surprised that you could actually notice the performance difference when you converted unqualified calls to qualified ones.
Anyways, thanks for all the inputs here. As mentioned before,some of these function calls are intrinsic (@if and @and) and there are no list of these functions which are accessible.So having a full proof warning message might not be feasible.
Thanks again for all the inputs here.
Auto-Owners Insurance
US
We will re-evaluate to see if functions are indeed still giving us performance issues. Otherwise, thank you for the follow up on the intrinsic function calls.