Class rules
|
|
Records can be created in various ways. You can add a brand new record to your application or copy an existing one. Existing rules can be specialized by creating a copy into a specific ruleset, against a different class or (in some cases) with a set of circumstance definitions. Data instances may be copied but do not support specialization as they are not versioned.
Based on your use case, the Create, Save As or Specialization form is used to create the record. The number of fields and available options vary by record type. Start by familiarizing yourself with the generic layout of these forms and their common fields:
This help topic then identifies the key parts and options that are applicable to the record type you are creating.
Create a new class rule by selecting Class
from the SysAdmin
category.
NOTE: Review standard and existing classes before creating new ones, as your application might only need new properties, not a new class. Many tools and wizards such as the Application Explorer and the Connector and Metadata accelerator create classes automatically.
A class rule has a single key part, its name:
Field |
Description |
Class Name |
Type the name of a new class. Choose each new class name carefully. When creating an abstract class, end the name with a dash character. As a best practice, make any top-level class you create — a class with @baseclass as its immediate parent — abstract. Class names can contain up to 64 letters, digits, or dash characters and must contain at least two characters. However, limit the length of the class names you enter here to 56 characters, as the system creates a History- class by prefixing "History-" to the class name you enter. Use a dash between segments to show the relationship to superior classes. Follow the dash by a letter as the first character in each segment. Class names must be unique system-wide. By convention, an initial prefix or portion of your class name matches a top-level class for the organization, which helps assure this uniqueness. You cannot create a class derived from the Code- or System- base classes. These base classes are restricted. Except in unusual situations, do not create a class derived from the History- base class. Such classes are created automatically. As a best practice, do not choose a name that matches or starts with the name of an existing class group, unless the class you are creating is to belong to that class group. This is allowed, but results in a warning message. The following are not valid as names for new classes:
As a best practice to help assure unique class names, identify an organization in the first segment of a class name. In the second segment identify a division; lower portions can identify more specific purposes. This convention does not limit how such classes can inherit rules, through directed inheritance. For example, MYCO-HR-APPLICATION can be derived from Work-, and MYCO-HR-JOBTITLES can be derived from Data-. |
The Add to ruleset field is required but not part of the key. Select a ruleset name to be associated with this class. This ruleset value is used only by the Archive tools and the Application Explorer tool.
You cannot add a class rule to a shared RuleSet.
In a development system that is connected to the PegaRULES database with an account with the appropriate capabilities, creating a new class derived from the Work-, Data-, Assign-, or History- base class in some cases automatically creates a new database table. See Working with the PegaRULES database — Schema changes.
New classes needed in your application are often derived from the Work-, Data-, or Embed- base classes.
The system does not use rule resolution or rule availability to find instances of the Rule-Obj-Class rule type. Choose class names that are unique system-wide, across all applications.
As soon as you save it, a new class is available immediately to all users and all applications. The system applies access control restrictions to the properties, activities, HTML, and so on that apply to the class (if any), but not for the class definition rule itself.
So although the new class is accessible to other developers, they cannot use its facilities until you update access groups, Access of Role to Object rules and other security rules.
The Availability value for class rules is always Yes
.