You are here: Reference > Data classes > Class Group data instances > More about Class Group data instances

  More about Class Group data instances
 

About Class Group data instances

Creating appropriate class groups and the corresponding classes are important early steps in building an application. Typically, class groups are created automatically through a wizard such as the Application Express.

All instances of classes that are associated with a class group share a common key definition and common lock definition. This allows the database software (such as, Oracle or Microsoft SQL Server) to save the instances as rows in one table in the PegaRULES database.

The common key format also ensures that the same database table is accessed when an instance is converted from one class (within a class group) to another class (in that same class group). For example, a work item may initially be entered incorrectly as a merchandise order, but later be reclassified as a merchandise return request. Both work types have the same key structure and belong to a common work pool (class group).

Class groups can help with database table management, backup, space, and reporting.

Creating class groups automatically

You can automatically create a class group while creating a Class rule (Rule-Obj-Class rule type). The new class (a rule) and the new class group (a data instance) have identical names.

To do this, select is a class group for the This class field on the Settings tab of the Class form.

Class groups and inheritance

The names of all classes belonging to a common class group start with the class group name, followed by a dash character. For example, if you define a class group named Work-Object-Thorr-Task, the classes in the class group can be named Work-Object-Thorr-Task-Ordering, Work-Object-Thorr-Task-Shipping, and Work-Object-Thorr-Task-Billing.

For rule resolution purposes (not database storage purposes) classes in the class group can derive from (inherit rules from) the class with the same names as the class group, but this is not required. Because of directed inheritance, classes in the class group can inherit rules from elsewhere in the hierarchy.

For instance, in the above example, Work-Object-Thorr-Task-Ordering can be configured to inherit rules from Work-Object-, while the other two classes inherit from Work-Cover-Thorr-. All the classes in one class group, however, are associated with one common database table, regardless of their parent class for rule resolution purposes.

When one system hosts two or more organizations using a common application, each organization should have its own dedicated work pools. Work object numbering is per work pool; each organization can then have a work item numbered W-1234. The Clone a Class Group landing page tab is useful in this situation. See Data Model category — Classes and Properties landing page.

How to define a class group for a work pool

If you use the New Application wizard to create an initial application, it creates a class group for the work pool automatically, incorporating good design practice.

If you do not use the wizard, designing a class group for a work pool and for the corresponding Work- classes involves several steps. Complete the following steps to create one class group and one work pool.

  1. Determine the parent class of all the classes that are to become associated with the class group.
  2. Designate one concrete class to be the "container". This class has the same name as the class group.
  3. Complete a class form for the container class. Make this a concrete class derived from Work-Object-, Work-Cover- or another appropriate class. Choose Is a class group in the This class field. On the Keys tab of the form, enter the property pyID as the only key part. When you save the class form, the system creates both the class you define, a history class, and a Class Group data instance. Choose the Short Description text carefully, it defines the application name.
  4. Complete the Class form again for each of the child classes derived from the container class. Select is a member of a class group for these classes. Do not complete the Keys array for these classes.
  5. Update the access groups of developers, testers, or users who need to use the application. Add the class group to the Work Pools list.
  6. Add properties and other rules as needed for the new classes.

Database keys for work items

The database key for instances in most cases consists of the class name concatenated with the instance name. However, the internal key for instances of a class in a class group consists of the name of the class group (the same as the name of the container class) concatenated with the instance name. (The instance name or internal key is formed from the values of the key part or parts.)

Class groups with dedicated database tables

For reporting, performance, and other reasons, it is often desirable to place the work items for a class group in a single, dedicated database table, rather than the default pc_work table. In development systems (only), the system can create a PegaRULES datable with the appropriate structure automatically as the class group is created. See More about Database Table data instances.

External classes

External classes cannot be part of a class group. Each external class has an associated Database Table instance (Data-Admin-DB-Table class).

Definitions class, container class, external class, internal key, Work- base class, work pool
Related topics Working with the PegaRULES database
Standard rules Atlas — Initial Class Groups

UpAbout Class Group data instances