Working with the PegaRULES database — Views and Indexes

Six database views are defined in the database to support searching and reporting.

When an existing PRPC 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.

Views for assignments

Two views support reporting on work items with open assignments. (For reporting directly on assignments, see Tables for assignments.) As a single work item may be part of multiple simultaneous flow executions, it may have more than one assignment outstanding.

If you extend the initial PegaRULES database scheme to store work item in a new table other than the default pc_work table, also adjust these view definitions to include the new table.

View	Description
`pcv4_assignment_summary`	Associated with the Data-Assignment-Summary class, this view supports custom worklist display. This join contains a row for each row in the `pc_assign_worklist` table (assignments sent to operator worklists), but with additional columns supporting reporting and custom worklists. For example, the standard list view rule Data-Assignment-Summary.Worklist_CustomerRequest produces a custom worklist for PegaSample work items of type CustomerRequest. See PDN article How to customize the display of a worklist for more information.
`pcv4_assignmentwb_summary`	This view is associated with the Data-Assignment-WBSummary class. This join supports custom displays of workbasket contents, through techniques similar to those for custom worklists.
`pc_AllAssignments`	This view is associated with the Data-Assignment-AllAssignments class.

Work History view

The pcv4_work_history table is associated with the Data-Work-History class, and provides a consolidated means to reporting on work item history across all applications and work pools. The sort order of this view is:

pxHistoryForReference — Formed from the class group name, a space, and the work item ID, for example PEGASAMPLE W-4532
pxTimeCreated — Date and time the history instance was saved

This sequence causes all the history instances for a work item to appear in sequence. This view is not used in standard reports. (For reporting directly on work item history, see Tables for History.)

Views for rules

Five views support searching and reporting on rules:

View	Description
`pwbv4_circumstance_duplicates`	Associated with the Data-Circumstance-Duplicates class. It supports the report on Circumstance Property Issues.
`pwbv4_rule_locking`	Associated with the Data-Rule-Locking class. It contains a row for each rule checked out by a developer, and supports reporting on checked-out rules.
`pwbv4_rule_overrides`	Not used in V6.X. Associated with the Data-Rule-Overrides class.
`pr4_rule_vw`	A materialized database view, populated by triggers and associated with the Data-Rule-Summary class. It provides access to the information in all the rule tables, allowing rapid rule searches by visible key (pxInsName column). In this view, the pyClass column — not the usual pxObjClass column — identifies the PRPC class of a row. See How to report on rules of multiple types.
`pwbv4_rule_summary`	This view supports special rule reporting on personal development systems only. In Version 5.1 and later production systems, the `pr4_rule_vw` view replaces this view.

Database Indexes

Database indexes provide fast alternate access to rows of tables.

When initially installed, V6.3 contains just over 100 database indexes. Many indexes that provide fast access to rule information using alternate (secondary) keys; these indexes have low or zero turnover (adds and deletes) in a production system. Other indexes support system operations such as locking and usage tracking, and may have high turnover.

For example, the database index flow_pyClassName associates flow names to Work- classes, and changes only when flows are added or deleted.

Don't confuse database indexes with instances of concrete classes derived from the Index- base class. The purpose and function of both mechanisms are similar, but database indexes are supported by database software.

Index- objects, created by Declare Index rules (Rule-Declare-Index rule type), support application-specific access. For information on the tables that support Index- objects, see Working with the PegaRULES database — Index tables.

	check out, circumstance, referencing rules, view, visible key
	Atlas — Standard classes derived from the Index- base class

Home Working with the PegaRULES database

Open topic with navigation