Remediating legacy database structures
Certain features in our older products have dependencies on deployment options and technology choices that work well with an on-premise data center, but present obstacles when used in a cloud operational model, and will not work if migrated to Pega Cloud.
There may be a number of legacy technology choices which are implemented in your database. You must update this functionality to current Pega features, in order for your application to run correctly in the Pega Cloud Services environment.
Custom schema names
In an on-premises installation, you could create other schemas and name them whatever you want. For the standardized installation on Pega Cloud Services environments, the schema names must be the defaults only. (See Schema structure above for details on the default schemas.) Any custom schema names – schema names other than those listed above – are not supported, as the ability to add a custom schemas is not available through the Pega application database functionality.
Pega Cloud remediation: Rename your schemas to match with the default Pega schemas.
IMPORTANT: Custom schema names will not affect just the database structures, but also various rules. If there are any references to the schema names, such as Connect-SQL rules, an execute-RDB call in an activity, or other mentions, those will also have to be corrected to point to the correct schema reference.
Custom database objects
There are a number of custom database structures that our clients have implemented in their on-premises systems. You might have one or more of the following:
- Custom stored procedures
- Custom views
- Custom sequences
- Custom triggers
- Custom functions
In these cases, “custom” refers to a structure that was not shipped with the Pega database schema, but that you created and added to your Pega database.
These custom database structures are not supported in a Pega Cloud Services environment, due to issues with upgrading, functionality, and security risk.
One of the main benefits you receive from running on Pega Cloud Services is that Pega manages the upgrade process. See Understanding the Pega Cloud Services software upgrade process.
In order to provide smooth upgrades in the Pega Cloud environment, the Pega application must be “aware” of all customizations – in other words, all customizations should be accomplished through the Pega application interface. If a customization, such as a stored procedure, is added manually through the back end, then there is no record of that change in the Pega application, and it will be overwritten and lost during an upgrade process.
In addition to issues with upgrades, manual custom changes to databases can cause other issues. If a custom stored procedure is not written correctly, then when it is triggered, it could run out of control, overwrite data, or cause performance issues if it runs in an infinite loop.
Custom changes could also change or delete structures that Pega relies on. This could also cause issues and prevent a smooth upgrade process.
If you allow custom changes to your database, then one or several of your users have access to make direct command-line changes to the database. In Pega Cloud Services environments, this access is a security vulnerability. Pega Cloud Services provides a secure environment, and therefore does not allow direct client access to the database.
There is no one 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 purposes, they can be replaced by Pega Report Definitions.
For the most efficient and secure administration of your application in a Pega Cloud Services environment, always make changes to your Pega database by using the Database tools available in Dev Studio to optimize or modify your schema or do change tracking. For details, see Database administration and performance.