Discussion
Mindtree
IN
Last activity: 6 Apr 2018 19:26 EDT
Pega 5.5 SP 1 to 7.1.8 Upgrade - unidentified property: pySaveAsResults.pyworkbaskets_opid
We are upgrading from 5.5 SP1 to 7.1.8 for one of our client. They performed a single schema upgrade, post upgrade when they try to save as for an existing operator id, they get the below error:
"The page contains an unidentified property: pySaveAsResults.pyworkbaskets_opid".
"The page contains an unidentified property: RH_1.pyworkbaskets_opid". - we get this error sometimes.
When they create a new operator and do save as from the new operator the operator gets created
Question 1: If anyone knows why they are getting this error? What is the possible fix for the issue?
Also their current upgrade approach is to perform the single schema upgrade to 7.1.8, post upgrade install all frameworks into the upgraded pega 7 environment, then use migrate script to split the schema to Rules and Data instead of doing a direct split shema approach. My question here is, if the upgrade approach cause any potentail issues post upgrade?
**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.
Pegasystems Inc.
IN
Is this issue is happenign for all the operators or one particular operator?. After the upgrade did you run the revalidate and save utility? if not please run this utility.
Regarding your second question from single to split schema upgrade. Could you please outline your steps on how are you planning to split?
Thanks,
Dhev
Mindtree
IN
Hi Dhev,
Thanks for your response. This issue is happening for all Operators, we have not run Re validate and save yet. The entire upgrade process is taken care by the client CoE team, they noticed this issue when they logged in post the upgrade of the system. They will be handing over the system to us, post which we will run the re-validate and save. I will let you know if I face any issues post Revalidate and Save.
Regarding the Upgrade Approach, Client Pega team has already done a pega 6.x to 7.x upgrade and they are using the steps from their previous upgrade experience. They are using Installation and Upgrade Assistant (IUA) for the upgrade, Rule Base Cleanup was selected while going through the wizard, they gave rule schema name and Data Schema name as existing 5.5 schema name.
There initial plan was to split the schema now by using migrate script, however there is internal process to create a new schema, so they are planning to go ahead and install the frameworks post which the environment will be handed over to the development team for post upgrade fixes. Once they have permissions to create a new schema, they will take the environment from the Dev team for a day and split the schema at that point.
Do you see any issues with the approach, since they plan to split the schemas after the post upgrade fixes are in progress, also they plan to install frameworks first in the single schema environment.
Hi Dhev,
Thanks for your response. This issue is happening for all Operators, we have not run Re validate and save yet. The entire upgrade process is taken care by the client CoE team, they noticed this issue when they logged in post the upgrade of the system. They will be handing over the system to us, post which we will run the re-validate and save. I will let you know if I face any issues post Revalidate and Save.
Regarding the Upgrade Approach, Client Pega team has already done a pega 6.x to 7.x upgrade and they are using the steps from their previous upgrade experience. They are using Installation and Upgrade Assistant (IUA) for the upgrade, Rule Base Cleanup was selected while going through the wizard, they gave rule schema name and Data Schema name as existing 5.5 schema name.
There initial plan was to split the schema now by using migrate script, however there is internal process to create a new schema, so they are planning to go ahead and install the frameworks post which the environment will be handed over to the development team for post upgrade fixes. Once they have permissions to create a new schema, they will take the environment from the Dev team for a day and split the schema at that point.
Do you see any issues with the approach, since they plan to split the schemas after the post upgrade fixes are in progress, also they plan to install frameworks first in the single schema environment.
Pegasystems Inc.
IN
If I understood right they have done only rulebase in-place upgrade and now they are planning to split the schema then perform the frameworks upgrade. yes this is possible and follow the below steps.
1) Migrate the rules using OOTB migrate script
2) perform generate ruleschema objects
3) upgrade all the frameworks.
Thanks,
Dhev
Mindtree
IN
Thanks Dev.As per my understanding If I run migrate with the following properties set, it should split the schema for me. Or do I need to run first migrate first and then run migrate again to perform generate rules schema objects,
pega.move.admin.table=false
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
pega.rules.objects.generate=true
pega.rules.objects.apply=true
Scotiabank
CA
Hi Chetan,
To answer your first query regarding the operator Id save error,
Please check whether the failed operator id as the "pyworkbaskets_opid" property in the rule xml.
If you have the above property in rule then you can try the following workaround to fix the issue.
- Get the pzInsKey of the operator ID
- Run the activity: @baseclass.FixRecord with pzInsKey of Operator-ID as the parameter "insHandle" and "pyworkbaskets_opid" as the parameter "PropertyName"
- After running the activity check whether the pyworkbaskets_opid property is removed from rule dat
- Re-save Operator ID