Cases are the primary units of processing in applications that use flows. A large fraction of database processing involves creating and updating cases. Updates to related objects, such as assignments and attachments, usually also require updates to the case.
As configured during installation, Pega 7 Platform saves cases—instances of concrete classes derived from the Work- base class—in the pc_work table, except as described in this topic.
A work pool, defined by a class group instance, causes all cases for an application to be stored in a single shared database table. This sharing is helpful for searching and reporting on cases. With appropriate safeguards, this also allows a case to be reclassified from one case 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 case was initially created with the wrong case 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, directly from the class form or indirectly using a wizard or tool. The structure of the new table is similar to the initial structure of the pc_work table.
The pc_work table demonstrates work pools, and serves as a default table for cases. 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, use a dedicated table for cases for each application.
If your system hosts two or more unrelated applications each with one or more work pools, store work items for each application in a dedicated table, using the structure of the pc_work table. A dedicated database table is recommended because:
SELECT operations) In addition, different applications might need different properties exposed as database columns
If you create the applications using the New Application wizard, each work pool has a dedicated table named pc_ZZZZZ_Work, which is a copy of the pc_work table, and you do not have to segregate cases into a dedicated table.
If your pc_work table contains cases from two or more unrelated applications, segregate cases into a dedicated table.
Many wizards and developer tools available in Designer Studio 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. This separation improves reporting performance.
The Pega-Events class and subclasses support the Designer Studio's RSS feed, and the Recent Actions landing page. These classes are derived from the Work- base class. To simplify reporting on your application work items, instances of these classes are saved in a dedicated database table, pc_events.
The pc_scheduledtask table contains work items for scheduled reports, which are instances of the Pega_ScheduledTask class.
The pc_work_dsm_batch table supports work items created using Decision Strategy Manager, which are 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.
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.
Note: Local data storage replaced data tables.