The Building Blocks of a Pega Application

Rules and rule types
When you play a game of chess,you and your opponent agree to follow a specific set of instructions. These instructions govern game play,such as how each piece moves on the game board. These basic instructions are the rules of chess. 

When you model a case type in a Pega application,you configure the application with instructions to create,process, and resolve a case. These instructions are rules. Rules describe the behavior of individual cases. The Pega platform uses the rules you create to generate application code. 

Pega provides wizards that create and modify many of the rules in an application for you. For example,the Case Designer automatically creates rules to describe cases, processes,and UI forms. Much of the work of designing an application can be completed by using these wizards,although you may need to access a rule directly.

The following screenshot shows an example of a flow rule. A flow rule is used to describe a process. Pega Express and the Case Designer automatically create a flow rule whenever you add a process to a case life cycle.

Each rule is an instance of a rule type. Pega provides many rule types,with each type tailored to a specific type of case behavior. For example,Pega provides one type of rule to describe a process flow, and another type of rule to describe an automated email notification. You create an individual rule from one of the rule types provided by Pega. Each rule you create describes specific aspects of case behavior,such as a submission form or an audit process. The use of individual rules makes your application modular. By describing case behavior with modular,task focused rules,you can combine and reuse rules as needed. In this manner,rules are analogous to classes in Java or other object-oriented programming languages. For example,you create a rule to describe the content of an email to send toa customer regarding the status of a change of address. Your application automatically sends this email after the customer enters the old and new address. By creating the message as a separate rule,rather than embedding the message in the case life cycle,you can update the content of the email without impacting the rest of the business process. This modularity provides three significant benefits:
1. Versioning

System architects create a new version of a rule whenever case behavior needs to change. Pega maintains a history of changes to a rule,allowing system architects to review the change history and undo changes if needed. Since each rule describes a specific case behavior,the rest of the case is unaffected. For example,a system architect updates a UI form with instructions and removes a critical field. You can review the history of the form and revert back to the version before the changes were made,without changing other rules in the application.

2. Delegation

System architects 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 are approved automatically. 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 toUSD50,without submitting a change request for the application.

3. Reuse

System architects reuse rules whenever an application needs to incorporate existing case behavior. Otherwise,you must reconfigure the behavior every time the behavior is needed. 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.

Rules and rulesets
To package rules for distribution as part of an application,you collect rules into a group called a ruleset. If a rule is similar to a song,a ruleset is similar toan entire album. Just as you can copy the album to share with a friend and allow your friend to listen to your favorite song,you can share a ruleset between applications to allow several applications to use the same rules. 

Ruleset versioning 

System architects collect individual rules into a subset of a ruleset,called a ruleset version. To update the contents of the ruleset,you create a new ruleset version. Ruleset versioning allows system architects to easily update applications by providing access to an entire set of rules at once. 

You identify each ruleset by its name and version number. For example,an application to process expense reports includes a ruleset named Expense. You refer to the ruleset as Expense:01-02-03, where Expense is the name of the ruleset and 01-02-03 is the version number. 

The version number is divided into three segments: a major version,a minor version,and a patch version. 

The major version represents a substantial release of an application. A major version change encompasses extensive changes to application functionality. For example,the Accounting department uses an application to manage expense reports. If Accounting wants to extend the application to track employee time off for payroll accounting,you create a new major version of the ruleset.

The minor version represents an interim release or enhancements toa major release. For example, you need to update an expense reporting application to automatically audit travel reimbursements. You create a new minor version of the ruleset.

The patch version typically consists of fixes to address bugs in an application. For example,you notice that a field in the current version of an application is labeled incorrectly. You create a new minor version to correct the field label.

Each segment is a two-digit number starting at 01 and increasing to99. Ruleset version numbering starts at 01-01-01,and increments upward.