Direct class inheritance of Implementation layer Data- and Int- and SvcInt- classes?


I have a framework layer (PCS) and corresponding implementation layer (SBC) with pattern inheritance from division Com. In f/w, the data and int classes are CTS-FW-PCSFW-Data-, CTS-FW-PCSFW-Int- and CTS-FW-PCSFW-SvcInt-

In impl layer the classes are  CTS-Com-SBC-Data-, CTS-Com-SBC-Int- and CTS-Com-SBC-SvcInt-


My question is:

1> Shall  CTS-Com-SBC-Data- be directly inherited from CTS-FW-PCSFW-Data- ? or simply Data-?

2> Shall  CTS-Com-SBC-Int- be directly inherited from CTS-FW-PCSFW-Int- ? or simply Data-?

1> Shall  CTS-Com-SBC-SvcInt- be directly inherited from CTS-FW-PCSFW-SvcInt- ? or simply Data-?

Please clarify. This will clear my understanding of ECS.





**Moderation Team has archived 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.


Keep up to date on this post and subscribe to comments

June 13, 2013 - 7:39am

Thank you for your submission.

In response to your question, the implementation classes are set up to directly inherit from Data- by default. In most situations you are working with subclasses of CTS-Com-SBC-Data- , Int-, or SvcInt- which should directly inherit from their counterparts in the FW classes. When working with subclasses of CTS-Com-SBC-Data- , Int-, or SvcInt-, the directed inheritence path of the subclass object being used is followed and the directed inheritence path of the abstract classes are ignored.


James Adair

Self Study Support


May 11, 2015 - 11:28am

I found this post because I'm struggling with this not for myself, but to explain to others.

Communication is not clear in Pega regarding inheritance across "Data Layers".

If I define Org-FW-XyzFW-Data-Person and I want to define specialized form of Person, e.g. Customer, then I should be defining Org-FW-XyzFW-Data-Customer which has direct inheritance to Person in the SAME layer.

If I wanted to define Customer in a lower layer (another Framework layer or Implementation layer), then it should STILL work the same way. Org-FW-AbcFW-Data-Customer should have direct inheritance to Org-FW-XyzFW-Data-Person. This shouldn't be a question. It is when we ask questions we shouldn't ask is where the problem begins, IMHO. Remember pattern inheritance is optional and it is for inheriting functionality, not reusing (sic) properties. One cannot sacrifice basic OO priniciples just because Pega has pattern inheritance.

When one has Org-FW-XyzFW-Data- the intention behind is that any classes defined at THIS layer serve to define the data model for the corresponding Work Types on which one instantiates these classes. There is a reason default inheritance is to Data-. It is us, the end users of Pega who make uninformed choices.

Classes in one Blah-Blah-Blah-Data- layer are supposed to inherit directly from classes in corresponding higher layers. We should not define properties under on Blah-Blah-Blah-Data- and then we will never have  this problem. We need to recognized Pega provided examples are "Hello World". We need to design and code for "Real World".



May 11, 2015 - 2:38pm

I personally dislike referring to layers as being either "lower" or "higher".  This depends on whether you view the enterprise class structure as less specialized layers/classes at the top, i.e., the enterprise level, with more specialized layers/lcasses at the bottom, e.g., a framework-extending implementation layer.

However when a "Layer Cake" diagram is presented, everything is jiust the opposite ,i.e., the lower layers represent what the higher layers are buit upon as if constructing a building -- the upper floor being dependent on the floor beneath it, so on and so forth until reaching the foundation.

I personally would define both "Person" or "Customer" at the enterprise level hence a common definition exists across frameworks. You could deffine, say, Org-Data-Party-Person that extends OOTB Data-Party then define Org-Data-Party-Person-Customer (pattern) or, instead, Org-Data-Party-Customer that directly extends Org-Data-Party-Person. My preference is the latter.

Each framework application is free to directly extend the enterprise class definiton, for example Org-FW-Data-Party-Person extending Org-Data-Party-Person as well as Org-FW-Data-Party-Customer extending Org-Data-Party-Customer.

But Org-FW-Data-Party-Customer does not pattern-inherit.Org-FW-Data-Party-Person. It would instead have to directly extend that class to see those propertoes.  But if that were done, the "Customer" propertes defined at the Enterprise level would not be visible.

What can be done instead is to add properties to Org-Data-Party-Person within the FW ruleset. Those FW properties would then be found through pure direct inheritance despite the class for those FW-ruleset-added properties being Org-Data-Party-Person.

EX:   Org-FW-Data-Party-Customer  -> Org-Data-Party-Customer  -> Org-Data-Party-Person



May 11, 2015 - 2:30pm

As long as we are communicating the same things :)

Yes Org-FW-Data-Party-Customer does not pattern inherit Org-FW-Data-Party-Person. I never said pattern and clearly the pattern does not match. I used different class names but am saying the same thing. The real problem here is that people see what Pega has done with its internal classes and don't ask questions until it is too late and get confused.

So again, pattern inheritance should not be used for this as you have also suggested. The problem I have is with what Pega does and then does not say. Take a look at Data-. Why define Properties under it? Presumably Pega has done it because all "Data classes" that are named Data-Abc, Data-Xyz should pattern inherit these properties? I don't know, but I sure hope not. I think it is more for Pega to manage things internally, but some of the Properties under Data- seem just all wrong.

My real point, is people see that and THEN conclude they should do things like these...




Then define Org-FW-Data-Person which (obviously!) pattern inherits from Org-FW-Data- and then add more stuff. I know my example is atrocious but without clear direction that is what properties under Data- are suggesting. Any class name that ends in a hyphen is an abstract class. Okay...but why carry that "logic" to data classes? Inherit functionality not state. Access State at run time. At Design time develop a well defined Data Model where arbitrary properties are not defined under Data- or Org-FW-Data- or whatever. That was my point, but I already know selling it to Pega crowd is going to be next to impossible.




May 12, 2015 - 2:13pm

Not saying that I am a biologist by any stretch of the imagination but your argument sound similar to the evolution of DNA.

In the beginning @baseclass.pyCity and @baseclass.pyCountry were sufficient for basic BPM 101 work objects, but for the much more /sophisticated BPM work objects in use today, i.e., cases that can have subcases (that can have...), using properties such as @baseclass.pyCity and @baseclass.pyCountry is not acceptable.

Nevertheless those properties are universally inherited.

Perhaps you could explain these types of pattern-inherited properties as being part of PRPC's "Junk DNA" ?   :- )

May 12, 2015 - 2:32pm

One man's junk is another man's treasure. All I'm saying is without explicit guidelines the uninitiated are left to draw erroneous conclusions. Take a look at properties defined on Data-.(in my version of Pega, your's could be different)

ErrorMessage, IsBulkOperator, OperatorName, OverrideExisting, ProcessOnlyDocs, RowSelected, SelectedOperator, SuccessMessage, UpdatedOperators, VerificationUIClass, VerificationUISection, VerificationValidation.

Which of them is business application data? Looks like properties Pega needs internally. All classes in *this* layer, e.g. Data-DocItem, Data-Gadget, Data-ProcessRequirement to name a few inherit all of the above properties. Now take a look at the Definition tab of these classes. Pega defaults to Data- for direct inheritance. But wait, Data-Gagdet et.al. already pattern inherit from Data-.

So this is how developers interpret

a) all classes by default direct inherit from Data-. Most people leave this alone and that's not too bad.

b) all classes should direct inherit from the same class they happen to pattern inherit from. THIS is a big problem because they end up defining nonsense properties in Blah-Blah-Blah-Data- and then create Blah-Blah-Blah-Data-MyBadObjectDefinition that both pattern inhertis and direct inherits from Blah-Blah-Blah-Data-. Worse all garbage is under Blah-Blah-Blah-Data-


This is harder to explain than it is to see. I've been on many Pega projects and most developers who are ONLY schooled in Pega do not have basic grasp of OO principles or Object/Data Modeling. They only have "Pega Best Practice", some written, some perceived and mostly misinterpreted and come up with ghastly implementations. My only hope is someone at Pega is reading this and comes up with "Best Practices for Data Modeling" which really starts educating people on the basics of Data Modeling and then map it to Pega. I firmly believe Pega can do a lot more in this area which I feel does not get much more beyond lip service in Pega literature or courseware.




May 12, 2015 - 3:05pm

Your point is well taken and well known.

At what point does Pega need to not teach Pega per se but, instead, teach skills and knowledge that can be gained elsewhere - for example Object Oriented Programming (for Dummies :-)?

This was the same argument made in the 90's when "visual" IDEs (Integrated Development Environments) were first introduced, i.e., the easier you make it to write code, the less people need to actually know how to write good code. Then the dot-Com era came along and made things even worse.

But as you said, for those who have done their homework and do understand OOP, perhaps there should be more examples along the lines of:

        given scenario X, the best-practice Data Model would be Y, etc.

Pega could only do this generically; it cannot use real world examples from customers. Plus numerous frameworks currently exist. For example, the 7.1 Practice Build involves Product Warranty Claims yet Pega has a framework for warranty handling.  See PDN -> Products -> Manufacturing -> Pega Warranty.