Data migration from Pega 8.6 to Pega 24.1.1 recognizes work table as external data table and unable to use pzpvstream

We have a requirement to move the work data from IBM DB2 to MS SQL DB and use the blob data and move the information to another data table. This data table will be used for search purposes for old case information. I have moved the data to MS SQL DB. When I create a work class and map the table. This is considered as external data table and px,py,pz not recognized and able to use only the exposed columns in the work table.

Class X is mapped to foreign data table Y in database PegaDATA, but it contains a px, py, or pz property

Need suggestions/solutions to move forward.I would like to know how pega manages the data migration to pega saas with these scenarios and able to consider the table as internal table?

Note: Exposing the data before migration is an option which I am not looking for.

@NivethaR3993

:warning: This is a GenAI-powered tool. All generated answers require validation against the provided references.

Understanding the Problem

When a work table is recognized as an external data table in Pega, it means that the system doesn’t identify it as part of the internal Pega database structure. This is why you’re unable to use the system columns (px, py, pz) and can only access the exposed columns. These system columns are critical as they’re used by Pega’s data model for proper functioning, especially the pzPVStream BLOB that stores most property values.

Solutions to Make the Table Recognized as Internal

Here are several approaches to resolve your issue:

1. Verify Required Pega Table Columns

Ensure your migrated table includes all the required columns for Pega internal tables:

  • pxObjClass - The Pega Platform class name (typically VARCHAR2(96))
  • pxCreateDateTime - The date column (typically DATE)
  • pyLabel - A short description (VARCHAR2(64))
  • pzInsKey - Primary key (VARCHAR2(255) NOT NULL)
  • pzPVStream - The storage stream (BLOB)

If any of these required columns are missing or have incorrect data types after migration, the table may be recognized as external.

2. Correct Database Class Mappings

The issue might be with how the class is mapped to the database table:

  1. Go to Dev Studio
  2. Navigate to App Explorer > Database > Class Mappings
  3. Locate the class mapping for your work class
  4. Verify that it’s correctly set to point to the internal database structure
  5. Ensure the mapping correctly identifies the table names and schema

You might need to create a new database class mapping or modify the existing one to align with the internal structure expected by Pega.

3. Use the Modify Schema Wizard

The Modify Schema Wizard can help view and adjust the database schema:

  1. In Dev Studio, go to Configure > Database > Database Structure
  2. Use the Modify Schema Wizard to examine your table structure
  3. Verify that your class is properly mapped to the correct table
  4. Check that the system properties (px, py, pz) are configured correctly

4. Run the Column Populator Utility

If the table structure is correct but the data isn’t properly populated:

  1. Use the Database Column Populator tool (Configure > Database > Tools > Database Column Populator)
  2. This can help populate values for system columns from the BLOB data

5. Check for Database Table Instance Rules

Verify that you have the correct Data-Admin-DB-Table instance for your work class:

  1. Look for a Data-Admin-DB-Table instance named after your class
  2. Ensure it references the correct table in MS SQL

How Pega Typically Handles This in SaaS Migrations

When migrating to Pega Cloud SaaS environments, Pega typically employs specialized migration tools that handle these schema and mapping issues automatically. The migration process includes:

  1. Analyzing the source database schema
  2. Creating a compatible schema in the target environment
  3. Ensuring all required system columns are properly mapped
  4. Configuring class mappings to recognize the tables as internal

Next Steps

I recommend trying these steps in the following order:

  1. First, verify the table structure and required columns
  2. Check and correct the database class mappings
  3. If needed, use the Modify Schema Wizard to adjust the schema
  4. Run the Column Populator utility to ensure proper data population

If you’ve tried these approaches and are still experiencing issues, the problem might require a more customized solution based on the specific structure of your data and application.

References:
Hybrid data storage model (pzPVStream BLOB)
Required columns for tables
Data migration
Creating separate tables for child classes
Viewing database tables and Pega Platform metadata