|
|
Working with the PegaRULES database — Tables for assignments
Three database tables normally contain assignments. Assignment instances are created when a flow execution reaches an Assignment shape (
in Process Modeler, or 
in Visio) in a flow. Assignment instances are deleted when a user or agent or other processing responds to the assignment by recording information, making and recording decisions, and adding attachments, or otherwise updating the work item, allowing the flow execution to continue.
BasicsAssignments are instances of a concrete class derived from the Assign- base class.
A newly installed system contains no assignments. As work items progress, the system creates and deletes assignments. Assignments may exist only for a few seconds, or for days or months.
As initially configured during installation, three tables in the PegaRULES database contain rows that correspond to assignments:
The Monitor Process Assignments area of the Monitor Activity workspace provides several standard reports that report on the contents of the first two tables. (However, worklist displays use a class Data-Assignment-Summary that is linked to the pcv4_assign_summary database view. See Views and Indexes.)
Assignments routed to workbaskets are instances of the Assign-Workbasket class. In the initial PegaRULES database schema, this class is linked to the pc_assign_workbasket table.
The pzInsKey for rows of this table is formed by concatenating the values of the following properties:
- pxObjClass — Class of this object,
ASSIGN-WORKBASKET - pxRefObjectKey — Identifies the work item for this assignment, formed from the class group name (work pool) and the work item ID
- A single exclamation point (!)
- pyFlowType — Second key part of the flow that produced this assignment
For example, the pzInsKey value:
ASSIGN-WORKBASKET OTC-HR-PTO W-18!VACATIONREQUESTFLOW
identifies an assignment for the work item W-18 in the work pool named OTC-HR-PTO, created by a flow named VacationRequestFlow.
The workbasket name itself is not part of the key. Assignments for one workbasket can be accessed through an index. Indexes on the pc_assign_workbasket table speed reporting.
Assignments on operator worklists are instances of the Assign-Worklist class. In the initial PegaRULES database schema, this class is linked to the pc_assign_worklist table.
The pzInsKey for rows of this table is formed by concatenating the values of the following properties:
- pxObjClass — Class of this object,
ASSIGN-WORKLIST - pxRefObjectKey — Identifies the work item for this assignment, formed from the class group name (work pool) and the work item ID
- A single exclamation point (!)
- pyFlowType — Second key part of the flow that produced this assignment
For example, assume you enter a new work item W-20 of the Simple Task type in the PegaSample application. The flow that starts for W-20 is named PegaSample-SimpleTask.SimpleProcess. All work items in the PegaSample sample application belong to the PegaSample work pool.
The pzInsKey of the first assignment created by this flow execution is:
ASSIGN-WORKLIST PEGASAMPLE W-20 ! SIMPLEPROCESS
The assignee operator is not part of the key. Assignments for one assignee can be accessed through an index. Indexes on the pc_assign_worklist table speed reporting.
External assignments are stored as rows of the pc_assign_worklist table, which also holds rows for assignments on worklists. The key structure of these two types of rows is identical, except that the pxObjClass value for external assignments is ASSIGN-EXTERNAL.
Assignments in the Assign-Corr and Assign-Service classes are stored as rows in the pr_assign table:
- Assign-Corr assignments identify correspondence (including email) created but not yet sent.
- Assign-Service assignments are produced when a flow execution reaches the Assign-Service shape (
), and identify tasks awaiting completion by an external system.
