You are on page 1of 38

CLASS STRUCTURES AND HIERARCHY DESIGN 20 % of EXAM

MATERIAL FOR PRPC CERTIFICATION

System Architecture Understand the difference between a Business Rules Engine (BRE) and a Business Process Management System(BPMS)
Business Rules Engine (BRE) is a software system that manages business rules, it separates the business rules from the application code. Engine Types Inference Derives a conclusion based on a knowledge base Answers questions when a user or application submits them Example: Should this customer be allowed a mortgage? Reactive Detects and reacts to patterns of events occurring Performs an action automatically when a certain rule is violated Example: Alert a manager when certain items are out of stock No User Interface External systems communicate through open interfaces with the Rules Engine

Business Process Management System (BPMS) is a software system which allows for the direct execution of business processes. Removes the costly and time intensive development of process specific software Allows the full business process to be defined Can invoke external services to perform business operations Can send messages to human workers requesting they perform certain tasks Can call a Business Rules Engine to make automated decisions Provides a process driven User Interface

Pega Rules Business Rules Engine Separates business logic from your mission-critical applications and enables your enterprise to capture, manage and execute your business policies and practices Pega Rules Provides An inference engine to perform dynamic business decision making A reactive engine using declarative rules that are used only when underlying data changes This combination of rule types and processing approaches provides Rapid time to production Increased ROI

Identify the elements that comprise Process Commanders


Java EE architecture
PRPC Architecture Overview Secure, scalable, upgradeable application framework based on a declarative object mode Shared UI components, business logic, and data model Standard data model Integrated tool set for extending the data model, business logic, and user interface Pre-built services designed specifically for BPM Designed to integrate with an organizations existing IT infrastructure Architecture Key Concepts Application Server Java Java Enterprise Edition Multi Tired Architecture Enterprise Java Beans Servlets Java Server Pages Java Data Base Connectivity

Describe the function of each component of the process


commander architecture
Application Server is a software dedicated to the serving (running) of other applications Facilitates Programming productivity Provides dedicated standard APIs Response to demand Provides scalability, load-balancing, (re)configuration, deployment Integration with existing systems Provides standard services SOAP Message Queue DB Access Security Java is an object-oriented programming language developed by Sun Microsystems Syntax is similar to C Is compiled to byte code which is run by a Java Virtual Machine Java Virtual Machines (JVM) are available for many different platforms Java code can be run on any platform that provides a suitable JVM

Java vs. JavaScript Originally developed by Netscape Is typically interpreted by a Web Browser Does not use a JVM Only similarity to Java is the C like syntax Java Enterprise Edition is a platform for developing and running distributed multi-tier architecture Java applications Formerly known as Java 2 Platform, Enterprise Edition (J2EE) The Java EE platform is defined by a specification Platform vendors must agree to certain conformance requirements in order to declare their products as Java EE compliant Multi Tired Architecture is a client-server architecture in which an application is executed by more than one distinct software agent The Java EE standard facilitates a multi-tiered architecture Often referred to as n-tier architecture

Client Tier

Web Browser
Java EE Platform Database Server

Example

Web Tier
Data Tier

Enterprise java Bean is a server-side component that encapsulates the business logic of an
application EJBs are deployed in an EJB container within the application server

Client Tier Web Tier Business Tier EJB

Data Tier
Java Servlets are Java programming language classes that dynamically process requests and construct responses Servlets are deployed in a web container within the application server Typically generate HTML

Client Tier Web Tier Servlets Business Tier EJB Data Tier
HTML

Java Server Pages are Text based documents May contain HTML tags Contain Java specific tags May contain Java code pieces A JSP compiler is used to generate a Servlet from the JSP page Typically produces HTML

JSP

Web Tier JSP Compiler

Servlet

HTML

Java Data Base Connectivity is an application programming interface (API) specification for database connectivity -Encodes database request statements in structured query language (SQL)

Client Tier Web Tier

SQL

Business Tier JDBC Data Tier SQL

Describe how work objects and rules are stored in the


database
Users create work instances that are saved to the database while running an application Work is stored as XML documents which are written to the database Stored as Binary Large Objects (BLOB) System Architects can select Work data to be stored in standard columns allowing for improved reporting and querying

Users Work
XML

XML

Work Database
System Architects modify and create object instances that are saved to the database Known as Rules Rules are stored as XML documents which are written to the rule repository database At runtime the XML documents are parsed and converted to Java code for execution

System Architects Rules


XML XML

Java

Rules Repository

Reusability and Hierarchy Design Define reusability and its impact on application design
Reusability Of assets across an organization is integral to the success of a project By gathering the right requirements, and applying the principles of reusability and class hierarchy design heuristics, you will always create systems that deliver on the value promised . Ultimately, the reusability requirements drive the selection of your class hierarchy design pattern .

Describe the difference between application


reusability and organization reusability

Application Assets are specific to an application and common to more than one business unit

Understand the difference between one Off


application and a reusable application

For example, all divisions across BIG have some type of Policy Administration Organization Assets common across multiple divisions or applications For example, LDAP integration

Generalized Define a common interface for its sub-application Defers some of or all of its implementation to application assets defined in its sub-applications The assets that an generalized application declares but does not implement are called generalized assets.A solution framework is an generalized application

Specialized

Applications that are not generalized are called specialized applications One Off application is a specialized one.

Identify the scope of reusable components within a


companys organizational diagram
We can create reusable components for an organization, divisions and units and also for a group of users. We can design these components where ever the similar kind of functionality is seen across divisions, units and organizations.

Design and create an organizational structure comprised of


an organization, divisions, and business units
In PRPC the following rules are used for creating organization, Divisions, and Business Units. Data-Admin-Organization Data-Admin-OrgDivision Data-Admin-OrgUnit

Understand the concept and benefits of building on a


common application layer
If we want to develop a frame work which can be used by different independent vendors to implement solutions upon that we need to build a common application layer. This layer can be reused and customized according to the requirements. The basic functionality will be residing in this common application layer. For example if we develop a application layer for a banking domain, the same can be used by independent software vendors to develop/customize the application.

Design and implement reusable class structure with


appropriate top, divisional, and class group levels and work classes.
Always while designing the class structure, the best practice is we should apply class level sense according to the business hierarchical structure of the organization. Organization --- Division --- Unit levels can be transformed to Top level class --- Divisional level --- Class group level with respect to PRPC. Each class group level will be a unit / application where in different process can be initiated. By Default PRPC is shipped with and Organization called Pega.com.

Classes and Class Groups/ Work Pools Create Classes and Class Groups
A Class group is an instance of the Data-Admin-DB-ClassGroup. A class group instance causes the system to store the instances corresponding to two or more concrete classes that have a common key format in a single database table. Class groups are commonly used to cause the system to store instances of similar or related Work- concrete classes together in one relational database table. While Creating the class group we need to specify the key for the group. Generally it is pyID.

Understand the purpose of a class group and its relation to


the applications database and a users work pool
Different work types (classes derived from the Work- base class) are grouped in to one class group and when this class group is added to a user in his access group, user can work on through each work type of each class groups. Class groups so added are called as Work pools. Instances of Data-Admin-DB-Table are used for mapping the classes and class groups with DB tables. At any point of time, if a class is not mapped to any DB table, its instances are stored in its super classs mapped table. The principle is recursive. All the classes belonging to the class group will have the same keys of the class group.

Describe the difference between the abstract and concrete


classes
Abstract Classes can contain any rule type Cannot contain instances Great for reuse The name of a abstract class must end with a dash (-). Concrete classes hold persistent objects, known as instances Names must not end with a dash (-) Names should define the type of work being performed.

Understand the concept of top-level and base classes


Top level classes are always abstract and inherit from the @baseclass. Top level class is an abstract class that has the ultimate base class @baseclass as parent but is not one of the standard base classes. @baseclass is called as the ultimate base class. And its immediate child classes like Data-, Work-, Assign- etc are called as base classes.

Understand the difference between pattern and directed


inheritance
Pattern inheritance Causes a class to inherit rules from classes that match the prefix of the class name. Uses prefix segments that are followed by a hyphen. Directed inheritance is Is explicitly specified by the developer. It allows a class to inherit from a class not related to its name. A base level class always has directed inheritance from @baseclass . A class can use both types of inheritance at the same time. It can have only one pattern parent and one directed parent. Must always have a directed parent. PRPC uses an algorithm to determine inheritance Known as the Rule Resolution algorithm. For Determining Inheritance Pattern inheritance is used first, If the algorithm fails to find any rules using pattern inheritance, it starts again using directed inheritance While Creating the class, mentioning the direct inheritance is inevitable. Pattern inheritance is optional. If pattern inheritance is mentioned by checking in the check box, Pattern inheritance takes the precedence.

Rule Sets and Rule Resolution Design and create a Rule set hierarchy and its prerequisites
A Rule Set is a container that stores a related group of business rules and provides: Security Version control Ability to deploy your application in a different Process Commander environment Rule Set Hierarchy Design

Rule Set Hierarchy at runtime Searches RuleSets in the order in which they appear in users Profile list User Profile list is assembled from: Requestor Organization Division Access group

Best Practice for Ordering RuleSets Personal RuleSets first (happen automatically) Production RuleSets RuleSets that are unlocked to allow changes RuleSets in an Application rule RuleSets that are locked Pega-ProCom, Pega-IntSvcs, Pega-WB Pega-RULES (always last and happens automatically) Rule Set Hierarchy at runtime When editing a rule Not possible to guarantee what the profile of the user is Therefore, RuleSet list of requestor is not used A RuleSet list is generated from the rule being edited and its prerequisites

Tips for Rule Set Hierarchy design Limit the number of RuleSets to the minimum amount necessary Create a RuleSet only if it has a reasonable chance of holding rules Use the Initial Setup Wizard to create the organizational RuleSet Use the Application Accelerator to create the first RuleSet needed for each application A RuleSet can inherit features from other, prerequisite RuleSets and also from lower-numbered versions of itself As a best practice, update the RuleSet Version rules created by the Application Accelerator to identify Pega-ProCom:04-02 as a prerequisite to each of your application RuleSets

Understand the Connection between Classes and Rulesets


While creating a new class you need to Identify the RuleSet version number that applies to the class. The Archive tools depend on this version. The Export Archive tool includes this class instance if you export this RuleSet version or a higher-numbered version. However, version information in class rules is not used for rule resolution. You cannot define multiple class rules with the same class name but different versions.

Understand Ruleset versioning and why it is important to


application development and configuration development

Versioning at configuration management controls the exact application behavior, at development time it controls the access to the developers.

Understand how to provide users with access to Rulesets


We can add rulesets at either at Organization or at Division or at access group, but not at the unit. It is not mandatory to add the rulesets either at Organization, division and the access group. We can add at all these places, at the same time we can refrain by not adding at any of these places. Significance of adding rulesets at Organization: We can add one or more rulesets to organization for providing access to all the users belonging to that organization to the specified Ruleset. Assume an application like leave application which needs to be accessed by all the employees of organization, and then perhaps we may like to add leave applications rulesets at Organization level. Significance of adding rulesets at Division: We can add one or more rulesets to division for providing access to all the users belonging to that division. Assume an application like Loan application of a bank which needs to be accessed only by the employees of Loans division, then perhaps we may like to add Loan applications rulesets at Loan division level, so that other divisions in the same organization can not have access the Ruleset

Understand the reasons of locking rule sets

Significance of adding rulesets at Access Group: We can add one or more rulesets to access group when we think that security needs to be controlled basing on the specific job function. Assume that an application like Heart allocation request application is being developed for all the Project Managers in Virtusa for making resource requests for their projects. Then we can think of adding this application Ruleset in an access group called PM, so that all PMs across all the divisions in Virtusa can access this application.

Describe rule resolution, how it works, and how it impacts


rule set hierarchy design
Picking up right rule at right time is called as rule resolution. Process by which Process Commander decides which rule (of a series of possible rules) will be used to execute an action.

You can use the Security tab to lock the Ruleset by requiring developers to enter a password when they update the Ruleset, or add or update version instances for the Ruleset. We can avoid tampering/misuse of rules (assets) by locking the rule set when the application is shipped for production.

Dynamic selection of rule involves the following steps Business process Product Organization Ruleset and version Date Time Circumstance Security We have to design the rule set hierarchy considering the process of rule resolution. At run time it checks for the order we have configured rule sets in the access group. We have to check for where exactly a particular rule fits in the organization and accordingly we need to create multiple rule sets to modularize the application into different rule set constituents.

Availability of the rules: Availability is an important aspect of any rule for it to be considered by Rule resolution algorithm. pyRuleAvailable property represents whether a given rule is available or not ? At any point of time, this property can be set with either of the following four values YES : Indicates that this rule is available. Rules with a Yes value are visible to rule resolution processing and executed. NO : Indicates that is rule is not available and become invisible to the rule resolution algorithm for all users (including yourself). The No setting is useful in experimentation and troubleshooting to assess the effect of two rule versions. Ex : If you are setting No status for a rule of version 01-01-03, still 01-0101, 01-01-02, 01-01-04 of same rule are visible to rule resolution algorithm BLOCKED : This is a stronger form of No because it affects all lower-numbered versions of the rule and it makes all lowered numbered including this version not to be visible to rule resolution algorithm. Note : A blocked rule does not prevent rule resolution from finding (and running) higher-numbered versions Ex: If you are setting BLOCKED status for a rule of version 01-01-03, only upper versions like 01-01-04.. of same rule are available to rule resolution algorithm. Lower version like 01-01-01 and 01-01-02 are not available for rule resolution algorithm FINAL : We need to set availability to Final if we want this rule to be available (equivalent to Yes), but want to prevent others from overriding this rule in any other RuleSet. A final rule can be superceded by a higher-numbered version (in the same RuleSet), but not by any version in any different RuleSet. A rule is said to be available only when its availability is either Yes or Final

Application Deployment Create a Rule-Admin-Product instance to create a zip file of an application and its data instances
Rule-Admin-Product instance allows you to specify in great detail which rules to save RuleSets (and versions) Data instances When rules specify criteria for data instances Creates a zip file containing rule and data instances to upload into a separate system

Understand the impact of RuleSet versioning on the deployment and migration of rules
You can use these tools to copy a product or RuleSet from one Process Commander system to another. (Also called migrating or moving, this procedure doesn't alter or delete the source rules.) For example, you can move a product from a smaller development or test Process Commander system into a production Process Commander system. The source and destination systems may have different servers, operating systems, database vendors, Web server software vendors and so on. Information inside the ZIP file consists entirely of XML documents in Unicode characters. Confirm that you have a working Operator ID with a PegaRULES:SysAdm4 access role on both the source system and destination system. Confirm that the Process Commander version number of the destination system is not less than the version number of the source system. Don't attempt to move a RuleSet created in version 05-01-06 into a system based on version 04-02-01. Review the RuleSets version rules to be included. Note the prerequisite RuleSets and versions they reference. If moving more than one RuleSet, note whether and how they are interdependent. On the destination system, access the Rules by Type Explorer. Confirm that the destination system includes all the prerequisite RuleSets and versions needed. On the source system, create a Product rule or Product Patch rule if you need to include data instances or an installation activity in the ZIP archive. On the source system, examine the All Checkouts report to make sure none of the rules to be migrated is checked out. Choose the View > Rules > All Checkouts menu item to produce this report. On the source system, use Rules per RuleSet, Version, Class report (in the Rule Reports area of the Monitor Activity slice to estimate a count of rules to be included in the ZIP archive. (The reports show only up to 10,000 rules. The ZIP archive may contain more than 10,000 rules.) Export the ZIP archive. Copy the ZIP archive to the destination system. Import the ZIP archive. Adjust your access group as necessary to provide access to the uploaded RuleSets and versions. Log off, then log in with the updated access group, and review the uploaded results. If they are satisfactory, this may be a good moment to lock the imported RuleSets and versions. Consider whether a new class group and work type structure is appropriate for deployment of the application.

Able to port an application and install it to run in parallel with an existing application
Following are the common steps to port an application 1. Save all the rules 2. Make a Rule-Admin-Product 3.Use the import archive tool to import the zip file

Understand and apply the concepts of portability and parallelism

Application Rule Explain the purpose of application rule

Rule-Application is the place where we specify the RuleSet lists so that this list can be shared across multiple user configurations. This ensures the following benefits: Reduce the namespace problems Smaller and efficient caching A user can have multiple applications. Allows users to have different privileges across different applications. Previously though multiple applications are allowed, its only through the mixed ruleset lists i.e., the Rulesets required are combined as a single long list. So multiple applications coexist in the single ruleset list. The PegaRules 5.1 is so developed to adopt the application focused user configuration. RuleApplication alone remains as the center where we mention the rulesets list, which the user has access to. If the user works with a particular application, then that particular ruleset list becomes the pxThreads active ruleset list.

Understand the connection between application rules, Rule Sets and rule resolution
In the rule resolution process the engine checks for the application rules which are configured in the access group and also the order in which the rule sets are configured in Rule-Application also important.

Units of Work Define and understand the differences between the basic units of work and their associated work classes:
Work-Object

A work object is the primary unit of work completion in an application, and the primary collection of data that a flow operates on. As an application is used, work objects are created, updated, and eventually closed (resolved). Every work object has a unique ID (property pyID), an urgency value, and a status (property pyStatusWork).
A cover is a work object that is also a parent to one or a few other related work objects. Typically one work party such as the customer party is present in the cover work object and also present in all of the covered work objects associated with it. The covered work objects are the children in a parent-child relationship. Internally, a cover is a work object in a concrete class derived from the WorkCover- abstract class. A cover work object provides a means to coordinate processing of the related work objects. Normally, the system resolves a cover work object once all its "member" covered work objects are resolved. The standard ticket rule WorkCover-.AllCoveredResolved alerts a cover flow that all the member work objects have been resolved.

Work-Cover

Locking a covered work object normally also locks the cover work object. This is desirable as the cover work object may contain totals, balances, counts or other derived information that require single-threaded access. Normally, the cover work object is added to the clipboard using a page named pyCoverPage; the covered work object is on a page named pyWorkPage. The covered work objects may be of various work types. However, the work type of the cover and the work type of the covered objects must all belong to the same work pool. A folder is a work object in a concrete class that inherits from the Work-Folderclass. A folder object holds a collection of one or more other work objects (which themselves may be basic work objects, other folders, or covers) providing access for analysis and reporting. By convention, the work object ID of folders has the format F-99999. In contrast to covers: One work object may be associated with multiple folders, but only with one cover. Members of a folder can belong to various work types, which need not be all in a single work pool. The relationships between folder work objects and their contents may be manyto-many.

Work-Folder

Understand the inheritance structure of work classes


@baseClass WorkCoverFolderObject-

Understand when to inherit from work-objectversus work-coverGenerally we use Work-Object- inheritance for individual work objects, if we want to process multiple dependent work objects which are tightly coupled, covers (work-cover-) can be used. If the work objects are not tightly coupled then we can use Folders for resolution of multiple tasks.

Explain how a work object ID is defined A work object ID is the permanent, external identifier of a work

object, the value of property Work-.pyID. Prefixes and suffixes For every work object, either the prefix or suffix must be present. Normally the system assigns a permanent work object ID automatically as a work object is created. The standard utility activity named Work.GenerateID uses the standard properties pyWorkIDPrefix and pyWorkIDSuffix in its computation. For example, the prefix of work object Q-1432 is Q. The prefix of the work object MORT-763-K4 is MORT. The suffix of work object 15378-DR is DR. If you don't specify a prefix, the Work-.GenerateID activity uses W as the prefix and no suffix. The Work-Cover-.GenerateID activity uses C as the default prefix. Conventionally, the F prefix identifies folder work objects. The internal class Data-UniqueID supports work object numbering, and ensures that work object IDs are unique system-wide, not just within an application or organization.

Describe how flow execution moves between a work object and its cover during processing
When the flow belongs to class which inherits form Work-Cover- Cover related data can be seen in pyWorkPage. When the flow belongs to Covered class, Cover related information can be seen in pyWOrkCover and CoveredWork can be seen in pyWorkPage

Locate Work objects and covers on the clipboard

Wizards and Accelerators Understand the purpose and output of external setup wizard

An optional step during installation or upgrade of a Process Commander system, the External Setup wizard creates a starter kit of rules and data instances based on a single input text value. Ordinarily, the External Setup wizard is not started from within the Process Commander portal. For example, if the installer enters Alpha, the External Setup wizard creates these instances: A RuleSet named Alpha and a Version 01-01-01 An organization Alpha.com, a division AlphaDiv in the organization, and a unit AlphaUnit within the division A top-level abstract class Alpha- referenced in the Organization data instance An application rule AlphaApp A workbasket named default@Alpha.com A work group named default@Alpha.com An Operator ID named Administrator@Alpha.com, linked to the Developer portal and the application rule.

Understand what needs to be created prior to and after running the Application Accelerator in advanced mode
Pre Application Accelerator set up
Create Rule Sets Add new Rule Sets to application rule Reset your Ruleset Access Create new classes Post-Accelerator manual Entry Complete Set up of your application Create RuleSet and RuleSet versions Create classes Add new class group to work classes

Understand the purpose and output of the Application Accelerator when run in advanced mode
Streamlines the process of setting up the foundation for your application Guides you through the initial development steps when you construct a new application Allows you to build the elements of your application from the Class Group down Application Accelerator Creates A RuleSet and version for the application which is added to your access group

A simple class structure, including covers and work-related classes


A class group (work pool) and supporting database table Work object and cover prefixes Properties and models Work parties Work object forms (harness and section rules) with your application properties added One or more basic flows Workbaskets, worklists, and work groups

Application Guardrails Identify the guard rails and describe their intent
Adopt an Iterative Approach Establish a Robust Foundation Do Nothing That Is Hard Limit Custom Java Build For Change Design Intent-Driven Processes Create Easy-To-Read Flows Monitor Performance Regularly Calculate and Edit Declaratively, Not Procedurally Keep Security Object-Oriented Too

Know how to validate guardrail compliance


when building an application
The Application Preflight tool performs a number of checks on the rules in the currently selected application. These checks are designed to encourage good design and implementation practice, such as codified in the SmartBuild guardrails and elsewhere. A rule in your application may work correctly and save without errors, but still be marked with a warning (). The Application Preflight tool summarizes these warnings. For example, a decision table rule may contain two rows that conflict give a different result for the same inputs. You can save the rule and execute it within your application, because the uppermost row of the table is used at runtime, and other conflicting rules are ignored. However, the conflict may indicate that the rule was not entered correctly. You may perform the preflight check at any time during development. As a best practice, use the preflight tool before locking a version of a RuleSet, and research each warning message.