Understanding
covers — Concepts and terms
|
|
A cover is a work object that is also a parent to one or more related work objects. 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 associated with the cover. The covered work 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. By default, the system prevents the resolution of a cover work object unless all of its "member" covered work objects are resolved.
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.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.
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.
pyCoverPage; the
covered work object is on a page named
pyWorkPage. Many
standard activities depend on these naming conventions.
) on a cover work object starts execution of a
list view rule named {AppliesTo
class}.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. 
