Merging 7.2.2 and 7.4 data schema
Hello Everyone,
We have PEGA applications in 2 different version, those are 7.2.2 and 7.4.
We are upgrading 7.2.2 to 7.4 and merging the existing and upgraded 7.4 data schemas.
But we are facing some challenges like, there are few tables which has same primary key but different data for other columns and those tables are from PEGA.
Any suggestions how we can proceed?
Is it safe if we ignore data from below tables while merging?
|
Tables having same PK and diff data |
|
IIF_SICFACTOR |
|
PBI_JURISDICTIONSECONDARY |
|
PC_DATA_UNIQUEID |
|
PC_SCHEDULE_TASK |
|
PC_WORK_ACCEL |
|
PC_WORK_SOCIAL |
|
PI_DATA_CONNECT |
|
PR_DAILY_USAGE |
|
PR_DATA_ADMIN |
|
PR_DATA_DMS_PURCHASE |
|
PR_DATA_FILE |
|
PR_DATA_MOBILE_DEVICE |
|
PR_LOG |
|
PR_OPERATORS |
|
PR_PEGAINS_DATA_PAYMENTCODES |
Hello Everyone,
We have PEGA applications in 2 different version, those are 7.2.2 and 7.4.
We are upgrading 7.2.2 to 7.4 and merging the existing and upgraded 7.4 data schemas.
But we are facing some challenges like, there are few tables which has same primary key but different data for other columns and those tables are from PEGA.
Any suggestions how we can proceed?
Is it safe if we ignore data from below tables while merging?
|
Tables having same PK and diff data |
|
IIF_SICFACTOR |
|
PBI_JURISDICTIONSECONDARY |
|
PC_DATA_UNIQUEID |
|
PC_SCHEDULE_TASK |
|
PC_WORK_ACCEL |
|
PC_WORK_SOCIAL |
|
PI_DATA_CONNECT |
|
PR_DAILY_USAGE |
|
PR_DATA_ADMIN |
|
PR_DATA_DMS_PURCHASE |
|
PR_DATA_FILE |
|
PR_DATA_MOBILE_DEVICE |
|
PR_LOG |
|
PR_OPERATORS |
|
PR_PEGAINS_DATA_PAYMENTCODES |
|
PR_SYS_USER |
|
PR_USAGE_SUMMARY |
|
PBI_JURISDICTIONPRIMARY |
|
PR_DATA_DMS_CUSTOMER_DATA |
|
PR_DATA_DMS_DEVICE |
|
PR_DATA_DMS_SUBSCRIPTION |
Thanks,
Divya
Pegasystems Inc.
IN
Here the details for the PEGA platform related tables
| PC_DATA_UNIQUEID | pc_data_uniqueid table corresponds to the Data-UniqueID class, and contains a single row for each work item ID format in use. |
| PC_SCHEDULE_TASK | A scheduled report is a work item (of work type Pega-ScheduledTask ), with prefix PX-ST-, saved in the database table pc_schedule_task |
| PC_WORK_ACCEL | Many wizards and developer tools available in the Designer Studio — for example, the Product Migration wizard — are implemented as screen flows and create work items in your system. The work types of such work items start with PegaAccel-Task-. The PegaAccel-Task- class is mapped to the pc_work_accel database table. This ensures that work items produced by developer tools are saved in a dedicated table separate from work items from business applications. Such separation improves reporting performance. |
| PC_WORK_SOCIAL | Pulse messages will be stored in pc_work_social table |
| PI_DATA_CONNECT | https://docs-previous.pega.com/system-administration/86/data-object-tables |
| PR_DAILY_USAGE | PR_DAILY_USAGE table Stores daily usage summaries (Log-License-Usage-Daily class) on requestor and background process use of rules for license compliance. |
| PR_DATA_ADMIN | Data-Admin-Nodes" "Data-Admin-System" "Data-Admin-Security-AuthenticationProfile" "Data-Admin-OAuth2-IdentityMapping" "Data-Admin-System-AuthPolicies" "Data-Admin-OrgDivision" "Data-Admin-Requestor" "Data-Admin-Operator-AccessGroup" "Data-Admin-System-Settings" "Data-Admin-WorkBasket" "Data-Admin-DataFlowScheduler-Aggregation" "Data-Admin-ServicePackage" "Data-Admin-RequestProcessor-Service" "Data-Admin-WorkGroup" "Data-Admin-ServiceType" "Data-Admin-Security-OAuth2-Provider" "Data-Admin-Organization" "Data-Admin-Security-Token" "Data-Admin-Calendar" "Data-Admin-Security-Keystore" "Data-Admin-AppID" "Data-Admin-OrgUnit" "Data-Admin-AuthService" |
| PR_DATA_DMS_PURCHASE | DMOrg-DMSample-Data-Purchase |
| PR_DATA_FILE | Instances of the Data-Content-Image class are associated with the pr_data_file table.https://docs-previous.pega.com/system-administration/86/data-object-tables |
| PR_LOG | Default table for log instance |
| PR_OPERATORS | Operator id instances used for loging to application |
| PR_SYS_USER | Contains one row for each rule delegation, corresponding to instances of the System-User-MyRules class. |
| PR_USAGE_SUMMARY | Pega OOTB stores Regular and Occassional Users information Monthly Wise in the OOTB Table pr_usage_summar |
| PR_DATA_DMS_CUSTOMER_DATA | DMOrg-DMSample-Data-Customer |
| PR_DATA_DMS_DEVICE | DMOrg-DMSample-Data-Device |
| PR_DATA_DMS_SUBSCRIPTION | DMORG-DMSAMPLE-DATA-SUBSCRIPTION |
You can skip merging of pr_log,pr_daily_usuage and PR_USAGE_SUMMARY tables as they are performance stats and logging related tables.
PR_DATA_DMS_CUSTOMER_DATA,PR_DATA_DMS_DEVICE,PR_DATA_DMS_PURCHASE and PR_DATA_DMS_SUBSCRIPTION are related to Pega DMSample application you can query the table based on pxobjclass. This sample data would already be available in target pega 7.4 and can be ignored.
PR_OPERATORS
Contains the data instance of operators used to login to application. if the operators logging into both the applications are unique then you would not have any problem in merging them. however, if the same operators login and use both the applications then you can skip merging at table level and just write an activity to update the accessgroup reference for the new application to existing operators.
PC_DATA_UNIQUEID
Are the work id prefix same or different for both the applications? This is very important table which helps pega platform to determine the next work item id to be assigned based on the pyprefix.
You would have to analyze the data on both the source and target environment and perform the merge.
PR_DATA_ADMIN
If you already have the application deployed and instances related to Data-Admin-Nodes" "Data-Admin-System" "Data-Admin-Security-AuthenticationProfile" "Data-Admin-OAuth2-IdentityMapping" "Data-Admin-System-AuthPolicies" "Data-Admin-OrgDivision" "Data-Admin-Requestor" "Data-Admin-Operator-AccessGroup" "Data-Admin-System-Settings" "Data-Admin-WorkBasket" "Data-Admin-DataFlowScheduler-Aggregation" "Data-Admin-ServicePackage" "Data-Admin-RequestProcessor-Service" "Data-Admin-WorkGroup" "Data-Admin-ServiceType" "Data-Admin-Security-OAuth2-Provider" "Data-Admin-Organization" "Data-Admin-Security-Token" "Data-Admin-Calendar" "Data-Admin-Security-Keystore" "Data-Admin-AppID" "Data-Admin-OrgUnit" "Data-Admin-AuthService"
are already available then you dont have to merge this table. Rather use Product rule to package the specific instance not available and import them
Details on other tables are already mentioned above. you would be in better position to make a call on what is required for your application to function and perform selective move based on the data already available in pega 7.4 application you are performing on to.