A rule is a basic building block of an application that defines its behavior. Pega Platform applications contain many types of rules that specify different types of behavior. Because rules are reusable, by implementing them, you can save time and resources when you build your application.
Rules define the display of forms, the UI fields, the flows for work processes, and multiple other software elements. The system can reuse rules throughout your application. For example, in an application for ordering replacements parts, you can define a UI element to capture an address, and then reuse the rule to capture the mailing address and billing address for the order.
You configure rules to create a business solution for your organization and customers. Rules provide flexibility during the development process and help you design applications more efficiently so that you can implement the rules again in future projects.
For relevant training materials, see the Creation and maintenance of rules module on Pega Academy.
- Creating a rule
To save time and ensure that your projects adhere to the unique needs of your clients, create rules and data instances using reusable elements of your application. By combining a rule type, name, class, and ruleset, you provide a unique identity for each rule that you create.
- Organizing rules
For an improved management of your application, organize its building elements – rules – in a logical and coherent way. You can group rules into rulesets and classes, so that you can conveniently reuse them during application development. As a result, you reduce development time and costs.
- Rule resolution
Rule resolution is a search algorithm that the system uses to find the best or most appropriate rule instance to apply to complete processing. By using automated rule resolution, you can save time and ensure that you implement resources in a way that is the most efficient in a given scenario.
- Changing the scope of rules
Adjust your application to your specific business needs by changing scope of rules. For example, you can move a rule to another ruleset or class, so that you can reuse the rule in a different part of your application.
- Checking out a rule
To avoid accidental rule changes or conflicts that might result from multiple developers working on the same rule, perform a check out, so that you can lock the rule and safely make changes to it. By checking a rule out before editing, you avoid unwanted rule changes, and as a result save time and maintain a better quality application.
- Restoring the earlier state of a rule
During application development, you can undo recent changes to a rule and replace the current rule with a previous copy, even if another developer created the newer copies.
- Exploring rules in your application
To ensure that your application includes all the features that your business process requires, explore rules that define these features. By exploring rules before you define new elements of your app, you can also avoid duplicating resources, and as a result, save time and development costs.
- Delegating a rule or data type
To delegate a rule or data type to enable your business line to configure simple application logic without involvement from IT, complete the following steps.
- Importing the legacy ruleset from the Resource Kit
Applications that require deprecated rules that are no longer included in the Pega Platform distribution need to import those legacy rules from the Resource Kit.
- Renaming classes or rulesets during an archive import
Use the Refactor on Import wizard to rename classes or rulesets in an archive as it is imported. This allows you to integrate the imported structure into the existing hierarchy on your system. The Refactor on Import wizard supports merging RuleSets developed by Pegasystems or others into your PegaRULES database.
- Omitting history snapshots for data types
To improve performance and manage your resources efficiently, you can choose not to take history snapshots when you develop data types. Every time a value in a data type changes, before you implement the change, the system takes a snapshot of the previous instance in case you need to restore the data type to the previous state. With multiple changes, omitting the snapshot can save you time and resources.