Question
Express Scripts
US
Last activity: 7 Sep 2016 12:06 EDT
Export database from dev and import to higher envs for Pega and its Frameworks
We have Pega Base product, CS framework, HCIF and CSHC framework installed on development environment.
We took a baseline export of the database so that it can be imported into other environments and refer to this export as Gold copy.
The other higher environments are - SYSI, QA,UAT and PROD
SYSI,QA and UAT will be in same database instance and so we have to create unique schema names and owners for each environment.
Since the Gold Copy (from dev) is having references to different schema owner names and schema names - we are trying to come up with a script so that these changes can be incorporated while importing the Gold copy into particular higher environment.
We are getting errors for certain views and procedures as they are referring to the old values from development.
The question is:
- is it safe enough to update the old values from development in the Gold copy with environment specific values?
- Is there any other places in the database that we need to replace/customize for the new envrionment values?
- Is this approach ok to proceed or do we need to run the Pega install utility and start from scratch and add other dependent frameworks as required?
Below is some additional details with regards to Views,procedures.
In order to deploy PEGA software in multiple schemas in a same database, using a finalized “gold” copy, a schema rename was used.
We have Pega Base product, CS framework, HCIF and CSHC framework installed on development environment.
We took a baseline export of the database so that it can be imported into other environments and refer to this export as Gold copy.
The other higher environments are - SYSI, QA,UAT and PROD
SYSI,QA and UAT will be in same database instance and so we have to create unique schema names and owners for each environment.
Since the Gold Copy (from dev) is having references to different schema owner names and schema names - we are trying to come up with a script so that these changes can be incorporated while importing the Gold copy into particular higher environment.
We are getting errors for certain views and procedures as they are referring to the old values from development.
The question is:
- is it safe enough to update the old values from development in the Gold copy with environment specific values?
- Is there any other places in the database that we need to replace/customize for the new envrionment values?
- Is this approach ok to proceed or do we need to run the Pega install utility and start from scratch and add other dependent frameworks as required?
Below is some additional details with regards to Views,procedures.
In order to deploy PEGA software in multiple schemas in a same database, using a finalized “gold” copy, a schema rename was used.
Ex. REMAP_SCHEMA=PEGACIPR:PEGACIAQPIPR So when objected originally owned by PEGACIPR are imported, they are changed to PEGACIAQPIPR.
However, 6 procedures still reference objects as “PEGACIPR”.””, but that owner is now named PEGACIAQPIPR, so the code no longer points to itself.
For the 6 procedures and 4 views, can the owner simply be removed from the code?
Ex
from Select pyLastReservedID into tpyLastReservedID from PEGACIPD.pc_data_uniqueid where pzInsKey = tpzInsKey for update;
to Select pyLastReservedID into tpyLastReservedID from pc_data_uniqueid where pzInsKey = tpzInsKey for update;
PROCEDURES SPPC_DATA_UNIQUEID SPPR_AGGREGATE_USAGE SPPR_SYS_GETINDEXTIME SPPR_SYS_STATUSNODES_SET SPPR_SYS_UPDATESCACHE_FLUSH SPPR_SYS_UPDATESCACHE_GETTIME VIEWS PCV4_WORK_HIST
Thanks,
Murli
***Updated by Moderator: Marissa to add SR Details***
Accepted Solution
Pegasystems Inc.
US
Although not documented (and not officially) in the installation guide, this database copy approach has been used but with the following caveats:
First of all, you may have to fix the invalid db objects (most likely within stored procedures as we have harded schema names in the store procedure code, due to split schema requirement) - it is pretty straightforward you just need to replace the old schema name references with your new ones.
The tricky part is to update envinvironment specific stuff to the new environment, e.g., email accounts, operator ids, system name changes, production level, truncation of cache tables, etc. Unfortunately I cannot find a public document detailing all the steps. So this may not be a good practice to build the prod environment as it is likely some of the lower environment data may be brought in and not being cleaned up.
In my opinion, this approach should be used with caution as there are so many manual steps involved. I would not recommend this approach based on your requirement as you would have to go through the 'tricky part'. On the other hand, if you just need to duplicate an environment homogeneously (e.g., from dev schema1 to schema2 for whatever reason), this approach is fast and easy.
Express Scripts
US
This is for Pega 7.2.1 with CS,CSHC,HCIF frameworks - installed on oracle database.
Update to Procedures and views affected :
PROCEDURES SPPC_DATA_UNIQUEID SPPR_AGGREGATE_USAGE SPPR_SYS_GETINDEXTIME SPPR_SYS_STATUSNODES_SET SPPR_SYS_UPDATESCACHE_FLUSH SPPR_SYS_UPDATESCACHE_GETTIME VIEWS PCV4_WORK_HISTORY PWBV4_CIRCUMSTANCE_DUPLICATES PWBV4_RULE_LOCKING PWBV4_RULE_OVERRIDES
Accepted Solution
Pegasystems Inc.
US
Although not documented (and not officially) in the installation guide, this database copy approach has been used but with the following caveats:
First of all, you may have to fix the invalid db objects (most likely within stored procedures as we have harded schema names in the store procedure code, due to split schema requirement) - it is pretty straightforward you just need to replace the old schema name references with your new ones.
The tricky part is to update envinvironment specific stuff to the new environment, e.g., email accounts, operator ids, system name changes, production level, truncation of cache tables, etc. Unfortunately I cannot find a public document detailing all the steps. So this may not be a good practice to build the prod environment as it is likely some of the lower environment data may be brought in and not being cleaned up.
In my opinion, this approach should be used with caution as there are so many manual steps involved. I would not recommend this approach based on your requirement as you would have to go through the 'tricky part'. On the other hand, if you just need to duplicate an environment homogeneously (e.g., from dev schema1 to schema2 for whatever reason), this approach is fast and easy.
Express Scripts
US
Based on the reply and feed back from on sitepega psa - we ended up updating the procedures and views that were involved. Now we have a gold copy of baseline database containing - Pega foundation, CS,HCIF and CSHC framework.
We can now take this to different environment and customiz the schema names and schema owner names quickly and easily.