Working with the PegaRULES database — Tables for data objects

The pr_operators table contains rows that correspond to instances of the Data-Admin-Operator-ID class. The key to this table consists of the class name and Operator ID, for example:

DATA-ADMIN-OPERATOR-ID [email protected].

As a best practice, retain Operator ID records permanently; do not delete rows that correspond to departed operators. You can change the operator password to prevent anyone from logging on, and can mark the operator as unavailable for work.

The Storage Stream column (pzPVStream) of this table contains user passwords in encrypted form. For maximum security of your Process Commander system, do not alter the schema for this table to expose this property as a column.

The pi_data_connect table is associated with the Data-Admin-Connect- class. Instances of the classes derived from this class support service listeners and related interface data.

For example, JMS listeners are instances of the Data-Admin-Connect-JMSListener class.

The pr_data_admin table holds instances of classes derived from the Data-Admin- class, excluding those explicitly mapped to other tables:

• Operators
• Instances of classes derived from Data-Admin-Connect-
• Instances of classes derived from Data-Admin-DB-.

For example instances of the Data-Admin-System-Settings class are mapped to the pr_data_admin table.

The pc_data_uniqueid table corresponds to the Data-UniqueID class, and contains a single row for each work object ID format in use. This row records the most recently assigned work object ID of that format, usually computed by a stored procedure.

For example, if most recent purchase order is PO-4253, then when the next purchase order is entered, the value of property pyLastReservedID increments to 4254.

Attachments to work objects are instances of concrete classes derived from the Data-WorkAttach- class. In the initial PegaRULES database schema, this class is linked to the pc_data_workattach table.

The pzInsKey value for a work object attachment consists of values of these properties, concatenated into a single string:

• pxObjClass — The class, such as DATA-ADMIN-WORKATTACH-FILE
• pxRefObjKey — The work object, identified by work pool name and work object ID
• pxAttachKey — The date and time the attachment was created

For example, a note attached to work object W-15 on November 10, 2005 may have the following pzInsKey value:

DATA-WORKATTACH-NOTE PEGASAMPLE W-15!20051110T195841.692 GMT

Some applications in production may create and retain millions of work object attachments; other applications may not to use attachments at all.

Instances of the Data-WorkAttach-File class may contain an uploaded file of any type, up to 25MB in initial size, converted to text using Base64 encoding. Instances of the Data-WorkAttach-ScanDocument and Data-WorkAttach-ScreenShot classes both contain images, also converted using Base64 encoding.

Instances of these three Data- classes are associated with the pr4_base table:

• Data-Admin-DB-Table
• Data-Admin-DB-Name
• Data-Admin-DB-ClassGroup

These are known as foundation classes.

Instances of two Data- classes that support the Automatic Testing facility are associated with the pr_data_autotest table:

• Data-AutoTest-Result-Case
• Data-AutoTest-Result-Suite

Instances of the Data-Content-Image class are associated with the pr_data_file table. See About Image Content data instances.

Two Data- classes support the Virtual Enterprise Repository. If your system does not host a VER, these tables are not used:

• Data-VERB-Registry instances are saved in the pr_data_registry table, keyed by transaction ID, RuleSet name and RuleSet version.
• Data-VERB-Repository instances are saved in the pr_data_repository table, one for each rule involved in a transaction.

The pr_data table holds instances of any concrete class derived from the Data- base class not covered by the tables listed above. For example, (as initially configured during installation) the Data-Party-Com, Data-Party-Person and Data-Corr-Email classes map to this table.

The pr_data table has only few exposed columns. As a best practice for good performance, evolve your PegaRULES database so that any classes with many saved instances or high activity are not mapped to this table. For example, some applications in production may have thousands or millions of people identified through Data-Party-Person instances, or create millions of outgoing email messages saved in the Data-Corr-Email instances. As a best practice, create new dedicated tables with exposed columns for such classes, or add indexes to eliminate table scans and add exposed columns to avoid retrieving the Storage Stream.