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 Tier
Data Tier
Web Browser
Java EE Platform
Database Server
Example
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
Data Tier
Business Tier
EJB
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
Business Tier
Data Tier
EJB
Servlets
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



Web Tier
JSP 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
Business Tier
Data Tier
JDBC SQL
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


XML
Users
Work
Work Database
XML
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





XML
System Architects
XML Rules
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
For example, all divisions across BIG have some type of Policy Administration
Organization Assets common across multiple divisions or applications
For example, LDAP integration
Understand the difference between one Off
application and a reusable application
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






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.
Understand the reasons of locking rule sets
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.
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.







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-01-
01, 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. Rule-
Application 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).
Work-Cover-
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 Work-
Cover- 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 Work-
Cover-.AllCoveredResolved alerts a cover flow that all the member work objects
have been resolved.



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.
Work-Folder-
A folder is a work object in a concrete class that inherits from the Work-Folder-
class. 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 many-
to-many.



Understand the inheritance structure of work
classes
@baseClass
Work-
Cover-
Folder-
Object-

Understand when to inherit from work-object-
versus work-cover-

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