What is rules in pega

 What is rules in pega

1. 1. What is Rule in Pega? § Rules arethe building blocks of applications § A Rule type is a concrete class derived from the Rule- baseclass. § A Rule is a named object that defines the behavior of part of an application § A Rule is a single instance of a class derived fromthe Rule- class § Example: Rule-Obj-Property is a Rule Typeand a Property named User Name is Rule What is Case? § A business transaction thatis initiated, processed, and resolved § A case typically consists of assignments, processes, businesspolicies, and potentially other cases § A case is a instanceof a concrete class (Case Type) derived fromWork- Cover- class Example: Purchaserequest What is Process? § Process is represented as Flow in PRPC § Process or Flow defines: – How work items are created – How they progress through oneor moreflow executions – How they become resolved (completed) § Example: Loan lending process
2. 2. What is Class? § Class is a container of Rules like Properties, Sections, Flow actions, Data Transformand many other rules § Many Rules apply to a specific class, and potentially to subclasses of that Class § Classes can be Abstract or Concrete – AbstractClass is only a container of rules and data and cannot be persisted in database – Concrete Class contain rules and data and it can be instantiated and persisted in database – Concrete Classes may inherit froman AbstractClass Class Hierarchy is a hierarchy for storing Rules and Data in PRPC What is Rule Resolution? § Rule resolution is internal search algorithm that the systemuses to find the best or most appropriaterule § This algorithm uses many factors like Rule Name, Applies To Class, Rule set etc., Example: A property named FullAddress is present in Person Class and Location Class. While capturing a person’s address information, systemwilluse FullAddress property fromPerson Class. What is Inheritance inPega: § Inheritancedefines the association between classes – Parent Class – Sub-Class/Class § Pega provides two types of Inheritance – Pattern and Directed
3. 3. – Directed Inheritanceis defined by User Pattern Inheritanceis enforced by the Systembased on Class Name Class Hierarchy: Example What is Ruleset inPega? § Ruleset is a container of rules § All rule type mustbelongs to a Ruleset. § Purposeof ruleset as container is different – Access Control – Migration – Versioning § Ruleset is a bigger container than a class Contains related classes and rules MyCo Commercial Lines Auto Policy Admin Claims Processing Property Policy Admin Claims Processing Personal Lines Auto Policy Admin Claims Processing Home Policy Admin Claims Processing
4. 4. Ruleset Name &Ruleset Version: § Ruleset has 2 parts – Ruleset Name & Ruleset Version § Ruleset Name – Maximum 64 characters – Ex. PolicyAdmin § Ruleset Version – Has 3 parts separated by a hyphen – Major, Minor & Patch – Ex. 01-05-07 What are Components in Pega Designer Studio? § Designer Studio – Header – Explorer Panel – Work Area – Developer Toolbar What is Designer Studio: § High-productivity portalfor application designers § Launched from any browser § Steps to view Designer studio : 1.Launch the Pega server URL 2. ProvideUsername and Password 3.Launches Designer Studio with features based on access group
5. 5. Components – Header – Global access to the application via wizards, tools and landing pages – Explorer Panel – Organizesimilar actions and tools to keep architects focused and efficient o Provides navigation mechanismto access application records – Work Area – Main workspacefor architects – Developer Toolbar – Provides tools for debugging, performance analysis, and understanding how an application is built. Types of Explorers inDesigner Studio: Recent Explorer: § View, open and search the recent items opened in the Work Area. § Available as “Recent Items” in Header Case Explorer: § Reviews and updates the application’s casehierarchy § Replaces functionality in the Case Designer landing page Data Explorer: § Creates, modifies data object types and their associated data pages(Declare Pages). App Explorer: § Hierarchical view of the rules in the application stack § Application Explorer as in Pega 6.3 Records Explorer: § Explores both Data and Rule instances § Rules explorer in Pega 6.3
6. 6. Private Explorer: § Displays currently checked out rules by the operator. § Available as “My Checkouts” in Header Favourite Explorer: § View, edit and open favorite rules Pega Testing/Debugging &Performance Tools Overview: § Tracer : Debugging tool fully cross-browser and supports severalnew event types. § Clipboard : In-Memory allocation displays all pages and Made Cross browser and localizable § UI inspector : Analyzethe User Interfaceelements – Displays the application structurein the context of UI rules and elements by Hover over the UI item § Performance : Open PAL and now browser compatible § Alerts : View alert logs in readable format § InspectionPrefs : Enable/Disable the Declarativeand Field Value inspectors

 

Getting started with low-code application development

Start building your applications in a user-friendly and seamless way by implementing low-code digital solutions. Save time when you create your applications by using templates, develop various aspects of your application by engaging collaborators with different skills and roles, and increase work efficiency by configuring your application for reuse. To meet your unique needs, use of the authoring portals that Pega Platform supports.

Pega Platform offers multiple tools that you can use based on your experience, role, and level of expertise. You can use the following authoring portals to develop your applications:

App Studio

Select this portal if you are a citizen developer, a front-end developer, a business analyst, or a data engineer. App Studio holds a great variety of low-code, time-saving solutions for you to implement during your application development. With a real-time UI design, any person that is involved in a business process can contribute to application planning and development. App Studio supports the Pega Express methodology that is a goal-oriented and user-friendly approach to designing business processes. The Pega Express methodology uses visual tools to bring technology and business closer together towards reaching a shared goal.

For more information, see App Studio overview and Creating a Microjourney for customer success.

Dev Studio

Select this portal if you are an experienced application developer, a security administrator, or an account administrator. Dev Studio offers tools for advanced application configurations, such as versioning, rules management, or branched development.

For more information, see Dev Studio overview.

Admin Studio

Select this portal if you are a system administrator. In Admin Studio, you can monitor and manage your system resources, such as nodes or background processes.

For more information, see Admin Studio overview.

App Studio

Select this portal if you are a citizen developer, a front-end developer, a business analyst, or a data engineer. App Studio holds a great variety of low-code, time-saving solutions for you to implement during your application development. With a real-time UI design, any person that is involved in a business process can contribute to application planning and development. App Studio supports the Pega Express methodology that is a goal-oriented and user-friendly approach to designing business processes. The Pega Express methodology uses visual tools to bring technology and business closer together towards reaching a shared goal.

For more information, see App Studio overview and Creating a Microjourney for customer success.

Dev Studio

Select this portal if you are an experienced application developer, a security administrator, or an account administrator. Dev Studio offers tools for advanced application configurations, such as versioning, rules management, or branched development.

For more information, see Dev Studio overview.

Admin Studio

Select this portal if you are a system administrator. In Admin Studio, you can monitor and manage your system resources, such as nodes or background processes.

For more information, see Admin Studio overview.

Rule resolution

 Rule resolution is the search algorithm that the system uses to find the best or most appropriate rule instance to apply in a situation.

Rule resolution applies to all but a few rule types — classes that inherit from the Rule- class. Rule resolution does not apply to instances of classes derived from the Work-, Data-, or any other base class.

While the rule resolution algorithm is fast and invisible, it is important to understand how it operates. As you create applications, make your choices of values for key parts based on how you want rules to be found by rule resolution.

An in-memory rule cache helps the rule resolution process operate faster. If the system finds an instance (or instances) of the rule in question in the cache, it accepts what is in the cache as the candidate rules and skips many steps in the resolution process (see below).

The benefits of rule resolution include:

• Rules can be shared across applications and organizations. Sharing and reuse are major benefits of object oriented software development.
• Rules defined at a higher level can be overridden by more specific rules defined at a lower level. While this dilutes the sharing benefit, it provides often needed flexibility while bringing visibility to exceptions.
• Rules can have multiple versions, even within one ruleset, and security rules control which users see and execute which versions. This facilitates application evolution, testing, and patching.
• One Pega Platform system can host multiple applications, multiple organizations, and multiple versions of one application with minimal concern for conflicts and interference.
• Applications can be developed independently from other applications, yet all can depend on common rules that are locked (and so won't change).

Overview

The inputs to the rule resolution process are:

• The key parts of a rule instance being sought, such as its Applies To class and name
• The user's ruleset list, assembled when the user logs in
• The class hierarchy — the structure of parent classes and subclasses below the ultimate base class
• The user's access roles and privileges held, determined by the access group
• Security and access control rules, such as Access of Role to Object rules and Privileges
• Rule availability — which rules are available, blocked, final, withdrawn, or not available
• Whether time and date limitations affect which rules are available for this session
• In some cases, the value of a circumstance property

The output of the resolution process is the first rule found that matches all the criteria. (Sometimes no rule instance is found, and execution stops.) The system then executes the selected rule. Often this causes one or more additional rules to become needed. These are also found by rule resolution.

The rule resolution process

The steps in the rule resolution process are as follows:

1. Check the Rules Cache.

   Using rules already in the rules cache avoids additional database lookups.

   If the rule is there, go to Step 8. If not, continue to Step 2.

2. Choose instances with the correct purpose.

   The purpose, or "family name" combines all the key properties of a rule, excluding the "defined on" class.

   For an activity rule, the key properties include:

   • the Applies To class that the activity is defined on
   • the activity name

   The purpose in this case is the activity name.

   For a Field Value, the key properties include:

   • the Applies To class, as above
   • the Field Name
   • the Field Value

   The purpose in this case is the Field Name plus the Field Value, for example " pyActionPrompt.ViewHistory ".

   The system chooses all items of the appropriate purpose and puts them in a temporary list.

3. Discard rules where Availability = No.

   The system drops unavailable rules from the temporary list.

4. Discard inapplicable rulesets and versions.

   The system drops from the list rules that belong to rulesets and versions that are not enabled for the current requestor. For instance, if the user's profile includes the ruleset version ThisRuleSet: 05-01, rules belonging to ThisRuleSet: 04- or ThisRuleSet: 06- are dropped.

5. Discard all candidates not defined in a class in the 'ancestor tree'.

   Only rules found in classes from which the current class descends by either pattern or direct inheritance will be retained in the list.

   Note:

   This step is not used for rules which do not have the Use class-based inheritance to arrive at the correct rule to execute check box selected in their class definition.
6. Rank remaining stack of rule candidates and discard the choices after the first base rule.

   The system ranks the remaining rules on the list in order of

   • Class
   • Ruleset - note that default rules that have been saved to a branch or privately checked out are in their own ruleset.
   • Circumstance
   • Circumstance Date
   • Date/Time Range
   • Version

   The following example shows rules ranked from top to bottom. Rules that have been designated as a base rule are indicated as such. 1. MyRule in MyRuleset 01-01-05 Circumstance by Property: .pyLabel = Green 2. MyRule in MyRuleset 01-01-05 Circumstance by Property: .pyLabel = Yellow 3. MyRule in MyRuleset 01-01-05 Base rule 4. MyRule in MyRuleset 01-01-04 5. MyRule in MyRuleset 01-01-03 Circumstance by Property: .pyLabel = Yellow 6. MyRule in MyRuleset 01-01-02 Circumstance by Property: .pyLabel = Green 7. MyRule in MyRuleset 01-01-02 Circumstance by Property: .pyLabel = Red 8. MyRule in MyRuleset 01-01-01 Circumstance by Property: .pyLabel = Green 9. MyRule in MyRuleset 01-01-01

   Note that:

   • The ruleset and version rankings are based on the ordered list in the user's profile.
   • A rule with a specific qualifier ranks higher than one with no qualifier.
   • Circumstanced rules rank alphabetically by Circumstance value.
   • Circumstance Dates rank in descending value.
   • Date/Time ranges rank first by their end-date (in ascending order) and then by their start-date (in descending order).
   • Rules that do not have the Use class-based inheritance to arrive at the correct rule to execute check box selected in their class definition are not ranked by class.

   In the above example, if the MyRule is the rule being searched for, the match is at line 3, and all rules below line 3 are discarded.

7. Set the cache.

   The process adds the rules that remain on the list to the cache as being selectable for use.

8. Find the best instance and check for duplicates.

   The process searches down the list for the first rule that:

   • exactly matches a Circumstanced Rule
   • has the correct Circumstanced Date
   • is in the correct Date/Time Range
   • is the default Rule, with no qualifiers

   When it finds a rule that matches these conditions, the process checks whether the next rule in the list is equally correct. If it is, the process sends a message that there are duplicate rules in the system and stops processing.

   If no duplicates are found, the system prepares to use the rule that matched the listed conditions.

9. Check Availability is not Blocked.

   The process checks Availability again, to see whether it is set to Blocked for this rule. If it is, the system sends a message that it could not find an appropriate rule to use.

10. Verify requestor is authorized to see the rule.

    The process finally verifies that the requestor has authorization to access the selected rule. If so, the system uses it. If not, it sends a message that it could not find an appropriate rule to use.

Example

Your use of an application can cause Pega Platform to search for a flow named Repair in the class Work-Contract-Application-Complete.

The system first examines in the Work-Contract-Application-Complete class, and then (if no match is found) searches higher classes in the class hierarchy. Only flows belonging to rulesets and versions that are present on your ruleset list are candidates.

Exceptions

A few rule types have instances that are not associated with a ruleset and version and no rule resolution processing occurs when an instance of these classes is needed. For example, access roles ( Rule-Access-Role-Name rule type) must have names that are unique system-wide.

Additionally, some other rule types do not support circumstanced processing.

What is rule availability in Pega?

 What are the types of rule availability in Pega?

 1. Available 

2. Not Available 

3. Withdrawn

 4. Blocked 

5. Final

In the Availability list, select an option to control how your application selects the rule during rule resolution:

• You cannot change the availability of some rule types, such as classes and rulesets, which are always available to users.
• To consider the rule in rule resolution, select Available.
• To exclude the rule from rule resolution and disable validation logic so that you can continue to edit the rule even if errors occur, select Not available.
• To consider the rule during rule resolution but to stop processing and return an error to the user when the user selects the rule, select Blocked.
• To consider the rule during rule resolution but to prevent users from extending the rule by copying it to a different ruleset, unless the ruleset is a higher version of the current ruleset, select Final.
• To exclude the rule and all instances with the same name, in previous versions of the same major-version ruleset, from rule resolution, select Withdrawn.

Troubleshooting final rules

After a rule is marked as final, no one can create a second rule with the same visible key in any ruleset other than the ruleset that the first rule belongs to. If the ruleset version of a final rule is locked, you cannot create a second rule with the same visible key in any version of any ruleset, except a higher version of the ruleset containing the final rule.

You cannot override a final rule except through a higher version in the same ruleset. Many rules in the Pega-* rulesets are marked Final because correct operation of these rules is essential to ensure the integrity and security of your system. However, most standard rules have the Availability field set to Available rather than Final; you can override those rules in your application.

TMF and PMF

About the Test Management Framework:

 The Test Management Framework is a ready-to-use application that implements best practices for the testing and deployment of new applications and incremental changes to existing applications.

With the Test Management Framework, you can:

• Improve the quality of your applications by managing testing across multiple test environments
• Create and maintain complete test coverage to ensure nothing is missed in the test cycle
• Directly leverage the actors, use cases, and automated unit test cases created by Direct Capture of Objectives and Automated Unit Testing in your test environments
• Track test results and record details when tests fail
• Produce a comprehensive set of documentation and reports including test plans, progress reports, and quality monitoring
• Accelerate your test planning, scheduling, and execution cycles
• Manage tester workloads

Installing the Framework

TMF V6.1.1 is installed into a Process Commander V6.1 SP1 environment that is separate from the V6.1 SP1, V5.5 SP1, V5.4 SP2 or V5.4 SP3 environments where target applications reside.

	TMF 6.1.1 on:	Target test applications on:
Process Commander version	V6.1 SP1	V6.1 SP1 V5.5 SP1 V5.4 SP3 V5.4 SP2

Installation is a process that involves:

• Loading database tables and RuleSets into the Process Commander system that holds the Test Management Framework
• Loading an additional RuleSet into the target environments, the systems that hold the applications for which you want to test application and functional changes

Installation instructions are included on the distribution media for the framework. Click Test Management Framework V6.1.1 Installation Guide to download a copy. see in pdn otherwise i will share the information also