CSA备考笔记 Mission03—Roles/Dev Studio/Rules

Roles on a Pega project

Depending on the project goal, you may need to assemble a mix of team members and roles.Some projects are small in scope, other projects are more expansive.The common roles found on larger Pega projects:

• Consulting Solutions Executive
• Specialty Architects
• Product Owner:Creates acceptance criteria and prioritizes backlog items
• System Administrator and IT resources
• Scrum Master
• System Architect
• Subject Matter Expert:Has deep knowledge of a particular business topic or domain
• Business Architect
• Quality Assurance:Creates and executes functional and performance test scripts
• Citizen Developers:Non-technical business users who participate in application development
• 
• 

The tasks and responsibilities for each role may overlap or are accomplished by multiple roles.

• 

Dev Studio overview

Dev Studio
Robust, enterprise-grade Pega Platform™ applications depend on cooperation between two key groups of application developers.

• Domain experts — business analysts, citizen developers, and front-end developers — provide valuable insight into processes and user needs.
• Implementation experts — system architects, full-stack developers, database administrators, and security administrators — provide the expertise needed to address critical use cases that require complex configurations.

In App Studio, domain experts can access core application development features (case design, data management, and user experience) and apply their knowledge to improve development outcomes. To support advanced rule configuration in applications, Pega Platform provides implementation experts with a second development environment, Dev Studio. In Dev Studio, implementation experts access rule forms directly to address complex or less-common configuration requirements. In addition, Dev Studio provides features for configuring security permissions and access control, managing rules to promote reuse, and addressing the performance limitations of an application.

Co-develop solutions
Business analysts and citizen developers understand business needs. System architects understand the capabilities of Pega Platform. To help these two groups work together, Pega Platform enables a co-development approach that embraces the strengths of each group.

Promote reuse throughout the organization
In App Studio, developers configure rules such as processes, views, correspondence, and service levels for a single case type.
In Dev Studio, developers access all the layers of an application and can extend the rule scope from a single case type to an application, division, or even the entire organization to create a library of standardized, reusable rules.

• Dev Studio allows developers to create application components that business analysts and citizen developers can add to case types in App Studio.(Using Dev Studio, developers can configure entire forms and processes that provide functionality not available in App Studio. Using App Studio, developers can add these views and processes, even if they contain elements not available in App Studio.)

Relationship between studios as needed

• Application developers can switch between App Studio and Dev Studio as needed to configure rule behavior.
• Developers can use Dev Studio to combine rules into solutions such as completed views or processes for use in App Studio.
• Developers in App Studio and Dev Studio configure the same rules, but Dev Studio provides more configuration options.

Some common App Studio elements have the different names used for those elements in Dev Studio.

Creation and maintenance of rules

Rules and rule types
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 rules. Rules describe the behavior for individual cases.Pega Platform uses the rules you create to generate application code in the background.

Each rule is an instance of a rule type. Pega Platform provides many rule types to use as templates for creating a rule. The rule type determines the type of behavior modeled by the rule. Each rule type models a specific type of behavior.

Much of the work of designing an application can be completed using App Studio. Pega Platform provides a simplified interface that automatically creates and manages the underlying rules while allowing developers to focus on business tasks.

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. This modularity provides three significant benefits:

• 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.

• 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.

• Reuse: Developers reuse rules whenever an application needs to incorporate existing case behavior.

• A rule is an instruction for describing a specific case behavior, such as a process or automated decision.

Rulesets
To package rules for distribution as part of an application, you collect rules into a group called a ruleset. A ruleset identifies, stores, and manages the set of rules that define an application or a significant portion of an application. If a rule is similar to a song, a ruleset is similar to an entire album. You can share a ruleset between applications to allow several applications to use the same rules.

Developers collect individual rules into an instance of a ruleset, called a ruleset version. To update the contents of the ruleset, you create a new ruleset version. The new ruleset version is available — or unlocked — for the developer to make rule updates and add new rules. Ruleset versioning helps developers identify and manage changes to an application. Pega identifies rulesets by names and version numbers. The version number is divided into three segments:

• A major version:The major version represents a substantial release of an application. A major version change encompasses extensive changes to application functionality.
• A minor version:The minor version represents an interim release or enhancements to a major release.
• A patch version:The patch version consists of fixes to address bugs in an application.

Each application consists of a sequence of rulesets called a ruleset stack. The ruleset stack determines the order in which Pega Platform looks through rulesets to find the rule that is in use. Each entry in the ruleset stack represents all the versions of the specified ruleset, starting with the listed version(=) and working down to the lowest minor(≤) and patch(≤) version for the specified major version.

Each version of an application contains a unique ruleset stack. The ruleset stack allows an updated application to reference new ruleset versions that contain updates and new features.

Rule creation
When you create a rule in Dev Studio, the New Record form prompts you to provide four pieces of information:

• Rule type: determines the type of behavior modeled by the rule.
• Identifier: identifies the purpose of the rule.
• Class: The class identifies the scope of the rule. You specify the class of a rule in the Apply to field.
• Ruleset: The ruleset is the container for the rule.

This information is used to identify the rule uniquely within your application. This combination allows an application to call the correct rule during case processing, through a process called rule resolution.

You can access the New Record form several ways based on how you create a new rule, the manner of rule creation determines the amount of information that is automatically entered.

Rule updates
Developers often secure rulesets to prevent unauthorized or unintended changes to rules. Securing a ruleset in Pega Platform helps to maintain the integrity of rules, adds an audit trail, and relies on an explicit action to add and update rules.

Only delete rules if they belong to the current version of an application or ruleset. To edit the rules in a secured ruleset, you either check out the rule or perform a private edit.A private edit provides a nonexclusive check out of a rule; this allows other developers to edit a rule at the same time. Private edits are useful for quick debugging without interrupting development by other team members. This option is not available in App Studio.

The check-out feature is used to manage changes to rules when multiple developers work on an application. This feature allows a developer to update a rule while preventing updates from other developers. Rule check-out creates a copy of a rule in a ruleset that is visible only to you, called a personal ruleset. The personal ruleset occupies the top spot in the ruleset stack. The rules in your personal ruleset override rules in the rest of the application. This allows you to test your changes to the rule without affecting other developers. After you update the rule and test the changes, you check in the rule. Checking in the rule updates the application ruleset with a new version of the rule.

It is a best practice to lock older versions of a ruleset to prevent changes. To update a rule in a locked ruleset version, save the rule to an unlocked ruleset version, then check out the rule if necessary.

Classes and class hierarchy

• Within an application, Pega Platform groups rules into classes according to their capacity for reuse.

Each grouping is a class. Each application consists of three class types.

• The Work class contains the rules that describe how to process a case or cases, such as processes, data elements, and user interfaces.
• The Integration class contains the rules that describe how the application interacts with other systems, such as the integration assets that connect the application to a customer database or a third-party web server.
• The Data class contains the rules that describe the data objects used in the application, such as a customer data type or order items data type.

A class can also contain other classes. A class that contains another class is a parent class, while a class that is contained by another class is a child class. A child class can reuse or inherit any of the rules defined for its parent class.

The classes that comprise an application are organized into a multi-level class hierarchy to organize application assets. Classes are organized from most-specific to least-specific in the class hierarchy. The class hierarchy determines how developers can reuse rules within the application. When attempting to identify the rule to use at run time, Pega Platform starts with the most-specific class and expands the search to increasingly general classes.

Rule reuse through inheritance
Pega Platform™ provides two methods for rule inheritance:

• Pattern inheritance is automatic. Pattern inheritance uses the class name structure to determine rules available to reuse. It searches classes that share a class name prefix.

• Directed inheritance is inheritance between classes where the parent class is explicitly specified. You apply directed inheritance to reuse standard Pega Platform rules and rules from other applications outside the business class hierarchy.

• Pattern inheritance allows you to reuse rules within a single application. Directed inheritance allows you to reuse rules in other applications, including standard rules provided as part of the Pega Platform.

When attempting to reuse rules through inheritance:

1. Pega Platform first searches through the parent classes indicated by pattern inheritance.
2. If unsuccessful, Pega then searches the parent class indicated by directed inheritance as the basis for another pattern inheritance search.
3. This process repeats until Pega reaches the last class in the class hierarchy, called the ultimate base class or @baseclass. If the rule cannot be found after searching @baseclass, Pega returns an error.
   

• Directed inheritance is the only option that allows an application class to inherit rules defined for the Work- class.
•