Question
Capgemini
GB
Last activity: 21 Jul 2017 9:57 EDT
Upgrade 62 SP1 to Pega 7.1.8
One of the Pega customers has requested us to perform this upgrade. The customer has below circumstances -
1. We cannot perform an upgrade on existing machine which has thier application ( Pega 62 + KYC ).
2. We have been provided with a new machine having IBM WAS 8.5 which will become their instance post upgrade.
With these limitations in mind we have agreed to below approach.
Step 1. Move a clone of the Application Database Schema from machine A to machine B.
Stepl 2. Next we follow the command line upgrade methods as mentioned in the upgrade guide. Create an empty schema called UPGRADE on machine B.
Step 3. Run migrate.sh and then upgrade.sh on the UPGRADE schema to get upgraded rules schema.
Step 4. Run upgrade,sh on the cloned Application Database Schema to selectively upgrade the Data part.
Step 5. Deploy Pega 7.1.8 archive to WAS 8.5 and configure it to point approrpriate PEGARULES ( schema from step 3 ) AND PEGADATA ( schema from step 4 ).
Step 6. Upgrade KYC 7.13.1 following the upgrade guide for this Pega 7.1.8 instance
Machine B now becomes the new upgraded instance for the customer.
One of the Pega customers has requested us to perform this upgrade. The customer has below circumstances -
1. We cannot perform an upgrade on existing machine which has thier application ( Pega 62 + KYC ).
2. We have been provided with a new machine having IBM WAS 8.5 which will become their instance post upgrade.
With these limitations in mind we have agreed to below approach.
Step 1. Move a clone of the Application Database Schema from machine A to machine B.
Stepl 2. Next we follow the command line upgrade methods as mentioned in the upgrade guide. Create an empty schema called UPGRADE on machine B.
Step 3. Run migrate.sh and then upgrade.sh on the UPGRADE schema to get upgraded rules schema.
Step 4. Run upgrade,sh on the cloned Application Database Schema to selectively upgrade the Data part.
Step 5. Deploy Pega 7.1.8 archive to WAS 8.5 and configure it to point approrpriate PEGARULES ( schema from step 3 ) AND PEGADATA ( schema from step 4 ).
Step 6. Upgrade KYC 7.13.1 following the upgrade guide for this Pega 7.1.8 instance
Machine B now becomes the new upgraded instance for the customer.
Can someone please validate the above approach. I'm more interested to know below -
1. Whether upgrade scripts interact with the filesystem ? In above approach we are dealing with database initially and then in Step 5 WAS comes into the picture.
2. Do we see any issues here in the approach ?
***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.
Accepted Solution
Pegasystems Inc.
US
In between steps 3 and 4 you have to run the migrate script a second time. Even if you are not migrating the UPGRADE schema back to a new RULES schema you still need to create the rules objects and setup the grants between the rules and data schemas.
For Step #6 if that version of the FW came out prior to 7.1.8 then there will be database triggers which is wants to create to update the pr4_rule_vw and pr_sys_updatescache tables. These triggers are obsolete in 7.1.8 as the updating of those tables is now handled by the engine. You do not want to create these triggers in 7.1.8.
I'm not sure what you are asking about the upgrade scripts and the filesystem. The scripts will use the media on the filesystem to boot the engine and connect with the database and then the majority of upgrade will involve updating things in the database. Yes the app server does not come into play until step #5.
Athough you don't outline this above the second pass of the migrate script (step 3B) and for the upgrade of the data schema (step #4) both the upgraded rules schema and the 6.x combined schema which will become your data schema are both involved in these steps.
Is Machine A still running in production and WOs are getting created/upgraded during the time that Machine B is being updated? Essentially as of the moment you copy the data to Machine B anything that happens on Machine A is going to be lost if you are not actually using the data schema from that machine in the upgraded environment.
Capgemini
GB
Thank you Celeste for your reply.
@filesystem related query - The mahcine B will not have an up and running Pega 62 application ( where one can login ) before we upgrade. All we will have is a database schema of the 62 application brought from machine A. I was wondering if the absence of App server and other Pega related folders within it will cause any issues with the upgrade. Once upgraded we will deploy new 7.1.8 archive and will be able to launch the portal and login.
@Steps above - You are correct. After Step 3 I should have a step to Generate Rules Schema Objects by executing migrate.sh on the upgraded rules schema. In step 4. We will upgrade the Data part only of the 6.x combined schema.
As you have mentioned machine A will be down for the period during which we perform upgrade on machine B. Once upgraded machine B becomes the production system.