Custom Function Validation in Sections - undefined property error
I am attempting to create validation for the following path for a section rule. In drilling down far enough, I'm encountering a page list that I'm not able to validate the contents of. Specifically, I'm attempting to iterate through the PageList .pyActivityParams (see below for the full path). However, the farthest I can seem to go down is .pyActionAPI and .pyActivityParams appears to be inaccessible.
=== The path of the PageList we're attempting to validate ===
Pages must be defined on the Pages and Classes tab.
Property Embed-.pyActivityParams is undefined.
***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.
Looks like your validation is attempting to run on the abstract class of the pyActivityParams. You need to define the specific class of pyActivity params you want to validate (ex. Embed-DesktopAPI or Embed-PagesAndClasses).
I might need a little more context to better understand your scenario. However, I created a simple one-step activity that does a Start-Validate on the property path you provided above. When I define the full path on the Pages & Classes tab like so:
I do not get an error when I save.
One thing I noticed that may or may not be related, or may cause you other problems, is the path you provided above is inferring .pyTable() is a page list. It is actually a single page property and, as such, shouldn't have any brackets.
FYI. Still digging into this. This is definitely reproducible on my end. Not quite ready to pull the trigger on calling this a bug yet. But I think I have it narrowed down to the fact that the pyActions() page list of class Embed-Control-Mode-Behaviors defines the pyActionAPI category as an abstract Embed- class. This is because there are different page classes of pyActionAPI. And it would seem that, even when I specifically define pyActionAPI to be of class Embed-DesktopAPI on my activity's Pages & Classes tab, it is validating against the Embed- instance of the property.
Unfortunately, I tried a few more things and ran them by a couple of people in product engineering, and it doesn't look like there is much you can do on your end to workaround this issue.
As I mentioned above, the pyActionAPI page property defined under pyActions is set to an abstract Embed- class to allow for different class types of the same property to be instantiated. Even when I explicitly define the page class in the activity, the validation is running against the abstract class, which does not have the pyActivityParams page list property defined, hence the "undefined property" error. Because these are all reserved name properties in Pega- rulesets, there's little that can be done without exploring the most feasible options for addressing the issue on our end.
If I'm not mistaken, there may already be an SR raised for this issue. One of my colleagues will update the SR to reference this discussion thread to avoid starting at square one. We'll make sure it is assigned to the appropriate team to further explore the best options for resolving this issue with you.
Once resolved, we'll circle back to this discussion and communicate the resolution for other community members to benefit from in the future.
I take that back. I believe I discovered a workaround. It may not be the prettiest solution, but you could certainly try it and see if it works.
On Pages & Classes, define a tempActionAPI page of type Embed-DesktopAPI. Do a page-copy of .pyActionAPI into tempActionAPI. Since the tempActionAPI is a newly instantiated clipboard page of your own making, you'll avoid the Embed- validation issue and can iterate on tempActionAPI.pyActivityParams and do whatever logic you need. Assuming as part of the validation you'd be setting messages, once your iterations complete, do a page-copy of tempActionAPI back into .pyActionAPI and discard the temp page.
Here's a rough outline of what the activity would look like, of course minus your actually validation logic...
Anyway, like I said, may not be the prettiest workaround. But I'm pretty sure it would work. If you want to try this and it works for you, let us know and we'll close out the SR. But I certainly wouldn't begrudge you if you want to continue on with the SR.
The solution suggested works, thanks! This is a good temporary solution, but I don't think this is something we will want to continue to have to use if this comes up again. We won't need an SR for this scenario, but I wouldn't mind there being an enhancement request for this to prevent this from being an issue in the future.
Glad to hear that works for you. I'll take care of the enhancement request for you.
Truth be told, I'm still going back and forth as to whether to enter it as an enhancement or a bug. I *understand* why it's working the way it is, but trying to decide if that's the way it *should* work and this is kind of a unique case or if it's truly is more of an enhancement.
Either way, I'll update this thread with the FDBK/BUG ID when I enter it.