Fields in WorkPage
Could you please help me on this question,
Which one is best practice among creation of multiple properties in direct work page or create a page (Data class mapping) in the pyworkPage ? Here in our application everyone keeps adding the new fields directly in the workpage so I am thinking - would that hit any performance?
Message was edited by: Lochan to add Category
Pegasystems Inc.
IN
Hi Narender, Good morning!
Please note: I'd could be wrong but want learn the community thoughts...however, please find below my opinion...
Hi Narender, Good morning!
Please note: I'd could be wrong but want learn the community thoughts...however, please find below my opinion...
| # | Properties on pyWorkPage | Properties on dedicated Page inside pyWorkPage | Performance | Notes |
| Case - I | Created All Properties on pyWorkPage | --------------- | Slightly lesser to Case II (Creating Properties on dedicated Page inside pyWorkPage) | A straight through read from pyWorkPage when accessed from code/rules |
| Case - II | --------------- | Creating Properties on dedicated Page inside pyWorkPage | Could be relatively more on performance impact when compared to Case - I | The reference to property should pass through pyWorkPage and also through additional page to resolve the property value The additional page will be saved in BLOB The size of clipboard will include this additional page memory |
| Case - III |
Having appropriate properties on pyWorkPage like Booleans, key values (account number) etc... basically work related properties should present on pyWorkPage |
Creating Properties on dedicated Page inside pyWorkPage when needed by creating a right data model/class makes re-usability data (a variable component) that drives the work should be derived from data class for re-usability and easy maintainability. |
the data will be segregated analysing the clipboard will be easy |
Will have the properties/data dictionary in a right composition segregation of specific feature/functional properties onto right functional referenced pages for reusability can be achieved. |
|
I could be wrong but if I've to answer... either the property should be exposed or a database index should be created for query better performance. |
Please share your thoughts/comments, Thank you!
psahukaru
AccentureServices Pvt ltd
IN
Thank you very much Phani,
I got your explanation here. So you would be indirectly suggesting me create properties directly in pyworkPage rather than creating Page and use it and manage.
Pegasystems Inc.
IN
I'd prefer creating work/functional Boolean/key identifier related properties on pyWorkPage and data/rest related on a data class specific page/page group/page list property.
Swiftrinity
NL
There will be no difference in performance. You are not having to loop through a pagelist, and there is no additional database hit. Once you fetch the BLOB, you have all properties, be it directly on work page or, on an embedded page.
The thing to consider here is not performance, but having a clean data model. If the data model is properly constructed, keeping in mind the business logic and possible future scopes, one should be able to group together similar data and then they may be clubbed together under an embedded page.
To give an example,
Bad clipboard structure : .EmployeeName, EmployeeAdress, EmployeePhone, .SupervisorName,SupervisorAdress, .SupervisorPhone
Good structure:
.EmplyeeInfo
.Name
.Adress
. Phone
SupervisorInfo
.Name
.Adress
. Phone
Why the later is good? - because not only it groups together related information, but also you get to reuse the 'Name', 'address' etc properties.
Eclatprime
AU
If you need to show Name Address Phone on reports then it should be property on table(work table) and have external mapping in class rule form as below
.EmployeeInfo.Name to Specific database property