Working with the PegaRULES database — Tables for work items

A work pool, defined by a class group instance, causes all work items for an application to be stored in a single shared database table. This sharing is helpful in searching and reporting on work items. With appropriate safeguards, this also allows a work item to be reclassified from one work type to another (when both are in the same work pool). Such reclassification can be a typical, normal aspect of the application workflow, or can indicate that the work item was initially created with the wrong work type.

In development systems (only), the system can automatically create a database table (and associated Data-Admin-DB-Table data instance) each time you create a work pool, whether directly from the class form or indirectly through a wizard or tool such as the Application Accelerator.The structure of the new table is similar to the initial structure of the pc_work table. See More about Database Table data instances.

The pc_work table demonstrates work pools, and serves as a default table for work items. As initially configured during installation, the system saves work items from the PegaSample application and from certain developer tools in the pc_work table.

As a best practice, a dedicated table for work items is desirable for each application, as described below.

If your PRPC system hosts two or more unrelated applications each with one or more work pools, it is usually desirable to store work items for each application in a dedicated table, using the structure of the pc_work table. Keeping each application's work items in a dedicated database table is recommended, because:

• Performance of reports (based on SQL SELECT operations) is improved
• Insert operations are faster as new work items are created
• Different applications may need different properties exposed as database columns

If you create the applications through Application Express or the Application Accelerator, each work pool has a dedicated table named pc_ZZZZZ_Work, which initially is a copy of the pc_work table, and the steps below are not necessary.

If your pc_work table contains work items from two or more unrelated applications, use these steps to segregate work items into a dedicated table:

1. Create a new database table by copying the schema for the standard pc_work table. Be certain to update the CONSTRAINT element in the new table to reference itself, not the old pc_work table.
2. Expose the columns for new properties in the application in the new table or tables as desired.
3. Within the portal, create a database table instance (Data-Admin-DB-Table class) for the class group, referencing the new table.
4. Create a database table instance for the History-ZZZZZ class, where ZZZZZ is the name of the class group, mapping instances to the pc_history_work table.
5. Copy the view definitions pcv4_assignment_summary and pcv4_assignmentwb_summary and adjust them to reference the new tables.

Many wizards and developer tools available in the Designer Studio — for examples, the Application Accelerator and the Product Migration wizard — are implemented as screen flows and create work items in your system. The work types of such work items start with PegaAccel-Task-.

The PegaAccel-Task- class is mapped to the pc_work_accel database table. This ensures that work items produced by developer tools are saved in a dedicated table separate from work items from business applications. Such separation improves reporting performance.

The Pega-Events class and subclasses support the Designer Studio's What's Happening display, RSS feed, and the Recent Actions landing page tab. These classes are derived from the Work- base class. To simplify reporting on work items of your applications, instances of these classes are saved in a dedicated database table, pc_events. See Designer Studio — Working with the What's Happening display

The pc_schedule_task table contains work items for scheduled reports, instances of the Pega_ScheduledTask class. See Report Definitions — Scheduling reports.

Standard reports on work items depend on the exposed columns in the schema of two tables:

• pc_work, for work items
• pc_history_work, for history instances for work items

As initially installed, PRPC stores work items in the pc_work table, and work item history instances in the pc_history_work table. This relationship is defined by the two database table instances Work- and History-Work-.

Reporting on work and work history (such as provided by the links on the Monitor Process workspace) depends on the columns of these two tables.

When a developer creates new work types (and corresponding work history classes) using the Application Accelerator, the system maps the new work classes appropriately into these two tables.

However, when a developer creates a new concrete class using the Class form, the default mapping is to the pr_other table (and the pr_history table, for history). These mappings are not appropriate for work items and may cause SQL errors or JavaScript failures. You can remedy this by adding the two appropriate database table instances.

Two standard database views are linked to the Data-Assignment-Summary and Data-Assignment-WBSummary classes. These support custom worklist and assignment reporting; update these view definitions if you use these views and you change or copy the pc_work table.

This PDN article provides more information on this strategy: 9173 Troubleshooting: instances were not saved in the expected table of the PegaRULES database

The pc_work_dsm_batch table supports work items created through Decision Strategy Manager, instances of the Pega-DM-Batch-Work class.. This table is empty unless you use DSM facilities.

Used internally to support work processing derived from incoming emails.. The Work-ProcessEmail class is linked to this table. See Understanding email-based work processing.

If an appropriate data table mapping is undefined for a work type (or an entire work pool), the system saves the work item in the pr_other table. This is undesirable except in rare cases where only a few, rarely searched work items are expected. To notify developers or system administrators that work items are saved in that table, the system creates a PEGA0041 alert.