Purging and Archiving Work Objects

Purging and Archiving Work Objects Process Commander V5.
Copyright 2006 Pegasystems Inc., Cambridge, MA

All rights reserved. This document describes products and services of Pegasystems Inc. It may contain trade secrets and proprietary information. The document and product are protected by copyright and distributed under licenses restricting their use, copying distribution, or transmittal in any form without prior written authorization of Pegasystems Inc. This document is current as of the date of publication only. Changes in the document may be made from time to time at the discretion of Pegasystems. This document remains the property of Pegasystems and must be returned to it upon request. This document does not imply any commitment to offer or deliver the products or services described. This document may include references to Pegasystems product features that have not been licensed by your company. If you have questions about whether a particular capability is included in your installation, please consult your Pegasystems service consultant. For Pegasystems trademarks and registered trademarks, all rights reserved. Other brand or product names are trademarks of their respective holders. Although Pegasystems Inc. strives for accuracy in its publications, any publication may contain inaccuracies or typographical errors. This document or Help System could contain technical inaccuracies or typographical errors. Changes are periodically added to the information herein. Pegasystems Inc. may make improvements and/or changes in the information described herein at any time.
This document is the property of: Pegasystems Inc. 101 Main Street Cambridge, MA 02142-1590 (617) 374-9600, fax: (617) 374-9620 www.pega.com PegaRULES Process Commander Document: TITLE GOES HERE Software Version: 5.1 Posting Date: October 2006
Contents
Introduction...............................................................................................................2 Mapping Classes to Database Tables ....................................................................4 About Classes and Tables..................................................................................4 Verifying Class-to-Table Maps ...........................................................................5 Listing All Classes Mapped to one Table ...........................................................6 Computing Row Counts by Class.....................................................................10 The Work Object Data Model.................................................................................11 Tables for Work Objects ...................................................................................11 pc_work Table ..................................................................................................13 pc_history_work Table......................................................................................14 pc_assign_workbasket , pc_assign_worklist and pr_assign Tables................15 pc_link_attachment Table.................................................................................15 pr_link Table .....................................................................................................16 pc_link_folder table...........................................................................................16 pc_data_workattach Table ...............................................................................17 pc_index_workparty Table................................................................................18 pc_data_uniqueid Table ...................................................................................18 pr_data Table ...................................................................................................19 Case 1: Purging All Work Objects ........................................................................20 Lookup List Cache............................................................................................20 Case 2: Purging Selected Work Objects ..............................................................22 Selection...........................................................................................................22 Purging .............................................................................................................25 Case 3: Using Date-Range Partitions ...................................................................29 Case 4: Archiving ...................................................................................................30 Summary and Redundant Data .............................................................................31
Purging and Archiving Work Objects
Introduction
In a production Process Commander application, the volume of data for work objects typically grows to require hundreds of megabytes or terabytes of database storage. If information from older work objects is no longer needed, or is needed only infrequently, it makes sense to remove selected older data from the live production database, possibly storing it in a separate archive system. Removing selected work objects can provide these benefits:

Improved performance, because database operations operate on tables with fewer rows. Reduced space requirements for the database. Reports and analyses run against an archive or shadow system do not affect production operations.
You can implement such purging and archiving with standard relational database operations. However, because information about a work object is stored in several tables, and not all Process Commander properties are available as individual columns, planning is required. Care is needed to ensure the internal consistency and integrity of the database after purging or archiving operations are completed. This article describes the PegaRULES database tables that hold work object details and the relationships among them, and provides sample SQL statements for specific situations. (Database administrators will need to adjust these sample SQL statements to meet specific architectural and business needs.) References to tables and properties correspond to the database schema as initially installed in Version 5.1SP1, though the approach is generally applicable to Version 4.2SP4 and later. Your applications may introduce additional tables or additional relationships among the tables. In that case, you must adapt the specific SQL and techniques presented here to your needs. Caution: Before using any of techniques described in this article, back up the entire PegaRULES database.
Purging and Archiving Work Objects Introduction
In this article, purging means deleting data permanently, with no means for restoring it in the future. Archiving means removing data from the primary PegaRULES database, allowing for a possible future restore operation, or allowing it to be accessed (for searching or reporting purposes, not updates) in a separate database and separate Process Commander system.
Mapping Classes to Database Tables

It is important to understand the PegaRULES database model as it applies to work objects. For additional information the PegaRULES database, see the Administration and Security Guide and Help System topics.
About Classes and Tables

Process Commander is an object-oriented system supporting hundreds of different object structures. However, persistent objects are stored in a few dozen tables in a relational database, known as the PegaRULES database. The correspondence between the conventional relational representation (of tables with columns and rows) and the internal orientation (of classes and properties) is simple and fast. These principles apply to all tables:
One database table may contain rows corresponding to instances of various Process Commander classes. For each row, the column named pyObjClass identifies the Process Commander class. Instances of the Data-Admin-DB-Table class define a many-to-one mapping between classes and database tables. For example, a DataAdmin-Database-Table record maps the class Data-Admin-OperatorID to the table pr_operators. When an object is saved (committed to the database), a search algorithm uses the class name to search for a table, using the pattern of dashes and letters in the class name to find a Data-Admin-DB-Table record that applies, or choosing the default table pr_other if none is found. The unique key to most tables is a single column named pzInsKey. However, the internal structure of this key varies from table to table. Most tables contain a column named pzPvStream, known as the Storage Stream, typically declared as a BLOB or Binary Large Object data type. This contains all non-key values (properties) of a Process Commander object, compressed into a single value. The internal format of pzPvStream various from Process Commander release to release. Data values inside the pzPvStream column can be accessed only through Process Commander facilities. Columns other than the pzPvStream column and the pzInsKey column are known as exposed columns, and hold individual string, date, and number values. These can be scanned, selected, and searched through
Purging and Archiving Work Objects Mapping Classes to Database Tables
ordinary SQL statements. Each column name corresponds to a rule within Process Commander known as a property. For example in the pr_operator table, the column pyUserName holds the users full name as a text string.
Process Commander uses an internal locking mechanism separate from the database locking facility. For maximum safety, purging or archiving operations should take place only at a time when no users (or background processes) are accessing the database. Every table contains a column that holds the date and time that the row was first saved (committed). In most tables, the column is named pxCreateDateTime. DateTime values are in UTC format to the nearest millisecond, following the pattern YYYYMMDDTHHMMSS.ZZZ GMT, for example 20060616T151041.093 GMT for June 6, 2006 at 15:10:41 London time. (In some cases, Process Commander rounds the values as they are saved into the database.) Process Commander employs an internal indexing mechanism (controlled by Rule-Data-Index rules) that is similar in purpose but independent of database indexes. Because of these principles, if you store data from Process Commander in a similarly structured database (but without Process Commander software), you can report only on exposed properties. Data values for properties that are available only in the pzPvStream column are inaccessible. Further, you cannot simply move rows in one PegaRULES database table, even if both tables have the same columns and structure, without careful coordination with changes to Data-Admin-DB-Table maps. Additionally, the Process Commander mapping requires that all instances of a class be in one table. You cannot store current work objects in one table and older work objects (of the same class) in a second table.
Verifying Class-to-Table Maps

Using the Class Explorer tool of the Process Commander Developer portal, you can determine which database table holds the rows corresponding to a concrete class:
1. Expand the Class Explorer tree control to locate the class name. (Adjust your Class Explorer preferences if some classes are not presented.) 2. Click the icon at the left of the name to view the Class rule form in the workspace. 3. Click the Basic tab if necessary to make it front most. 4. Click the Test Connectivity button. Process Commander identifies the table in a pop-up window display.
Listing All Classes Mapped to one Table

Using the Modify Database Table tool, you can determine the reverse information, listing all concrete classes that are mapped to a specific database table. (This procedure is read-only; it does not alter the database contents or schema).
1. From the Tools menu of the Developer portal, select the Database > Modify Database Schema menu item.
2. A window appears. At step 1, select the PegaRULES database. Click Next.
3. At step 2, select the table of interest. .Click Next.
4. The Step 3 display lists all the classes mapped with that table (whether any rows of that class are present or not.) In this example, the pc_work table may contain rows from any of 30+ classes. Currently, this table contains 79 rows.
10
Computing Row Counts by Class

Using the System Management application, you can determine (for classes with one or more saved instances), the row counts of the Process Commander classes mapped to that table.
1. Start the System Management application. 2. Select any node in the left panel. 3. Choose Database Table Information from the Advanced menu in the left panel. 4. Select a radio button corresponding to one database table. Click the List Record Count button. In this example, six classes with one or more rows are mapped to the pc_work table. Classes with no rows do not appear. The total count of rows is 79.
Purging and Archiving Work Objects The Work Object Data Model
11
The Work Object Data Model

This section describes the tables that hold work objects or parts of work objects, the relationships among the tables, and the corresponding Process Commander classes. This description corresponds to the as-installed database schema and class-to-table of Version 5.1. If you have copied or renamed tables, or established additional relationships, the description may not fully match your system.
Tables for Work Objects

A work object is the fundamental record of a business process in a Process Commander application. Data about work objects is present in these tables:
pc_work Primary work object record pc_history_work Audit trail details pc_assign_* tables Incomplete assignments pc_link_attachment Associates a work object with attachments,
optional files, e-mail messages, or images.

pc_link_folder Support folders, an optional facility for grouping
multiple work objects

pc_data_workattach Holds work object attachments pc_index_workparty Cross-references work objects by an
identifier for each party (participant), such as an account number, Social Security Number, e-mail address, or telephone number.
pc_data_unique. Supports unique work object numbering pr_data Holds unsent correspondence for work objects.
In addition to the tables listed above, the PegaRULES database includes a few views and numerous indexes that involve the above tables. If you if you modify the contents of the tables, the database software maintains correct contents of views and indexes. The Entity-Relationship chart on the following page shows the relevant relationships among these tables.
12
13
This diagram uses the following notation and conventions:

All the columns listed are exposed properties holding a text value. (The tables contain many additional columns not shown.) PK identifies the unique key for each table, the pzInsKey column. As noted above, the structure and content of values for this column differ greatly from table to table. FK identifies a column and property that Process Commander uses as a foreign key to access a row of another table. These are interpreted by software, they not identified as foreign keys in the database schema.) Numbers on the arrows indicate the multiplicity of the relationship. For example, one work object (pc_work table) may have many different work object history records (pc_history_work table). All tables but one contain the pxCreateDateTime column, recording the date and time (in UTC format, previously known as Greenwich Mean Time) that the row was first saved. (In the pc_history_work table, this column is named pxTimeCreated.)
pc_work Table
Work objects are typically stored in the pc_work table, or another table with a similar structure. The unique pzInsKey value for a work object consists of a work pool name (sometimes called a class group) and a work object ID. The pc_work table is related to all the other database tables presented in the diagram.
14
The following table identifies important columns in the pc_work table.

Column
pzInsKey pxObjClass pxInsName pyID pyStatusWork
Description and Example
PK. Primary key PEGASAMPLE ! W-15 Work type (class). PEGASAMPLE-TASK. Work object ID, W-15. Work object ID, W-15. Work object status. The values that start with Resolved indicate that a work object is resolved and no further updates are expected. Resolved-Completed Date and time (in GMT format) that the work object was resolved. 20041109T204536.146 GMT FK. For a work object that is a member of a cover, identifies the pzInsKey value of the covering work object. This is a many-to-one relationship. PEGASAMPLE- ! C-145 For a work object that is a cover, an integer that records the number of member work objects that are open (unresolved).
pyResolvedTimeStamp
pxCoverInskey
pxCoveredCount
pc_history_work Table
This table contains detailed history of a work object, noting who updated the work object and on what date and time. The key structure links the date and time that the history instance was created to the work object. The two parts of the key are also available as separate columns, pxHistoryForReference and pxTimeCreated. Every work object has at least one history record in this table, recording the date and time the work object was created. Over time, the history of a work object may grow to contain dozens or hundreds of records. The pc_history_work table has a many-to-one relationship with the pc_work table, linked by the pxHistoryForReference value. For
15
example, the pxHistoryForReference value PEGASAMPLE ! W-15 identifies a row as one of the history rows for the work object W-15.
pc_assign_workbasket , pc_assign_worklist and pr_assign Tables

An assignment is a task typically requiring human input or decisionmaking. Ordinarily, you should not purge work objects with open (incomplete) assignments should not be purged or archived, as additional tasks are needed. These three tables have an identical key structure: The pzInskey for rows of these tables is formed by concatenating the values of first three properties listed, with an exclamation point between the pxRefObjectKey and pxFlowType values. Each row in this table references a work object, through the pxRefObjectKey value. One work object may have none, one, or multiple rows in the pc_assign_workbasket table (corresponding to instances of the ASSIGN-WORKBASKET class). Additionally, it may have none, one, or multiple assignments in the pc_assign_worklist table (corresponding to instances of the ASSIGN-WORKLIST class). Less commonly, it may have none, one, or multiple instances in the pr_assign table (for correspondence or suspended work). For example, the pxRefObjectKey value PEGSAMPLE ! W-15 indicates that work object W-15 (in the PEGASAMPLE work pool) has an open assignment and therefore the work object is incomplete and should not be purged.
pc_link_attachment Table
Entries in the pc_link_attachment table associate a work object with an attachment. Each row corresponds to an attachment, identified by the date and time that the attachment was saved. However, this table records only associations; the body of an attachment is in a separate table named pc_data_workattach. This table includes two foreign key references. Column pxLinkRefFrom identifies the work object to which this attachment belongs. Column pxLinkRefTo holds a date and time value that matches a key of the pc_data_workattach table.
16
One work object may have none, one, or many attachments. Each attachment is associated, through this table, with one work object.
pr_link Table
No standard Process Commander classes are mapped to the pr_link table. However, if your application uses the Link-Object method to create instances of a custom class derived from the Link- class, they are stored in this table by default. The schema and columns of this table are similar to those of the pc_link_attachment table. If your application contains custom links, the linked-to objects may be stored in a custom table, identified by a pzInsKey that is the date and time value the link was committed. (Procedures below do not include any custom tables in your application.)
pc_link_folder table
Instances of this table exist only when the application uses folders, a many-to-many relationship among work objects. In contrast to the cover relationship, folders can be members of folders, and a work object can belong to multiple folders at once. Folders provide quick access to the member work objects. Process Commander enforces no additional constraints or relationships between the folder work object and its member work objects, although your applications may introduce them. This table includes the following columns that hold exposed properties:
Column
pxObjClass
Class of this object, LINK-FOLDER. Initial portion of the pzInsKey value. FK Identifies the work object that belongs to a folder. Formed from the class group name (work pool) and the work object ID. Middle portion of the pzInsKey value. FK. Identifies the folder work object. Final portion of the pzInsKey value. Many different work objects can be linked to the same folder work object.
pxLinkedRefFrom
pxLinkedRefTo
17
Column
pxLinkedClassFrom
Work type (class), such as PegaSample-Task, of the work object that belongs to the folder.
The key of a Link-Folder instance consists of the pxObjectClass value and two work object references, pxLinkedRefFrom and pxLinkedRefTo., separated by a single exclamation point. For example, the value:
LINK-FOLDER PEGASAMPLE ! W-15 PEGASAMPLE ! F-208
indicates that work object W-15 belongs to the folder work object F-208. Both are in the PEGASAMPLE work pool. If your application uses folders, purging work objects while maintaining a folder structure for any work objects not purged may depend on application-specific details that are not addressed in this article.
pc_data_workattach Table
This table holds the contents of attachments, each associated with a work object. One work object may be linked to none, one, or many attachments. This table is related to the pc_link_attachment table, a 1-1 relation based on the date and time value in the pzInsKey value. Note that no column in the pc_data_workattach table identifies the work object ID. Five classes can hold attachments: Data-WorkAttach-File Holds an uploaded file in Base64 encoding. The file before encoding may be as large as 25 megabytes. Data-WorkAttach-Note Holds a brief text note of 1024 characters or less. Data-WorkAttach-Snapshot Holds a Base64-encoded TIFF image, a screen capture. Data-WorkAttach-URL Holds a URL link. Data-WorkAttach-ScanDocument Holds a Base64-encoded TIFF image produced by a document scanner
18
File attachments contain an uploaded file (converted to characters using Base64 encoding and stored in the pzPvStream column value) that may be up to 25 megabytes in original size. (Through a setting in your Process Commander prconfig.xml file, you can change this limit size to a higher or lower value.)
pc_index_workparty Table
A work party in a work object is a person, account, business or other organization that is in some way involved in the business process, and who may receive correspondence. The pc_index_workparty table supports rapid search for work objects that contain a specified party. (A standard Declare Index rule adds and deletes entries in this table.) The pzInsIndexKey column provides a foreign key reference to the pc_work table. This is a many-to-one relationship: one work object may have one or more than one work parties, and so one may have or more rows of this table.
pc_data_uniqueid Table
Entries in this table assure unique work object numbers, by recording the highest value already assigned. The key to this table consists of a work object prefix. For instance, a row with key C- records the number of the last work object that was created on this system and used a C- prefix. This prefix may be used only by one application or one work type, or may be used by many applications and many work types. (In earlier Process Commander releases, the organization name was also part of the key. Your system may reflect this earlier approach.) In most cases, you should not alter the contents of this table when purging work objects, unless you are deleting all work objects, or all work objects with a specific prefix, and wish to restart numbering at 1.
19
pr_data Table
The pr_data table contains rows corresponding to instances of various classes. Four values of the pxObjClass column indicate rows that hold correspondence, outgoing messages sent to a party.

DATA-CORR-LETTER DATA-CORR-FAX, DATA-CORR-EMAIL DATA-CORR-PHONETXT.
Correspondence records in this table may be sent (transmitted or printed) or unsent. To avoid possible later confusion, it is a good practice to retain (not purge) work objects when correspondence remains unsent. (Typically, correspondence is printed or sent out promptly after it is generated, so it would be unusual to find unsent correspondence for work objects resolved some time ago An instance of the Assign-Corr class a row of the pr_assign table mentioned above is present and linked to the pr_data table. Once the correspondence has been sent, the Assign-Corr instance is deleted. One work object may have none, one, or many correspondence items.
20
Case 1: Purging All Work Objects

In a test system, it may sometimes be useful to purge all work objects, to restore initial conditions to the system. The following SQL statements erase all work objects (open and resolved) and all associated parts. (If you are using a database that does not support the TRUNCATE statement, delete all rows of these tables.)
truncate truncate truncate truncate truncate truncate truncate truncate truncate table table table table table table table table table pc_work; pc_assign_worklist; pc_assign_workbasket; pc_data_uniqueid; pc_data_workattach; pc_history_work; pc_index_workparty; pc_link_attachment; pr_link_folder;
delete from pr_data where pxObjClass like '%DATA-CORR-%'; commit;
Lookup List Cache

After completing the above SQL statements or any similar direct database purging operation, it is a good practice to purge the lookup list cache a collection of XML documents that provide saved snapshots of some database rows. The lookup list files resides within the [tempdir]/LLC/ directory on the Process Commander server, where [tempdir] is the path of the temporary files directory identified during installation. (The Process Commander server may be a separate computer from the server hosting the PegaRULES database. In a multinode cluster, delete the lookup list cache on each node.) If you have access to the file system on the Process Commander server, simply delete all XML files in the LLC directory. If you do not have such access, perform these steps::
1. Start the System Management application 2. Select a node, and choose the Advanced > ETier Static Content Management menu item.
Purging and Archiving Work Objects Case 1: Purging All Work Objects
21
3. Click the DeleteLookupList button. 4. Repeat the steps above for each server node in the cluster.
Either technique can be used while the system is available and in use.
22
Case 2: Purging Selected Work Objects

Commonly, work objects resolved between two specific dates are purged. In this example, work objects of type PEGASAMPLE-TASK that were resolved between October 13th and 14th, 2006 are purged.
Selection
This sample SQL selects, but does not delete, the rows of tables involved with work objects resolved between two dates.
/* select attachments from pr_data (probably correspondence) that are linked to work objects of a given work pool that were resolved in a given date range */ select pr_data.pzInsKey as DataKey from pr_data where Exists( select AttachLinkTable.pzInsKey from pc_link_attachment AttachLinkTable, pc_work WorkTable where WorkTable.pzInskey = AttachLinkTable.pxLinkedRefFrom and WorkTable.pxObjClass like 'PegaSample%' and WorkTable.pyStatusWork like 'Resolved%' and WorkTable.pyResolvedTimeStamp between '2006-10-13' and '2006-10-14' and (AttachLinkTable.pxLinkedRefTo = pr_data.pzInsKey) ) /* select attachments from pc_data_workattach that are linked to work object of a given work pool that were resolved in a given date range */ select pc_data_workattach.pzInsKey as WorkAttachKey from pc_data_workattach where exists( select AttachLinkTable.pzInsKey from pc_link_attachment AttachLinkTable, pc_work WorkTable where WorkTable.pzInskey = AttachLinkTable.pxLinkedRefFrom and WorkTable.pxObjClass like 'PegaSample%' and WorkTable.pyStatusWork like 'Resolved%'
Purging and Archiving Work Objects Case 2: Purging Selected Work Objects
23
and WorkTable.pyResolvedTimeStamp between '2006-10-13' and '2006-10-14' and (AttachLinkTable.pxLinkedRefTo = pc_data_workattach.pzInsKey)) /* select attachment links that are linked to work objects of a given work pool that were resolved in a given date range */ Select pc_link_attachment.pzInsKey as LinkAttachKey, pc_link_attachment.pxLinkedRefFrom as WorkItemReference from pc_link_attachment where Exists( select WorkTable.pzInskey from pc_work WorkTable where WorkTable.pzInskey = pc_link_attachment.pxLinkedRefFrom and WorkTable.pxObjClass like 'PegaSample%' and WorkTable.pyStatusWork like 'Resolved%' and WorkTable.pyResolvedTimeStamp between '2006-10-13' and '2006-10-14') /* select history for work objects of a given work pool that were resolved in a given data range */ select pc_history_work.pzInsKey as HistoryKey, pc_history_work.pxHistoryForReference as WorkItemReference from pc_history_work where exists ( select WorkTable.pzInsKey from pc_work WorkTable where WorkTable.pyStatusWork like 'Resolved%' and WorkTable.pxObjClass like 'PegaSample%' and WorkTable.pyResolvedTimeStamp between '2006-10-13' and '2006-10-14' and pc_history_work.pxHistoryForReference = WorkTable.pzInsKey ) /* select workparty indices for work objects of a given work pool that were resolved in a given data range */ select pc_index_Workparty.pzInsKey as PartyIndexKey, pc_index_Workparty.pxInsIndexedKey as WorkItemReference from pc_index_Workparty where
24
exists ( select WorkTable.pzInsKey from pc_work WorkTable where WorkTable.pyStatusWork like 'Resolved%' and WorkTable.pxObjClass like 'PegaSample%' and WorkTable.pyResolvedTimeStamp between '2006-10-13' and '2006-10-14' and pc_index_Workparty.pxInsIndexedKey = WorkTable.pzInsKey ) /* Select resolved work objects from a given date range, that do not have assignments*/ select pc_work.pzInsKey as WorkItemKey, pc_work.pxObjClass as WorkItemClass from pc_work where pc_work.pxObjClass like 'PegaSample%' and pc_work.pyStatusWork like 'Resolved%' and pc_work.pyResolvedTimeStamp between '2006-10-13' and '200610-14' and not exists( select AssignWorklist.pzInsKey from pc_assign_worklist AssignWorklist where pc_work .pzInsKey = AssignWorklist.pxRefObjectKey ) and not exists( select AssignWorkbasket.pzInsKey from pc_assign_workbasket AssignWorkbasket where (AssignWorkbasket.pzInsKey = pc_work .pzInsKey) ) and not exists ( select AssignGeneric.pzInsKey from pr_assign AssignGeneric where AssignGeneric.pzInsKey = pc_work .pzInsKey )
You can report on the selected rows, to confirm that the SQL selected the expected ones.
25
You may also use vendor-supplied archiving tools for example as Data Transformation Services from Microsoft or Import-Export Services from Oracle to save the selected rows in an archival format.
Purging
After you are satisfied with the selected rows, you can repeat the operations above but using DELETE rather than SELECT. (The need for a final COMMIT depends on the database software and your use of transactions.) Order is important when doing deletions. This sample SQL deletes rows in a recommended order:
1. Attachments and any other linked objects 2. Links 3. History 4. Indexes 5. Assignments (not included in this example, typically none exist ) 6. Work objects that are not covers or folders 7. Covers (not addressed in this example) 8. Folders (not addressed in this example)
/* delete attachments from pr_data (probably correspondence) that are linked to work objects of a given work pool that were resolved in a given date range */ delete from pr_data where Exists( select AttachLinkTable.pzInsKey from pc_link_attachment AttachLinkTable, pc_work WorkTable where WorkTable.pzInskey = AttachLinkTable.pxLinkedRefFrom and WorkTable.pxObjClass like 'PegaSample%' and WorkTable.pyStatusWork like 'Resolved%'
26
and WorkTable.pyResolvedTimeStamp between '2006-10-13' and '2006-10-14' and (AttachLinkTable.pxLinkedRefTo = pr_data.pzInsKey) ) /* delete attachments from pc_data_workattach that are linked to work objects of a given work pool that were resolved in a given date range */ delete from pc_data_workattach where exists( select AttachLinkTable.pzInsKey from pc_link_attachment AttachLinkTable, pc_work WorkTable where WorkTable.pzInskey = AttachLinkTable.pxLinkedRefFrom and WorkTable.pxObjClass like 'PegaSample%' and WorkTable.pyStatusWork like 'Resolved%' and WorkTable.pyResolvedTimeStamp between '2006-10-13' and '2006-10-14' and (AttachLinkTable.pxLinkedRefTo = pc_data_workattach.pzInsKey)) /* delete attachment links that are linked to work objects of a given work pool that were resolved in a given date range */ delete from pc_link_attachment where Exists( select WorkTable.pzInskey from pc_work WorkTable where WorkTable.pzInskey = pc_link_attachment.pxLinkedRefFrom and WorkTable.pxObjClass like 'PegaSample%' and WorkTable.pyStatusWork like 'Resolved%' and WorkTable.pyResolvedTimeStamp between '2006-10-13' and '2006-10-14') /* delete history for work objects of a given work pool that were resolved in a given data range */ delete from pc_history_work where exists ( select WorkTable.pzInsKey from pc_work WorkTable where WorkTable.pyStatusWork like 'Resolved%'
27
and WorkTable.pxObjClass like 'PegaSample%' and WorkTable.pyResolvedTimeStamp between '2006-10-13' and '2006-10-14' and pc_history_work.pxHistoryForReference = WorkTable.pzInsKey ) /* delete workparty indices for work objects of a given work pool that were resolved in a given data range */ delete from pc_index_Workparty where exists ( select WorkTable.pzInsKey from pc_work WorkTable where WorkTable.pyStatusWork like 'Resolved%' and WorkTable.pxObjClass like 'PegaSample%' and WorkTable.pyResolvedTimeStamp between '2006-10-13' and '2006-10-14' and pc_index_Workparty.pxInsIndexedKey = WorkTable.pzInsKey ) /* delete resolved work objects from a given date range, that do not have assignments*/ delete from pc_work where pc_work.pxObjClass like 'PegaSample%' and pc_work.pyStatusWork like 'Resolved%' and pc_work.pyResolvedTimeStamp between '2006-10-13' and '200610-14' and not exists( select AssignWorklist.pzInsKey from pc_assign_worklist AssignWorklist where pc_work .pzInsKey = AssignWorklist.pxRefObjectKey ) and not exists( select AssignWorkbasket.pzInsKey from pc_assign_workbasket AssignWorkbasket where (AssignWorkbasket.pzInsKey = pc_work .pzInsKey) ) and not exists ( select
28
AssignGeneric.pzInsKey from pr_assign AssignGeneric where AssignGeneric.pzInsKey = pc_work .pzInsKey )
******
Purging and Archiving Work Objects Case 3: Using Date-Range Partitions
29
Case 3: Using Date-Range Partitions

If the work objects in your application meet certain turnover and retention criteria, you can simplify purging or archiving by using database partitions. No changes are required to Process Commander rules. For example, assume that work objects are normally resolved in no more than few days, and it is only necessary to retain resolved work objects for three months. Assume further that after a work object is resolved, no new attachments, correspondence, history or assignments are added. In this case, you can create twelve monthly partitions based on the value of the pxCreateDateTime column (or for the pc_history_work table, the pxTimeCreated column). Work objects created during January are stored in the January partition, as are the history, attachments, links, and other records. In April, to purge all January work, drop all rows in the January partition. During May, drop all rows in the February partition. If you adapt this technique to your applications, the period may be days, months, quarters or years. Be sure to create the partition for a period in advance of the starting date of the period.
30
Case 4: Archiving
You can hold resolved work objects, including history and attachments, in a shadow database on another Process Commander system. This allows occasional access or the possibility of restoring some or all of the data later. To create an archive database consisting only of the archived work objects: 1. Create a copy of the entire database; this becomes an archive. 2. On the production system, purge the work objects no longer needed, including attachments, history, and correspondence. 3. Install a Process Commander server that provides access to the archive. Note that the archive database tables have the same schema as the production database. Note: You cannot archive work objects by moving the rows for some work objects to another table in the production Process Commander system. Process Commander requires that all rows with a single pxObjClass value (identifying the Process Commander class name) be in a common table. (The pxObjClass value also appears in various other columns and properties within the tables discussed in this note.)
Purging and Archiving Work Objects Summary and Redundant Data
31
Summary and Redundant Data

If your application contains derived or summary data, or includes links or relationships among work objects other than described here, use extra caution to maintain application data integrity when deleting work objects. For example, if your application includes a table with totals or counts of work objects, recompute the data in the table after purging. *****

Purging and Archiving Work Objects

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Purging and Archiving Work Objects

Hochgeladen von

Copyright:

Verfügbare Formate

Purging and Archiving Work Objects Process Commander V5.

Copyright 2006 Pegasystems Inc., Cambridge, MA