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 updates to version 8.5 or later. Once you begin the update 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 update, extend the pyPopulateColumnNamesExtension data transform with this information.
If you are updating to Pega Platform 8.5, during the updatee 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.
Updating your version of Pega Platform occurs either as an out-of-place update or an in-place update. You perform an out-of-place update on Pega Platform running in Pega Cloud Services. This type of update has almost no downtime. You perform an in-place update for an on-premises or a non-Pega Cloud Services version of Pega Platform. This type of update 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 update. 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, perform an initial configuration step before you begin updating 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 update 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:
Previous topic Updating the email bot to the 8.5 version Next topic Archiving resolved emails for an email bot (Pega Cloud Services)