Certain features in our older products have dependencies on deployment options and technology choices that work well with an on-premises data center, but present obstacles when used in a cloud operational model. Some of these may be implemented in the database and will not work if migrated to Pega Cloud. Identify any dependencies, implementations, and deprecated or unsupported functionality present in your existing Pega database. Update these to use technology that is supported in Pega Cloud.
Review the output of the Modernization Tool, and the Database Readiness Tool (if required). Also, review the information collected in the Gap Assessment Worksheet to help identify custom database structures and objects which will need to be remediated when moving to Pega Cloud.
Schema Structure and Naming
In older versions of PRPC, all rules and data were stored in the same schema in the Pega database. Beginning in version 7.1.8, a split schema became the default, splitting the rules and data into separate schemas.
This was recommended because rules and data change at different rates – there are many more additions to data than there are rule changes - and have a different number of entries added per time period (weeks, months, quarters). Thus, storing them in separate schema allows the database to be most efficiently tuned for best performance.
The current default database schemas are:
These are the only schema names allowed on Pega Cloud.
Pega Cloud remediation: Rename your schemas to match the default Pega schema names before data migration. Also update any class mappings to match the renamed schemas.
Check for rules that need to be updated to point to the updated schema names. This includes Connect-SQL rules, execute-RDB calls in an activity, or other mentions.
Connect-SQL rules are used when your application needs to run complex Structured Query Language statements such as joins or stored procedures to update or extract information from an external database.
There are two situations where you might use Connect-SQL rules:
- Connecting to your Pega database
- Connecting to external databases
Connecting to the Pega database
For Connect-SQL rules operating on the Pega database, verify that they run on a Postgres database, and point to the correct schema names. Any Connect-SQL rules for other database types will not work correctly, as SQL differs for each database type. Oracle SQL is similar to Postgres SQL, and many of the Connect-SQL statements may work, but they should all be tested. If you wrote these rules for other database types, rewrite them for a Postgres database.
Connecting to external databases
If your Connect-SQL rules are mapped to your data warehouse, or a reference system, or system of record, then your rule must be written for the SQL used by that system. (If your reference system runs on an Oracle database, the Connect-SQL must be written for Oracle.)
Pega Cloud remediation: Verify that the mapping is set up correctly to connect to that database from your new Pega Cloud environment. Because you are connecting out of a secure environment, ensure that your rules are correctly configured to use a secure tunnel (such as a private connection) from your environment to the on-premises or remote system.
There are several types of indexes in Pega Platform software:
- Declarative indexes (Using declarative indexes to improve reporting )
- Index tables
- Database indexes
- Search indexes
Declarative indexes are defined in rules, and are included in the application RAP. Declarative indexes are mapped to Index- classes in the database, and are part of your application. Therefore, you do not need to do any remediation on these rules as part of the migration process.
Database indexes in the source database will be migrated as part of the data migration.
NOTE: One exception to this is if you have defined a particular index that takes advantage of functionality specific to one database type, such as Oracle. Pega Cloud runs on a PostgreSQL database. If you have specific index functionality defined for other database types, rewrite that functionality for a PostgreSQL database.
Custom database objects
Your system might have one or more of these custom database objects in your on-premises system:
- Custom stored procedures
- Custom views
- Custom sequences
- Custom triggers
- Custom functions
In these cases, “custom” refers to an object that was not shipped with the Pega database schema, but that you created and added to your Pega database.
On Pega Cloud, database customizations can only be created and managed using the database tools and functionality in the Pega Platform. If your deployment includes Custom database objects, remediate them, as they may pose issues with updating, functionality, or security risks.
There is no single suggested remediation for the custom database structures, due to the wide range of possible customizations. You should carefully review the action or goal of each customization, and use Pega application functionality to perform that action. For example, if custom views are used for reporting, replace them with Pega Report Definitions.
Always use the database tools available in Dev Studio to change your Pega database, such as to optimize or modify your schema or do change tracking. For more information, see Improving database performance
Function Alias Rules
A function alias rule has one of two types: Java function or SQL expression.
Java function aliases provide natural-language descriptions and prompting for input parameters to an underlying function rule. They can be used in collections, decision trees, when condition rules, Declare Expression rules, and constraints rules.
Java functions are supported in Pega Cloud. They are internal rule constructs; they don’t interact with the environment.
SQL expression aliases provide compact packaging of complex SQL expressions that can be used to query a database, and support the development of report definitions. They are defined in the Embed-UserFunction class.
Pega Cloud Remediation: As Pega Cloud uses a PostgreSQL database, ensure that your SQL expression function aliases are written for the PostgreSQL database. If your Function Alias rules are written for a different database type, rewrite them for PostgreSQL.