Migrating triage cases to new tables

Starting from Pega Platform 8.5, the system uses new tables to store complete information about triage cases for Pega Email Bot. To ensure that the email bot works as expected and to improve its overall performance, Pega Platform migrates all of your resolved and open triage cases to a new table during upgrades to version 8.5 or later. Once you begin the upgrade process for your installation of Pega Platform, the system performs the migration automatically in the background using a dedicated job scheduler. If you expose additional properties as optimized columns in the old tables, before you start the upgrade, you must extend the pyPopulateColumnNamesExtension data transform with this information.

If you are upgrading to Pega Platform 8.5, during the upgrade process the system automatically migrates existing email triage cases from the pc_work table to the new pc_work_triage table. As a result, you can later use the email bot to view built-in reports using the information from your triage cases. For more information, see Viewing reports for the Email channel and Database schema for email bot tables.

Upgrading your version of Pega Platform occurs either as an out-of-place upgrade or an in-place upgrade. You perform an out-of-place upgrade on Pega Platform running in Pega Cloud Services. This type of upgrade has almost no downtime. You perform an in-place upgrade for an on-premises or a non-Pega Cloud Services version of Pega Platform. This type of upgrade requires some downtime during the process. For example, a system with 1 million triage cases stored in database tables completes the migration process in the background in approximately 4 hours.

Migration job scheduler

To migrate all resolved and open triage cases to the new pc_work_triage table, the system runs the pyMigrateInteractionCases job scheduler defined in the Work-Channel-Triage class in the background, during your system upgrade. The job scheduler migrates unresolved triage cases first, and once complete, the system migrates the resolved triage cases. The job scheduler migrates 5,000 triage cases to the new table at a time, sleeps for one minute, and then repeats the process until all the data is successfully migrated. In addition, if the job scheduler unexpectedly goes down when it is running for any reason, and some triage cases are not migrated, the job scheduler picks up these triage cases for migration in its next run cycle.

Migration of exposed columns

If you expose additional properties as database columns in the pc_work table and optimize the properties for reporting, you must perform an initial configuration step before you begin upgrading your system. For this purpose, you extend the pyPopulateColumnNamesExtension data transform. If you expose additional custom columns in the pc_work table, you migrate your exposed columns by first defining them in the pyPopulateColumnNamesExtension data transform, and then beginning the upgrade of your system. During the migration process, which runs in the background, the pyMigrateInteractionCases job scheduler optimizes the exposed columns based on what you define in this data transform.

For example, if you previously customize three columns in the pc_work table, the pyPopulateColumnNamesExtension data transform rule to which you add the three custom exposed columns for optimization in the new table appears as in the following figure:

Sample of the pyPopulateColumnNamesExtension data transform rule with three columns to customize.

Note: You can also perform migration of exposed columns using the pyPopulateColumnNamesExtension data transform after the upgrade process completes, provided that the pyMigrateInteractionCases job scheduler is still running in the background.