Back Forward Working with the PegaRULES database — Tables for work objects

Working with the PegaRULES database

Show all 

Work objects are the primary unit of processing in applications that use flow rules. A large fraction of database processing involves creating and updating work objects. Updates to related objects, such as assignments and attachments, usually also require updates to the work object.

As initially configured during installation, Process Commander saves work objects — instances of concrete classes derived from the Work- base class — in the pc_work table.

About class groups and work pools

A work pool, defined by a class group instance (Data-Admin-DB-ClassGroup class), causes all work objects for an application to be stored in a single shared database table. This sharing is helpful in searching and reporting on work objects. With appropriate safeguards, this also allows a work object 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 object was initially created with the wrong type.

The pc_work table

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

TipAs a best practice, create an additional work object table for work objects for each application, as described below.

CautionWhen an existing Process Commander system is upgraded to a new version, SQL scripts may update the standard tables. To avoid possible collisions or other issues with future upgrades, make schema changes (other than simple new columns) only to copies of the standard tables and views. Adjust table rows and Data-Admin-DB-Table mappings to reference your copies. This is especially important for database views, as upgrade processing may drop view definitions and add revised view definitions.

Creating a dedicated table for a work pool

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

To segregate work objects 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. PRKB-20134
  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. VAGUE incompleteTURBT Clinic 2/10/06 clinic 3/14

The pc_work_accel table

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 objects in your system. The work types of such work objects start with PegaAccel-Task-. 55 OSMAE 1/15/09 BUG-2667

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

The pc_events table

The Pega-Events class and subclasses support the Designer Studio's What's Happening display, RSS feed, and the Recent Actions gadget. These classes are derived from the Work- base class. To simplify reporting on work objects 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 displayV6.1

Reporting on work

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

As initially installed, Process Commander stores work objects in the pc_work table, and work object history instances in the pc_history_work table. This relationship is defined by the two database table instances Work- and History-Work-.

NoteReporting 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 objects and may cause SQL errors or JavaScript failures. You can remedy this by adding the two appropriate database table instances.

Two standard database views or tables? 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.Q-999

PDN These Pega Developer Network articles provide more information on this strategy:

PEGA0041 alert

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

Definitions work object, work pool
Related topics About Database Table data instances
How to detect when a work object is saved to the pr_other table (PEGA0041 alert)
Standard rules Atlas — Initial Database Table data instances
Atlas — Standard classes derived from the Work- base class

HomeWorking with the PegaRULES database