Pega Rules

A rule is a primary component of an application that determines how it will behave. Pega Platform applications have a variety of rules that define different types of behaviour. The rules specify how forms, user interface fields, workflows, and other program elements are displayed. The rules can be reused throughout the application by the system. This blog helps you to learn about Pega's rule in depth. Let's get started.

Pega Rules - Table Of Contents

• What do you mean by Pega Rules
• Creating a Rule
• Organizing Rules
• Rule Resolution
• Changing the Scope of the Rules
• Checking out a Rule
• Restoring a Rule to its Rrevious State
  
• Exploring the Rules in the Application
• Delegating a Rule or Data Type

What do you mean by Pega Rules

A rule is a highly customized and non-reusable instruction for expressing a specific case behaviour. A rule is a specific case behaviour that must be established and handled.
It is a fundamental element of a user's behaviour.

Forms, user interface fields, work process flows, and various other software pieces are all defined by rules. One could create a UI element to record an address in an app for obtaining replacement parts, for example, and then reuse the rule to record the order's postal and billing addresses.

Pega Rules:

Creating a Rule

Create data instances and rules with reusable application features to ensure that your project satisfies customer needs and saves time. By combining a rule name, type, set of rules, and class, you can give each rule a unique identity. The latest record application will ask you for details such as the identification, rules type, rule, and classes when you create the rule.

This data will help recognize the rules in your applications in a specific manner. Whereas the instance has been handled throughout a process known as rule resolution, this combination will allow an application to invoke the appropriate rule. Pega Platform uses Rule Resolution to determine which rule should be executed when an application calls a rule.

1. Click Create in Dev Studio's header, and choose the record category and type you want to create.

2. Give your record a name and define its main components in the record configuration box of the Create form:

1. Fill in the Label field with a short description of the record's purpose in the form of a sentence. Use up to 30 characters as a best practice. Pega Platform appends rule information to the rule name you enter to construct the fully-qualified name.
2. Optional: To manually change the value of the name key section of your record to something other than the default, click Edit in the Identifier box, then adjust the name. 
   This field's default value is To be determined. The system populates this field with a read-only value based on the sentence you write in the Label field. The system ignores spaces and special characters. When you modify the Identifier value manually, the system no longer auto-populates this field after altering the Label value.
3. Fill in the blanks to add more essential details to your record. The number of essential components, categories, and constraints varies by record type. Start each crucial part with a letter and only use characters, numerals, and hyphens as a best practice.
4. Optional: View additional configuration options to see all of the record type's other customization options.
   These settings differ by record type and are only available for records that have Quick Create capabilities. One can make rules instantly in the Add dialog without actually opening the rule form if you choose the Quick Create option for specific rule kinds. This option includes attributes, field values, when conditions, flows, and activities as rule types.

If you want to enrich your career and become a professional in Pega, then visit Mindmajix - a global online training platform: "Pega Online Training" This course will help you to achieve excellence in this domain.

3. If the Development branch list is displayed in the Context section, choose a branch in which to save your record:

1. Select a branch name to create the record in a branched ruleset version. If the branched ruleset you specify does not already exist, the system builds it for you when you establish the rule.
2. Select [No branch] to create the entry in an unlocked ruleset version.

Once you establish a branch in the current implementation or maybe one of the built-on application levels, the form presents the Development branching lists.

4. Choose an application layer where you wish the record to be saved. Only records with access to the selected development branch can be stored in application layers.

5. Choose the class this record relates to in the Apply to the field. The system fills this list by default with instances and data types that your preferred application layer can access. Just choose a class at the bottom of the hierarchy that meets your application's requirements.

6. Select the type of a ruleset which will include the record in the Add to ruleset area. Enter an edition for the provided ruleset name if the development branch is set to [No Branch] or you don't have any available branches to select from.

7. Optional: Click the Down arrow key in the Work item to the associate field, then choose a work item to replace the standard work package that your applications connect with this development change.

8. Open by clicking Create.

Organizing Rules

Organize your application's components and rules logically and consistently to make it easier to manage. Rules can be organized into classes and rulesets to make them easier to reuse throughout application development. As a result, you save money and time on development.

1. Organizing rules into rulesets

Organize rules into rulesets to define, save, and maintain the rules that determine an app's repeatable components. One saves time by combining rules into a ruleset because then you can recycle an entire ruleset across multiple applications in your system rather than reusing or generating individual rules.

2. Organizing rules into classes

Organize your rules into classes for more practical application management. A class is a set of rules or other objects accessible to other classes or instances of the class, such as attributes, events, and HTML forms. While seeking a regulation to apply, Pega Platform puts classes into a hierarchy, and the system looks from the current class upwards.

3. Deleting a rule

Delete rules that are no longer relevant in your program to save storage space. For example, suppose you construct a field property to collect a phone number during application development, but you later need to capture numerous phone numbers. After that, you delete the field property and add a listed property. As a result, by giving only the rules that your application requires, you improve your program's extensibility and user understanding.

Want to Know More About Pega, Visit Pega Tutorial

Rule Resolution

It is a search method that the system employs to determine the best rule instance to use for the complete processing. With the help of automatic rule resolution, you may save time and guarantee that resources are deployed in the most effective way possible in a given scenario.

You could, for example, create an application to analyze loan requests and then use different approval criteria for ordinary loans and mortgages. A user selects a loan type in the application, and rule resolution discovers rules that carry appropriate approval requirements. In a separate case, you may give selected users an improved version of your software to collect feedback. Users who upgraded the application see a different UI version than users who used the application before the upgrade due to rule resolution at run time.

Changing the Scope of the Rules

By altering the scope of the rules, you can customize your application to meet specific business needs. A rule, for example, can be relocated to another class or ruleset so that it can be used in another portion of the program.

1. Moving rules

All previous instances, including references and indexes, are automatically removed from the system when a rule is moved.

2. Setting rule status and availability

Configure rule version and accessibility to build on the user information you provide and ensure that users are interacting with the correct version of your regulation at run time. You may also describe application behavior during rule resolution and how users can interact with rules at design time by setting rule status and availability. As a result, you can rest assured that your application will continue to function correctly even if users add extensions or make changes.

3. Creating a rule specialized by circumstance

Create a particular rule by circumstance to give a form of the rule that your application will only execute if certain conditions are met. You can meet changeable business requirements with out affecting the basic logic of your program by implementing specialized or situational rules.

4. Creating a rule specialized by a class or ruleset

Provide a version of a rule that is only triggered when your application resolves rules from a specific class or ruleset. When you establish the conditions for a rule resolution, you ensure that users engage with relevant actions and application behavior in a given circumstance. You save time and money by encouraging reuse throughout your application.

5. Defining the input parameters of a rule

You can set input parameters to limit what kind of data people can send to a rule. You can make decisions based on run-time data by including these input parameters in your rule logic.

6. Defining the pages and classes of a rule

When rules run, they can access or alter data on different clipboard pages. Most of these rule types have a Pages & Classes tab where you can specify essential details about the appearance of your clipboard pages during execution.

7. Rule skimming for higher ruleset versions

Skimming is the process of copying rules from one version of a ruleset into another. Skimming enhances the efficiency of your application by filtering out rules that the system cannot resolve. Skimming simplifies rule resolution and reduces the amount of rule data you ship to a different application version because the new ruleset only contains the highest rule versions.

8. Adding a custom field

Associating custom fields with criteria allows you to add metadata to the app, including a variation orders number or a logging files attachments, flexibly.

Would you like to ace Pega job interviews? Top Pega Interview Questions from MindMajix are exclusively for you!

Checking Out a Rule

Check out the rule to avoid inadvertent rule conflicts or modifications if more than one developer uses the same rule. The regulations will be securely secured and modified as a result of this. You may avoid making unnecessary rule modifications by double-checking a rule before editing it, resulting in a higher-quality application while also saving time.

1. Click Records in Dev Studio's navigation pane, expand the category that includes the rule you want to change, and then click the rule you want to change.
2. Check out is located in the header of the rule form. 
3. The original or base rule is copied into your customized ruleset by your application. No one else can check out this rule until you check in your changes.
4. As needed, change the regulation.
5. Save your work. Your changes are saved in the rule's checked-out version by your application. Only you will notice these changes. Only your checked-out version is resolved when rules are invoked in your application.

Restoring a Rule to its Previous State

You can undo recent changes to a rule and replace it with a previous copy during application development, even if another developer developed the newer copies.

• Open the rule in its most recent iteration.
• Select History from the menu bar.
• To see a collection of snapshots in a new window, click the View entire history button.
• The state you're looking for is shown in detail. Click the rule history button to open an older, historical state of this rule instance. The padlock symbol denotes that this is not the current rule, not that you have it checked out.
• To bring a state back to life, click the Restore button next to it.

Exploring the Rules in the Application

Examine the rules that define those characteristics to ensure that your application has all the features required by your business process. Duplication of resources can be prevented by exploring the rules before defining new features in the program, resulting in lower development costs and time.

1. Finding rules by type

The Records Explorer can be used to locate all instances of a particular class or rule type. You can easily find a rule if you know its kind but not its name by utilizing the Records Explorer instead of searching.

2. Finding rules by class

The Application Explorer can be used to locate rules that have the same class. You may rapidly locate rules in your application or inherited by your application without knowing their names by utilizing the Application Explorer instead of searching.

3. Finding rules by name

Follow the steps below to locate sibling rules, which are rules with the same name (key components) but distinct rulesets or versions.

4. Finding rules by dependency

With the Referencing Rules tool, you can save time on development and identify rules by dependence. You may rapidly identify a rule in context instead of executing a full-content search by tracing the link between the rules in your application.

5. Rule versions review and comparison

You can resolve merge conflicts, examine and debug code, and audit changes made by a developer when the rule was checked out by inspecting and comparing rule versions.

6. Comparing rules by system

The Rulebase Compare wizard could be used to compare and contrast the rules on two Pega Platform systems. The tool can evaluate the effectiveness of a product migration across platforms or discover the changes required to synchronize two systems, for example.

7. Bookmarking a rule

You can use favourites to save a rule so you can find it quickly later. You can make favourites that are only viewable to your operator, another operator, or all operators in a particular access group.

8. Searching for a rule

Non-deprecated rules, data objects, and the help system can be searched in full text in Dev Studio. You can do a topic search in the assistance system at any time. Index files kept by the system are used to search for rules and data.

9. Reporting on rules

Users may report on regulations of many types and rules that have been checked out. Scanning all occurrences of the classes inherited from the Rule-base class, or even all instances of the Rule-Service-class, for reporting reasons can negatively influence performance. You can define report definitions that query the database view corresponding to a given class to enable more efficient reporting.

10. Viewing rule history

You may look at a rule's preserved History to see when and by whom it was updated. For testing purposes or if the current version is erroneous, users also can evaluate the new edition with a previous model or recover a previous version of a rule.

11. Viewing rule versions

Select Actions to see the various rule variants. Versions are available to see. A dialog window emerges, displaying the rule's versions, availability, and situation. To access the rule form, click on an item.

12. Viewing the generated Java of a rule

Select Actions View Java after saving a rule form to see an estimate of the generated Java created by a rule instance.

13. Viewing the XML of a rule

Select Actions to examine the XML document that comprises the form that displays a rule instance if you have the @baseclass.ToolbarFull access. View the XML

14. Replacing a string in rulesets

Using the Search/Replace a String wizard, you may look for and replace a string anywhere in the PegaRULES database.

16. Finding deprecated rules in sections

Using an application update utility, locate parts that employ deprecated rules. These outdated rules can be located and modified to current regulations.

Delegating a rule or data type

To delegate a rule or data type so that your business line can configure simple application logic without IT intervention.

1. To delegate a rule or a data type, first, open it.
2. Select Delegate from the Actions menu.
3. Choose how the delegated rule will be interacted with by the end-user.

The delegated rule or data type determines the alternatives that appear.

• Manage content- Decision tables, map values, paragraphs, and correspondence rules can all be edited by users.
• Manage content and modify table- In addition to changing the contents of the map value table, users can add, change, or delete rows and columns.
• Manage data records- Users can add, change, or delete data entries for certain data kinds.
• Manage SLA- Users can set goals, deadlines, and escalation steps for SLAs.

4. Select the accessibility group to which you wish to delegate the rule or data type from the Delegate to access group drop-down list using the Directional arrow.

5. Give the delegated rule or data type a name in the Title box.

6. Detailed information about the delegated rule or data type should be entered in the Detailed Description field. The user can see this text.

7. Provide details on how the application will be affected by the delegated rule or data type. Consider the following illustration: "This delegated decision table uses logic to decide whether a travel request needs extra manager approval. Changing the reasoning in this decision table could impact all subsequent trip requests received through this app."

8. A delegate is selected by clicking on it.

Importing the Legacy Ruleset From the Resource Kit

Extremely outdated regulations which are no longer included in the Pega Platform release must be imported from the Resource Kit by applications that require them.

You can import legacy rules from the Pega Platform Resource Kit if your applications employ deprecated rules that are no longer available in the Pega Platform distribution media. The size of a Pega Platform installation is reduced by removing these obsolete rules. The reduced installation also minimizes the size of the rule database and reduces the time it takes to install and upgrade.

Legacy rules can be found in the PegaLegacyRules:01-01-01 Resource Kit on the Pega Platform media if your application still needs them.

1. By selecting ConfigureApplicationDistributionImport from the Resource Kit, you can import the legacy ruleset.
2. Select the distribution media from the drop-down menu ResourceKit\Utilities\PegaLegacyRules, and click next
3. On the confirmation screen, click Next. The next screen shows a list of rules that contradict legacy rules and are already in the system in a different ruleset.
4. Check the boxes next to the rules you'd like to load. This replaces existing rules with the same name, resulting in incompatibilities with applications that use those rules. If you don't load the rules, the rules related to these instances may not work correctly.
5. To finish the import procedure, click Done.
6. Open the definition of the application.
7. Save the definition after adding the PegaLegacyRules:01-01-01 ruleset to the list of application rulesets.

Related Article: Salesforce Vs Pega

Renaming Classes or Rulesets During an Archive Import

Alter classes or rulesets in an archive as it is imported with the Refactor on Import wizard. This allows you to incorporate the imported structure into your system's existing hierarchy. The Refactor on Import procedure allows you to merge Pegasystems or third-party RuleSets into your PegaRULES database.

The Refactor on Imported wizard shows a list of the classes in the archive and allows you to specify which classes will substitute the top-level and Data-classes for regulations in the archive. The instructions in the *.jar or *.zip files are read into memory, updated with the modifications, and then transferred to the Pega Platform database upon importation. The import archive is unaltered. Rules that do not verify when saved generate errors, yet all rules are saved to the database.

1. Click ConfigureSystemRefactorRules in the Dev Studios header.
2. When importing, select Refactor.
3.To import a file, choose one of the following:

• Click Next if the file already exists in the server's ServiceExport directory.
• Click Choose file and follow the directions to upload a new file.

4. Click Next after selecting the name of the file you want to import.

5. Select new class names and optional new ruleset names to apply to each imported class or ruleset, then click Next.

6. After you've double-checked that the modifications are correct, click Next.
To create a complete list of the rules that will be altered, click ExportToExcel. Before starting the operation, you can use the spreadsheet to examine the implications of renaming the class.

7. Next should be selected.

8. Change whatever additional rules you want. You'll notice a list of additional rules to edit if the archive contains rules that the system can't properly recognize as a class or ruleset name. Only the instances on the current page are selected using the check box at the top of the column.

9. Optionally, select Convert To Spreadsheet to create a spreadsheet of the presently displaying page or Convert All To Excel to create a spreadsheet of the entire report to review the additional conditions beyond the wizard.

10. Check the lists of any rule occurrences you picked to be refactored but are unable to alter. More information about the error can be seen by hovering over the error message in the Status column. Click Export All To Excel to see the status of all rules outside of the wizard.

11. Finish by clicking the Finish button.

Omitting History Snapshots for Data Types

We could choose not to take history snapshots while developing data types if you want to increase performance and manage your resources more efficiently. Before you apply a modification to a data type's value, the system creates a snapshot of the prior instance if you need to restore the data type to its former state. When there are a lot of changes, skipping the snapshot can save you time and money.

In the following cases, you can select not to take a picture of a data type:

• A data type is nothing more than an addition that stays the same throughout the entire business process.
• Snapshots are less useful because the frequency of updates to a data type is high.
• Because each snapshot is a BLOB write, having many snapshots can slow things down.
• You put in place your history-saving policy.

Snapshots are saved in the History-class of a particular data type by the system.

1. Click Data types in Dev Studio's navigation window.
2. Click MoreView definition after hovering over a data type.
3. Select the Advanced tab on the data type rule form.
4. Select True in the Bypass History on the Save section.
5. Save the file.

Conclusion

We are at the end of the blog. So far, gone through everything there is to know about Pega rules in this post. We hope this information was helpful to you. If you have any queries or if you have any suggestions, feel free to mention them in the comment box given below.