What is the difference between Workgroup and Access Group?
A work the group is an instance of the Data-Admin-WorkGroup class. A working group can identify a user who is a supervisor, together with a set of workers and workbaskets that report to that supervisor.
Access to the group is an instance of the Data-Admin-Operator-AccessGroup class. Access
groups make a set of RuleSet versions available to requestors.
Developers
define access groups and associate an access group with each user (each
Data-Admin-Operator-ID instance). Typically, multiple users are associated with
or belong to one access group.
The
access-group associated with a user affects access control by determining:
·
The portal layout that a
user sees first after logging in.
·
The local customization
RuleSet name and RuleSet version. These usually are defaulted whenever the user creates a new rule instance.
·
The application rule for
this user.
·
Optionally, the access
roles available to this user.
How to associate an Operator with a workbasket?
In a workgroup, we can associate an operator with a manager and
a workbasket.
What are the access
roles and how they work at run time? Can we create our own Access Roles?
If yes, explain with an example.
An access role is an instance of the
Rule-Access-Role-Name class.
Use an access role name to convey permissions (capabilities) to
a user or a group of users. Access roles can be referenced in requestor
instances, Operator ID instances, in access group instances, in activities, and
in queries.
At login, the system assembles a set of roles for a user base
on the information in a user’s requestor instance, Operator ID instance, and the
associated access-group instance.
Access roles influence which classes a user can view, update, and
delete, and so on through the Access of Role to Object and Access Deny rule
types.
Example. Create an instance of Rule-Access-Role-Name. To grant
access to a user for a particular class creates an instance of Rule-Access-Role-Obj.
For each of the eight categories in the array, you can enter an
Access When rule name or a numeric value between 1 and 5.
If at runtime, the production level of your Process Commander the system is not greater than the numeric value, then users with the specified
access role can perform the operation (on objects of that class). If an Access
When the rule evaluates to true at runtime, the users with the specified access
role can perform the operation.
The production level is set in Data-Admin-System.
What
is a portal and how can it be customized for different users?
The Process Commander portals support two user
communities:
·
The Developer portal
provides an integrated work, test, and development environment to support
application developers. Customization of the Developer portal is typically not
necessary and ordinarily limited to menus and skins.
·
User portals support
managers and users of applications workers, as they enter, update, and resolve
work objects. User portals may be customized to reflect the terminology,
layout, facilities, and styles appropriate to each user community.
This Developer portal provides quick access to dozens of tools,
wizards, reports, and other capabilities.
The appearance and function of our Process Commander portal
depends on the information in our access group which references a portal rule
(Rule-Portal rule type)
We can create our own portals and define new gadgets (instances
of Data-Gadget).
Data-Gadget contains simple HTML rules. We can change the Pega
Logo as well.
Define access group
and its functionality?
Access Group controls the security basing on the job functions.
It is an instance of Data-Admin-Operator-AccessGroup.
Various aspects that can be controlled through access group are
- default and available types of
works( also called work pools ),
- Primary rulesets ( Access Control
to rulesets),
- Assigned roles,
- Portal layout
- Default ruleset for making changes
( Default ruleset whenever the user creates/ saves as the rule )
What
is the order in which the Rule setlist is constructed?
Requestor, Organization, Division, Access Group is the order in which this list is constructed.
In the access group, the Application rule setlist is at the bottom and The production Ruleset is on top of it. It follows Top-down approach.
What
is RuleSet?
A RuleSet name is an instance of the
Rule-RuleSet-Name rule type. 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. A RuleSet name is a major aspect in:
·
Access control
·
Grouping interrelated
rules
·
Managing the rules
·
Moving applications —
sets of rules — from one Process Commander system to another.
Process Commander itself consists of six standard RuleSets:
·
Pega-AppDefinition —
Standard rules supporting Direct Capture of Objectives features
·
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
·
CheckInCandidates —
Optional. Empty, used by rule check-in processing. Version 01-01-01 is not
locked.
Any application developer who can check out rules has a
private RuleSet.
The system creates each private ruleset automatically named to
match the developer’s operator ID value.
We create one ruleset per application.
The rule set names are part of the SysAdmin category.
What is ruleset
versioning? Explain Major, minor, and patch?
A RuleSet version is an instance of the
Rule-RuleSet-Version rule type. The version number in the form AA-AA-AA,
defines six digits in three groups that characterize the evolution and
development of a rule instance, and of the application it belongs to. The
three segments are known as
the major version, minor version,
and patch version.
For eg. LoanAdmin:01-02-03
Here, 01: major version
02: minor version
03: patch version
Major: for entirely new functionalities or major releases,
the first two digits of the version is incremented.
Minor: for enhancements, the middle two digits are
incremented.
Patch: for bug fixes, the last two digits are incremented.
Rule resolution algorithm uses version numbers to find the
most appropriate single rule instances to execute in a specific situation.
Few rules are non-versioned
Application, class, RuleSet. Ruleset version, Access deny,
Library.
Explain
about RuleSet types and the priority given in Rule Resolution?
Application RuleSet is a RuleSet that appears in any
of the following form fields:
·
On
the General tab of the application rule referenced in the access
group for a requestor (when the current work pool is part of this application)
·
(Recursively) On the
General tab of a ‘parent’ application rule, if they Include Parent check box on
the General tab of a ‘child’ application is checked.
·
In the Local
Customization field on the Settings tab of the access group
Production RuleSet is a RuleSet that has
the Type field set to Standard (on the Category tab of the RuleSet
form) and that typically has at least one open (not secured) RuleSet Version.
Production RuleSets are listed on the General tab of an
application rule and on the Layout tab of the Access Group form
The application RuleSet does not include rules in RuleSets
listed in the Production RuleSets array of the Access tab.
During rule the resolution, the system:
· The first priority is given to
Production Rulesets. First, search the rules in Rulesets available in
Production RuleSet.
·
Next Searches the rules
in the Rulesets listed in application Rulesets. First using the topmost RuleSet
name and version on the list, then the next, and so on. Override RuleSet
versions (the top layer are searched first; the Pega-RULES RuleSet is searched
last)
·
Ignores any rule
instances that match a RuleSet on the list but contain versions higher than the
version on the list.
Good job keep it up 🥰👍🏻
ReplyDelete