Close popover
Lee Pederson (pedel)
Global Tech Enablement, Principal Instructor - LSA
Pegasystems Inc.
pedel Member since 2009 9 posts
Posted: January 26, 2018
Last activity: October 22, 2018

Bridging data classes that have different "package" names

The 7.3 LSA course strongly advises to add properties to Foundation application-supplied Data classes as-is, not wrap them or extend them per highlighted note below:

Note: It is not a best practice to use a custom data model or wrap the foundation data model. The best practice is to leverage the foundation data model and embellish it as needed.

Suppose a customer-developed class has (A) already been used in multiple applications and (B) contains basically the same type of information as a foundation data class such as details about a work party. What then?

Had the foundation application come first, a class such as PegaFS-Data-Party-<Org>-<App> could be defined, where: <Org> represents enterprise-wide extension and <App> represents application-specific extension beyond that. Note how this data class’s name makes it obvious to developers that it stems from a Pega Foundation-defined class.

This is similar to what you would do in java where a class name is formed using: <package name> + “.” + <object name>. It is generally considered poor practice for a class in one package to directly extend a class in a different package. Doing so makes it appear that the second package has “co-opted” the first package. In Pega you can use pattern inheritance to acknowledge the extending class’s origin while not having to separately declare a package name.

Back to question regarding how to deal with classes that do not share the same root / prefix / stem. Unlike java, Pega does not support Interfaces. Imagine being able to comma-delimit class names in a rule’s Pages & Classes. This would result in confusion. If the same-named rule were applied to two classes that have different roots, which should be used?

Changing a step page's pxObjClass at run-time to something that is not in the inheritance path of what is declared in Pages & Classes for that page’s name is far too risky, What you can do instead is call two separate rules using the same step page, the class of another page being “cast” by supplying a Page Name parameter. For example, in the first rule that is called Param.CustomerParty = Org-Data-Customer, in the second rule that is called Param.CustomerParty = PegaFS-Data-Party.

Feel free to comment if agree, disagree, and/or have something to add.

Low-Code App Development Data Integration Java and Activities
Moderation Team has archived post,
Close popover This thread is closed to future replies. Content and links will no longer be updated. If you have the same/similar Discussion, please write a new Discussion.