Rules in Pega applications
When you play a game of chess, you and your opponent agree to follow a specific set of instructions. These instructions govern gameplay, such as how each piece moves on the game board. For example, on its first move, the pawn can move one or two spaces forward. These basic instructions are the rules of chess.
Relatedly, when you model a Case Type in a Pega Platform™ application, you configure the application with instructions to create, process, and resolve a Case. These instructions are the Rules of the Case Type.
Rules are the basic building blocks of a Pega application that the project team can configure to create a business solution for the client organization and its customers. Pega Platform uses Rules to generate Java application code in the background. Pega Platform applications contain many types of Rules that specify different types of application behavior. Rules are flexible and reusable, which enables the project team to design application features more efficiently to implement them across multiple Case Types and applications.
In this topic, you examine Rules in more detail.
Automated Rule creation in App Studio
Pega's low-code approach means users can complete much of the work of designing an application in App Studio, especially early in the application development process. With the addition of a workflow automation in App Studio, Pega Platform automatically creates and manages the underlying Rules in Dev Studio. For example, when you configure a Case Type in App Studio, you use the Case Life Cycle Designer and configuration panes to add a View to a Collect information Step. In the background, Pega Platform creates and manages the Rules that define the Process Flows and UI.
In the center of the following image, slide the vertical line to see the Case Life Cycle with a Process created in App Studio and the Flow Rule of the Process that the system creates in the background:
Note: Each Step in the Case Life Cycle corresponds to a Shape in the Flow Rule. A Flow Connector links one Shape to another and represents the Task or Assignment that users must complete to get from one Shape (Step) to the next.
The ability to create complex Rules with App Studio's user-friendly interface is the key to the low-code functionality of Pega Platform.
While developers of all technical skill levels are in App Studio creating workflow automations using the low-code, visual modeling, Pega Platform is hard at work in the background creating the technical Rules that correspond to those automations. As a result, Business Architects and other less-technical developers on the project team, such as Citizen developers, can focus on defining business tasks rather than code.
Note: The technical Rules are accessible to more advanced, technical developers through Dev Studio. The more technical Rules that developers create in Dev Studio can be made available for users in App Studio.
Check your knowledge with the following interaction:
Application modularity with Rules
The use of individual Rules makes an application modular. By describing Case behavior with modular, task-focused Rules, Rules can be combined and reused as needed. For example, a rule is created to describe the content of a customer email regarding the status of a change of address. By creating the email message as a separate Rule, rather than embedding the message in the Case Life Cycle, the content of the email can be updated without impacting the rest of the business process.
This modularity provides three significant benefits: versioning, delegation, and reuse.
| Versioning | Developers create a new version of a Rule whenever Case behavior needs to change. Pega Platform maintains a history of changes to a Rule, allowing developers to review the change history and undo changes if needed. Because each rule describes a specific Case behavior, the rest of the Case remains unaffected. | For example, a developer updates a UI form with instructions and removes a critical field. You can review the history of the form and revert to the version before the changes were made without changing other Rules in the application. |
|---|---|---|
| Delegation | Developers delegate Rules to business users to allow business users to update Case behavior as business conditions change. The business user updates the delegated Rule, while other parts of the application remain unchanged. | For example, expense reports that total USD25 or less receive automatic approval. You create a Rule to test whether an expense report totals USD25 or less and delegate the Rule to the Accounting department. The Accounting department can then update the rule to increase the threshold for automatic approval increases to USD50 without submitting a change request for the application. |
| Reuse | Developers reuse Rules whenever an application needs to incorporate existing Case behavior. Otherwise, you must reconfigure the behavior every time you need the behavior. | For example, you create a UI form to collect policyholder information for auto insurance claims. You can then reuse this UI form for property insurance claims and marine insurance claims. |
Note: To learn how to delegate a Rule, see Delegating a Rule or data type. To increase the reusability of a Rule, use parametrization to drive the Rule's logic based on the value passed as a parameter instead of hard-coded data. Parametrization helps to reduce the duplication of code and implementation time of Rule specializations. To learn more about parametrization, see Defining the input parameters of a Rule.
Organization of Rules
Although you do not spend time working directly with application Rules in Dev Studio, it is imperative that you collaborate with your Lead System Architect to understand the organization of Rules for your application.
In Dev Studio, Rules are grouped into Classes and Rulesets so they can be easily used to develop applications.
Classes
In Pega, a Class describes a collection of Rules that the system groups according to their capacity for reuse. Each application consists of the following three types of Classes:
- Work Class: The Work Class contains the Rules that define the end-to-end "work" of processing Cases such as Processes, data elements, and user interfaces.
- Data Class: The Data Class contains the Rules that define the Data Objects that your application uses.
- Integration Class: The Integration Class contains the Rules that define interactions between the application and external systems of record, such as an external database maintained by the client.
Parent and child Classes
A Class can also contain other Classes. A Class that contains another Class is a parent Class, while a Class that is included in another Class is a child Class. A child Class can reuse or inherit any of the Rules that are defined for its parent Class.
In the following image, click the + icons to learn more about the parent and child Classes:
Note: For more information about Classes in Pega applications, see Organizing Rules into Classes.
Check your knowledge with the following interaction:
Rulesets
Rules are organized into Rulesets to identify, store, and manage the full set of Rules that define an application. Rulesets store the reusable functionality that you can migrate from one Pega application to another. For example, you can create a Ruleset to store Service-Level Agreement (SLA) Rules. You can reuse the SLA Ruleset in any application that processes Cases that require the same SLAs. The ability to save and reuse Rulesets speeds the time and reduces the cost of developing applications for the client.
Each Ruleset has a name, likely the name of your application, and version number. When you create a new Ruleset, the default version is 01-01-01. An example Ruleset name and version combination is GoGoRoad 01-01-01.
The version number is divided into three segments: a major version, a minor version, and a patch version. Each segment is a two-digit number starting at 01 and increasing to 99. Ruleset version numbering starts at 01-01-01 and increments upward.
In the following image, click the + icons to learn more about the versioning convention for Rulesets:
Starting in 2023, Pega Infinity product versions follow the format Year.Minor.Patch. For Pega Infinity '23, the product version is 23.1.1. The Pega Ruleset semantic versioning follows the format Major-Minor-Patch. For Pega Infinity '23, the Ruleset version is 08-23-02.
Note: Pega Infinity™ '23 is the latest minor release. For more information about the Pega Infinity product naming convention, see Pega software maintenance program.
Locked and Unlocked Rulesets
When a Ruleset is created, it is specific as either locked or unlocked. Developers work in unlocked Rulesets, and Ruleset locks prevent developers from making accidental changes. Developers must enter a password before unlocking and editing a locked Ruleset.
Note: For more information about Rulesets in Pega applications, see Organizing Rules into Rulesets.
The Lead System Architect (LSA) manages both the versioning and locking of any Rulesets related to an application during the development process. Consult with your project's LSA when questions related to Rules and Rulesets arise.
Check your knowledge with the following interaction:
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?