Moving a class's properties
Hi all,
I put together a small project in Pega 7.1.7, as a "learning exercise". One thing I learned, after putting it together, was proper class structure. Specifically, when to put things in "-Work" and when to put them in "-Data".
Before I learned that distinction, I put this project together with its basic data elements in -Work. As in,
-Work-(Project)-
Department
Due Date
Project Number
etc.
Instead of creating a -Data class and having the -Work reference a Page property of the -Data.
Now that my project is basically done - including sections, flows, etc. that reference the -Work-(Project) properties, is there any tool available to globally refactor something like this, into a proper -Data class/properties, and change all the related references? Or, am i stuck with my original design and just have to use the -Work-(Project) properties now that they are "baked in"?
Thanks in advance!
***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
Hi Jim,
If I understand what you're asking, the tricky thing is you don't want to refactor everything, just the bits that you wish you'd placed in a Data- class. Of course you also want to refactor references to them since they need to also point to the new Data- versions of those rules. I don't know a way to systemically cherrypick the bits you want to move. That is why building the correct data structure up front is critical, since you're going to need to either live with it or do a fair amount of work to correct it. The good news is that your learning exercise succeeded in teaching you some valuable things. The bad news is you've got an application who's foundations were built by a beginner. There are certainly things you could try that might help with some of the work, like moving your application to a different system and renaming the classes as Phani suggested and deleting the bits you want to keep in Work- and then moving the remainder back. You'll still have a fair amount of work gluing things back together, removing Work- versions of rules moved to Data- and so on.
Thanks,
Mike
Pegasystems Inc.
IN
Hi Jim, Good Morning!
Could you please try 'Rename a Class' wizard accessible via DesignerStudio --> System --> Refactor --> Classes [classes starting with Pega as string need PegaDeveloper role].
Post running the wizard following are the items to double check...
- Class Inheritance
- Access Group pointing to new class name...[if work class is renamed]
- The class definitions of the Page/Page List & Page Group properties
- Pages & Classes, Design [Work Class], Security and Process [Privilege Class] tabs
- Class Key referenced calls in the activity steps.
- Decision rules dependent on class string.
- Section rules using PAGE references
- Have to manually update the Database table mapping [Data-Admin-DB-Table instances, if any]
- finally search for the old class name from the search box as a quick test. If any traces exists use 'Delete a class' wizard.
So, listing the class name referenced rules - prior running the wizard would help as a double check between manual theory & system behavior.
Look forward to the community thoughts, Thank you!
psahukaru
Centene
US
This doesn't really seem to address my needs, but thanks Phani. I am looking for a more comprehensive solution to move my data elements out of my Work- object into a Data- class...including all references to all fields across Pega-land (Decision tables, activities, etc.)
Accepted Solution
Pegasystems Inc.
US
Hi Jim,
If I understand what you're asking, the tricky thing is you don't want to refactor everything, just the bits that you wish you'd placed in a Data- class. Of course you also want to refactor references to them since they need to also point to the new Data- versions of those rules. I don't know a way to systemically cherrypick the bits you want to move. That is why building the correct data structure up front is critical, since you're going to need to either live with it or do a fair amount of work to correct it. The good news is that your learning exercise succeeded in teaching you some valuable things. The bad news is you've got an application who's foundations were built by a beginner. There are certainly things you could try that might help with some of the work, like moving your application to a different system and renaming the classes as Phani suggested and deleting the bits you want to keep in Work- and then moving the remainder back. You'll still have a fair amount of work gluing things back together, removing Work- versions of rules moved to Data- and so on.
Thanks,
Mike
Centene
US
Oh well (sigh). Not quite as good as other development tools, where this is a relatively easy thing to do. Thanks for the info, though, Mike Townsend
Pegasystems
US
Hi Jim,
I’m kind of interested in how you are deciding which properties you want to be “work” ones and which are “data” ones. Can you show a few examples of properties you have that you want to move, and perhaps some examples of ones you don’t want to move ? /Eric
Centene
US
Eric
Since I did this as a learning project, I started it before I understood the concepts of Work- and Data- areas. So my first case's main data model was all done in the Data Model section of the Work- area. Things like the name, dollar value, processing instructions, etc that are all the data about the case being entered. For later things, I made Data- classes and created Page properties, but initially i did this stuff in Work-, and created sections and other things that referenced Work- instead of Data-.
Is that a big deal? I thought it would be wise to put "getters/setters" type of things in Data-. But I realized that AFTER I had built a working prototype.
Pegasystems
US
I would think you’d want things that vary from one work object to another to be stored in properties defined on the work class, and things that don’t vary from one work object to another to be defined in a data class.
For example, if each work object represents a pizza order, the name of the driver who will deliver that order would make sense to store on the work object.
But if there are hundreds of orders, and are all handled by a choice of five different drivers, and each driver drives a car with a particular license plate, it might make more sense to store the license plate info in the data class since when driver 1 handles orders 2 and 7, his license plate number is necessarily the same for both orders. /Eric
Centene
US
Eric
See the picture here. I should have put all these elements into a Data- class, correct? And then had a Work- item with a property of that Data- class, type "Page"?
Pegasystems
US
Hi Jim,
No, I'm not sure you'd want all of those things in your data class. For example, cancelation reason would be something I would expect to vary from work object to work object so I would think it would be in the work class. /Eric
Centene
US
Eric
OK then, I guess I am really confused then. During our training, it was pretty much suggested that our "data elements" are done in a Page property on Work-, and then spelled out in a Data- class. Wouldn't EVERY value vary from work object to work object? I can't think of many values that are the same across all work object/cases?
Pegasystems
US
Many values are the same across all work objects. I gave the example where although the driver assigned to each pizza delivery varies across each delivery order (choice of 5 different drivers), the license plate associated with driver 1 is not likely to vary since he always drives the same car.
Here’s another example: If each work object is an insurance claim, the name of the customer who is filing the claim will change for each claim and hence the customer’s name is appropriate to store on the work object, but the year of birth of that customer will not change, so storing the birth year in the data class may be more appropriate. If it is useful to have the customer’s birth year appearing on the insurance claim, then having a read-only property on the work object that holds the customer birth year would be appropriate, and that property should be populated from the data class.
To introduce a page property such as you mentioned, instead of having a single-value read-only property for birth year on the work object, you might have an entire page property on the work object that is read-only and populated from customer information read from the data class. For example, the page property might be called .customerPersonalData and some of its individual properties might be .birthYear, .homeAddress, .emailAddress. /Eric
Centene
US
From our SAE II Lesson Reference:
In PRPC, data objects are represented using data classes. Data classes are just like other classes except that they inherit from the Pega standard
class Data-....You can think of a data class as a template for how you want the data to be structured.
Data classes use properties to represent the data elements in a data object.
That makes me think of Data- classes as somewhat (somewhat) analagous to "getters/setters"...