You are on page 1of 14

RuleSet, AccessGroup & Operator

- Day2

By Vishnu Jaiswal

Agenda

2
Confidential

2009 Syntel, Inc.

Organization
Organization: Organization is on top of the organization hierarchy. It is an instance of Data-AdminOrganization.
By Default PRPC is shipped with and Organization called Pega.com.
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, then we can add leave applications rulesets at Organization level.
Significance of adding top level class at Organization:
We can optionally specify a top level class when an organization is created.
It does not have much significance except it is used as default top level class when the users
belonging to the organization uses application accelerator to create an application

3
Confidential

2009 Syntel, Inc.

Division & Unit


Division: Divisions is at a second level in the organization hierarchy right after the Organization. It is
an instance of the class Data-Admin-OrgDivision
While you are creating a new division, you have to specify (Mandatory) to which organization it
belongs.
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

Unit: Unit is at a third level in the organization hierarchy right after the division. It is an instance of the
class Data-Admin-OrgUnit.
While you are creating a new unit, you have to specify (Mandatory) to which organization and division it
belongs.

4
Confidential

2009 Syntel, Inc.

Organizational Hierarchy:
Organization
At the top level, this
identifies the company
entity.

Division
At the second level, this identifies the
highest-level entities of the company.
For example, you might use the
structure of your company's senior
management team as a starting place
for division-level entities.

Unit
At the next level, this
identifies the most specific
level at which organization
information is recorded

Process Commander supports a three-level organizational hierarchy consisting of organizations at


the top level, divisions at a second level, and organization units as a third level. Each user
(Operator ID instance) is associated with an organization, division, and unit.

5
Confidential

2009 Syntel, Inc.

Basic Organizational Hierarchy Structure


Process Commander applications group organizational data hierarchically, using nested levels of
organization, division, and unit. The following structure shows a sample organizational hierarchy with one
organization, two divisions, and three units.

Example: The above Hierarchy shows an extended organizational hierarchy. The Chennai, Mumbai and
Pune divisions each have IT and Admin units; each IT unit, in turn, has HealthCare and Banking work
groups. All work group managers are afforded additional privileges by belonging to the Managers access
group.
6
Confidential

2009 Syntel, Inc.

Operator ID
An Operator ID defines a user's name, password, access group, organizational setting, calendar, and
other values.
The operator ID references an access group that contains the RuleSet versions, roles, portal layouts,
and applications available to users.
The operator ID defines what a user is capable of doing, not what the user is allowed to do. Three
instances are created automatically when Process Commander is installed:
PegaRULES Administrator Default administrator created at installation
Batch Processing Default batch requestor created at installation
External User Default user for external applications
An Operator ID data instance is sometimes called a profile. To view your Operator ID instance, click the
link containing your name in the Developer portal navigation panel.
Operator ID instances are normally stored in the PegaRULES database as rows of the pr operators
table
Operators are created through instances of Data-Admin-Operator-ID class
Important entries while creating the operators are
Organization ( Mandatory)
Division ( Mandatory )
Unit ( Mandatory )
Workgroup ( Mandatory )
Access Group ( Mandatory )
Allow Rule Check Out ( Check box ) ( Optional )
7
Confidential

2009 Syntel, Inc.

Work Groups & Access Groups


When users log in with an operator ID, their organizational affiliations grant them appropriate RuleSet
access. The ID also identifies two additional affiliations: work group and access group
Work Groups: Users and the work they do are tied to work groups, which fall below units in an
extended organizational hierarchy. Users working on a common set of items generally belong to a
single work group.
Access Groups: Users' application permissions, portal layout, and accessible work are controlled by
access groups. Access groups may span multiple work groups, and typically mirror Process
Commander job functions.
Standard Access Groups: Process Commander provides the following standard access groups
1. PegaRULES:Administrators
2. PegaRULES:Agents
3. PegaRULES:PortalUsers
4. PegaRULES:ProcessArchitects
5. PegaRULES:SystemArchitects
6. PegaRULES:Unauthenticated
7. PegaRULES:WorkManagers
8. PegaRULES:WorkUsers

8
Confidential

2009 Syntel, Inc.

Work Groups & Access Groups contd..


Working of Access Groups :
Access groups make a set of RuleSet versions
available to set of users. Multiple users are
associated with one access group.
Access group represents a persons job function
and allowed actions in a Process Commander
environment.
It controls the applications, work portal tabs,
and groups of work (or work pools) you can
access
Access groups are assigned to users through
their operator ID records, the division and
organization to which they belong, and through
requestor definitions.
Process Commander Applications use a
combination of operator ID, access group, and
access role to control what each user can see
and do within the system.
When users log in with an operator ID, their
access group determines their application portal
layout and the RuleSets they can access.

9
Confidential

2009 Syntel, Inc.

Rules, RuleSets and RuleSet Versions


Rule:
A Rule is a named business object that defines behavior of part of an application.
It is piece of business logic that encompasses practice, process and system functions
Provides both practice and process rules.
Practice rule-Business guidelines or policies.
Process rule-Procedural steps that must be followed to complete a piece of work
PEGA is a Rule Engine, everything is a Rule in PEGA. All Rules are stored in distinct business rule
database (Rule base).
For example, a when condition is a rule that defines a test that returns true or false.
RuleSet:
RuleSet stores a set of rules and related processes of a specific application.
RuleSet provides versioning and security to an application.

Rule
Rule
Rule

Rule
Rule

Rule
Rule

There are two parts in a RuleSet: RuleSet Name and RuleSet Version
Each RuleSet defines a major subset of rules in the PegaRULES database, because every instance of
every rule type references or "belongs to" a RuleSet.
10
Confidential

2009 Syntel, Inc.

RuleSet
RuleSet:
A RuleSet name is an instance of the Rule-RuleSet-Name rule type. A RuleSet name is created to
identify, store and manage a set of interrelated rules that define an application. Every rule type instance
in the PegaRULES database belongs to a RuleSet.
A RuleSet name also plays a major role in defining the access control for users in an application and
moving applications from one PRPC system to another.
Base PRPC RuleSets
Some base RuleSet names are provided with a PRPC installation.
Pega-ProCom Standard rules that support business process management (BPM) applications
Pega-IntSvcs Standard rules that support integration
Pega-WB Standard rules that support the portal infrastructure
Pega-RULES Standard rules that support business rules engine and rule resolution
The above four RuleSets form the foundation for all PRPC applications. All other RuleSets created
during application development to group interrelated rules are built on top of these RuleSets.
In addition, any application developer who can check out rules has a private RuleSet which holds the
temporarily checked out rule. The system creates each private RuleSet automatically, named to match
the developer's Operator ID value.

11
Confidential

2009 Syntel, Inc.

RuleSets Contd..
Guidelines:
Start the RuleSet name with a letter and use only letters, digits, and dashes. Choose names that are
short and easy to remember.
Don't choose a name that starts with the four letters Pega, or other variations of this text with different
case. Such RuleSets have special capabilities and are reserved for use by Pegasystems Inc.
RuleSet names may be up to 64 characters long, but normally are less than 20 characters long.
A RuleSet name must be unique system-wide

Steps to Create a new RuleSet:


Select Application > New > RuleSet from the menus to access the New dialog box.
Alternatively, choose Application > New > Rule > SysAdmin > RuleSet or use the Application Explorer
right-click menu

12
Confidential

2009 Syntel, Inc.

RuleSet Version
A RuleSet Version is an instance of the Rule-RuleSet-Version rule type.
A RuleSet Version is referenced with a special syntax consisting of the RuleSet name, colon, and three
two-digit values, known as the major, minor and the patch version, in the format RuleSetName:NN-NNNN.
A RuleSet Version is created to identify, store and manage a set of interrelated subset of rules of an
evolving application.
RuleSet Versions have a three-part numeric key. For Example: 01-02-03
Where: 01 is the major version number
02 is the minor version number
03 is the patch, revision, or change number

13
Confidential

2009 Syntel, Inc.

Thank You !

You might also like