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,
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.
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.)
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.
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
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.
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
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
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?
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