Question
Optum
IN
Last activity: 2 Aug 2020 20:03 EDT
Property Optimization wizard available in production
As per Pega Help, Property Optimization wizard will be available only in development environments (production level of the system is 1 or 2 ). But I'm able to see the wizard in stage and production environment with production level as 4 and 5. Can anyone provide clarification on this?
***Edited by Moderator Marissa to update platform capability tags****
Accepted Solution
Updated: 4 Mar 2020 12:51 EST
Pegasystems Inc.
US
Hi Azharuddin,
The later versions of Pega don't have the Property Optimization feature enabled based on the production level. Earlier versions 7.1 and below use to have it. I assume the help doc obsolete or referring to older versions.
Below is the prerequisite as per latest 8.3 help
Before you begin: To expose and populate a property, or to view the status of column population jobs, your access group must have the SchemaPropertyOptimization privilege and the dynamic system setting database/AutoDBSchemaChanges must be true.
As I verified, the property optimization wizard is enabled based on the above privilege irrespective of production level.
Let me know if that clarifies!
Optum
IN
Hi Harish,
Thanks for your clarification. So which is the best approach that we can follow to expose and populate data in PRODUCTION.
1. Property Optimization Wizard
2. Modify Schema + Column Populator Utility in prpcServiceUtils
3. Manual column creation + Column Populator Utility in prpcServiceUtils
Pegasystems Inc.
US
Hi Azharuddin,
It depends on the level of access one can have in production and you pretty much got the order right.
For obvious reasons, the first approach is best considering property optimization detects the context(classes) the property is being used and followed by the automatic column population.
The last approach is less recommended.
Let me know if that clarifies!
Pegasystems Inc.
AU
I would recommend #2 provided by "Modify Schema" you mean "allow Pega modify the schema on import of a RAP archive"
#1 requires a human to be working with Dev Studio to run the wizard ... AND it can sometimes be intricate to ensure the correct property is being optimized. The risk of a human 'doing it wrong' in Production is high enough for this to be undesirable.
#3 requires direct database access which may not be available (e.g. Pega Cloud)
With #2, the schema change can happen at the point of importing the RAP (so long as the RAP specified the Data-Admin-DB-Table instances for the tables that have schema changes). This means that both the import and the column population can be triggered via REST calls, which makes them capable of being orchestrated by a DevOps Continuous Deployment pipeline.
Accenture
IN
With #2, the schema change can happen at the point of importing the RAP (so long as the RAP specified the Data-Admin-DB-Table instances for the tables that have schema changes).
Does this mean Schema change to be in done in lower environment after it has been tested then while taking RAP we have to mention Table pzInsKey, this way schema change can happen at the point of importing the RAP?. Please correct my understanding.
Thanks,
Pegasystems Inc.
AU
@ramakrishnaa7516 Your understanding is correct. Include the pzInsKey of the Data-Admin-DB-Table instance in the RAP and this will package the current Table Schema (not data) from the export environment with the RAP.
On Import, Pega determines the difference between the schema it finds in the import environment, and the target schema it needs to establish from the RAP, and runs DDL to close the gap. Usually, this is adding columns that have been Optimized in DEV, but may also be Table Indexes.