Discussion
JP Morgan
IN
Last activity: 6 Apr 2018 19:26 EDT
Upgrading Pega 5.5 to Pega 7.2 using single schema and then splitting the schema
We are upgrading Pega 5.5 to Pega 7.2 using single schema and then splitting the schema.
With reference to guide pega-72-platform-upgrade-guid.pdf. I am some queries/concerns as mentioned below. I would be happy if someone could answer these concerns/queries. Thanks
--------------------------------------------------------------------------------
Step1 : Migrating the rules tables with one database (page 44 & 45)
Use the migrate script to migrate the rules tables and other required database objects from the existing rules schema to the new schema
pega.source.rules.schema=original data schema name
pega.target.rules.schema=new rules schema name
pega.target.data.schema=original data schema name
Note: If pega.target.data.schema is blank, the rules schema is used by default.
Query/concern:
1. why "original data schema name" is mentioned in source.rules.schema and target.data.schema. As per my understanding the target.data.schema should by PEGADATA.
2. Also in this step we are migrating rules table from source.rules.schema to target.rules.schema then why target.data.schema needs to be mentioned?
--------------------------------------------------------------------------------
Step2 : Upgrading the migrated rules schema (page 46)
pega.rules.schema=new-rules-schema-name
pega.data.schema=new-rules-schema-name
--------------------------------------------------------------------------------
Step3 : Generating rules schema objects (page 48)
pega.source.rules.schema=original rules schema
pega.target.rules.schema=new rules schema
pega.target.data.schema=original data schema
Note: If pega.target.data.schema is blank, the rules schema is used by default.
Query/concern:
1. In this step we are generating rules schema objects then why target.data.schema is mentioned?
2. why target.data.schema is mentioned as orginal data schema, shouldn't it the target.data.schema be PEGADATA?
--------------------------------------------------------------------------------
Step4 : Upgrading the data schema (page 72)
pega.rules.schema=new-rules-schema-name
pega.data.schema=original-data-schema-name
Query/concern:
1. In this step we are upgrading data schema then why rules.schema is mentioned?
2. why target.data.schema is mentioned as orginal data schema, shouldn't it the target.data.schema be PEGADATA?
**Moderation Team has archived 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.
Updated: 28 Apr 2016 2:28 EDT
Cognizant
IN
"original data schema" means the existing 5.5 schema that is holding both 5.5 rules and 5.5 data. This schema will eventually become our "7.2 data schema" after the upgrade. It might not be named as PEGADATA in every PRPC application hence the usage of "original data schema" to denote it.
Step1
We need not mention anything for pega.target.data.schema; just leave it blank.
Its not relevant in step1 however its required in step3.
Step3
While 'creating the rules schema objects' the migrate.sh has to know which schema is holding the "yet to be upgraded" data.
Also it needs to know which schema is holding the "upgraded" rules.
Step4
While 'upgrading the data' the upgrade.sh has to know which schema is holding the "yet to be upgraded" data.
Also it needs to know which schema is holding the "upgraded" rules.
Pegasystems Inc.
IN
There could be some properties that can be left empty as Vignesh mentioned, but I have not explicitly tried those.
Below is my properties that helped be successfully migrate from prpc 6 to Pega 7.2.
Migrate Rules
pega.source.rules.schema=original rules schema
pega.source.data.schema=
pega.target.rules.schema=new rules schema
pega.target.data.schema=original rules schema
__________________________________________________________
Generate DDL and Upgrade Rules
rules.schema.name=new rules schema
data.schema.name=
set bypass.pega.schema property to true if we are running the Upgrade Rules step after generating the ddls and running the scripts on the DB.
__________________________________________________________
Generate Rules Schema Object
pega.source.rules.schema=original rules schema
pega.source.data.schema=
pega.target.rules.schema=new rules schema
pega.target.data.schema=original rules schema
__________________________________________________________
Data Only Upgrade
rules.schema.name=new rules schema
data.schema.name=original rules schema
Updated: 2 May 2016 6:49 EDT
Cognizant
IN
Since a single schema upgrade is being attempted; all the 5 schemas properties shown below might be referring to the same schema.
Assuming we are not going to perform a "rules migration to empty schema" (Step ONE) and the name of the existing V5.5 schema is PEGA_ABC ...
pega.source.rules.schema=PEGA_ABC (not significant since rules migration won't happen)
pega.target.rules.schema=PEGA_ABC
pega.target.data.schema=PEGA_ABC
pega.rules.schema=PEGA_ABC
pega.data.schema=PEGA_ABC
Pegasystems Inc.
IN
As per the guide pega-72-platform-upgrade-guide.pdf, for step "Migrating and generating rules schema objects" its mentioned that the following properties are to be set to true:
pega.clone.generate.xml=true
pega.clone.create.ddl=true
pega.clone.apply.ddl=true
pega.bulkmover.unload.db=true
pega.bulkmover.load.db=true
By now, the Rules tables are already migrated and upgraded to the Rules Schema.
Should we not set the above properties to false instead of true else it will re do the creation and applying of rules as well as unloading and loading of the same ?
Also, pega.move.admin.table should be set to false isn't it, as we have already moved the admin table when migrating the Rules?
Thanks
Anand.