Understanding covers
— Concepts and terms
|
|
A cover is a work object (in a concrete class derived from the Work-Cover- abstract class) that is also a parent to one or more related work objects (usually in a class derived from Work- class). Typically one work party — such as the customer party — is present in the cover work object and also present in all of the covered work objects. These objects are the children in a parent-child relationship.
Some Business Process Management materials refer to cases and case management, rather than the Process Commander term cover.
A cover work object provides a means to coordinate processing of related work objects. In most applications, the system resolves a cover work object when all of its "member" covered work DYERJ 12/3/07
The cover facility has many practical benefits. For example, if a single customer request causes a user to create three separate work objects, these work objects may follow separate flows, be handled by separate departments, and not otherwise affect each other. The cover object provides a way to consolidate, view, and manage the outstanding service requests of this customer. After all three covered work objects become resolved, the cover work object can be resolved.
Using the cover facility is optional. You can use the PegaSample sample application to learn about covers and determine whether this feature is useful in your application:
Sample Work as the current work pool.General
Task as the Issue.Add Work... and select General
Task to enter a second and additional members of the
cover.Case type rules enable you to nest cover objects within other cover objects in a parent-child hierarchy. This capability helps centralize flow processing and monitoring among multiple work types in large applications. You can nest any number of parent and child covers. You access attachments to covered work in a parent cover object. In a case management application, the rule lets you expand the scope of a top-level case (parent cover) by covering one or more subcases (child covers) and their children work types.
Work object forms support working with covers and its covered objects:
) at the top right of the cover work object form to
access the member work objects.
In the above example, the use of a case type rule enables C-13 to cover another cover, C-14. By convention, the work object IDs of covers have the format C-999999; basic work objects have the format W-99999. Your application need not follow these conventions.
Internally, a cover is a work object that is an instance of a concrete class derived from the Work-Cover- abstract class. Your system includes harness rules, flow action rules, and activities that support working with covers. The covered work objects can be of differing work types. However, the work type of the cover and the work type of the covered objects must all belong to the same work pool. CLINIC 11/15/05
pyCoverPage; the covered work object
is on a page named pyWorkPage. R-11879 B-3771
Many standard activities depend on these naming conventions.
) on a cover work
object starts execution of a list view rule named AppliesToclass.WorkInACover.ALL, which is embedded using the
<pega:listView> JSP tag. The standard list view rule
Work-.WorkInACover.ALL displays the urgency
(pyUrgencyWork property), work object ID
(pyID), subject (pyLabel), and status
(pyStatusWork) fields as columns, without sorting. You
can copy and override this list view rule for your work types,
choosing different columns, add sorting as required, and enabling
paging if required. However, note that list view rules with paging
enabled cannot sort rows by work object ID, as the
Work-.pyID property has a custom sort function.
C-2579 5.2ZELEK 11/14/06See the Pega Developer Network article 
PRKB-25838 Use one ticket to end a flow for both a cover object and its covered objects.
