Admin Part – Admin components

 ✪      Below are the objects (components) involved in Admin part:

Operator ID, Access Group, Application, RuleSet Name, RuleSet Version, Organization, Division & Unit

1.      Organization hierarchy:

⮚      Pega supports a three-level organizational hierarchy as: Just a logical structure

⮚      Go through the Organization features (Access Groups or Rulesets and global level Calendar)

⮚      Usually – Division or Unit may be geographical location or department. Your wish

2.      RuleSet hierarchy:

⮚      RuleSet a set of related rules in it & provides Packaging (for deployment), Versioning and access control

☞      RuleSet is like folder structure (like container) in windows

⮚      RuleSet Name contains multiple versions which in turn contains n number of related rules

⮚      RuleSet Syntax: <RuleSet name>:<Version>

●       RuleSet Name creation: Is an instance of Rule-RuleSet-Name (through Create menu or any)

Both Ruleset Name & Version together created in a single go

⮚      RuleSet version has a three-part key (syntax): NN-NN-NN (Where NN range is 01 to 99)

●       Min: 01-01-01 & Max: 99-99-99

●       NN (Major): major changes or new releases

NN (Minor): enhancements or medium-size changes

NN (Patch / Release): bug fixes or very minor changes

⮚      RuleSet version creation:

☞      Ruleset Name (Ruleset rule) > Versions tab > Add a row

☞      Skimming tool: To major & minor versions creation with rules as well

⮚      Pega recommends 2 Rulesets at each level as:

1)      Organization: Enterprise level & Int level RS

2)      Division: Division level & Int level RS

3)      Unit: Unit level & Int level RS

4)      Application: Application level & Int level

⮚      We can find its rules by the links here: Checked Out / Rule Count / All Rules / Rules currently checked out

⮚      RuleSet Prerequisite:

Used for rule validation and reusability (i.e. reusing the existing rules)

⮚      Some of RuleSet types:

1)      Branch rule sets: To manage parallel developments by teams working on large development projects. It has only one version

Go for branches for large developments where number of teams to work parallel – otherwise Checkout feature is ok to manage small developments

2)      Personal (Private) rule set: To unit test the private (check-out) changes

3)      Associated rule set: Is the RuleSet participated in deployment (migration)

4)      Standard rule set: Is the RuleSet participated in execution of rule instances

5)      Production rule set: Is the RuleSet participated in delegation of rule instances

6)      Unauthorized rule set: Is the RuleSet defined in AG of for Guest user

⮚      Apply Refactor to delete the Rule Sets: DS > System > Refactor > Rule Sets

⮚      RuleSet vs. Class: Class doesn’t contain rules rather determines how the rules contain within RuleSet or applied

3.      Application (Rule-Application):

Application, in general, is a s/w program used by end-users to make a transaction that has UI & logics on it. Ex: Loan processing, Leave request application, Raising purchase order … But coming to Rule-Application, it contains n number of concrete applications discussed above

⮚      Wrapper of related Rule Sets which are organized as stack in it (called Standard rule sets), an instance of Rule-Application

⮚      Application structure can either be framework or implementation

⮚      Each Application has versions (zz.zz.zz – major & minor, patch is optional) that are used to manage the subsequent releases

⮚      Any Application must directly or indirectly be built on PegaRULES (default)

⮚      Any Application (FW or Implementation) are connected to Pega platform through Directed inheritance

⮚      Application is also associated with version [Syntax: zz.zz.zz or zz.zz], not like RS version

⮚      Framework: Built on applications are said to be Framework applications which are of types Standard (by Pega) or Custom (by Client)

Ex for Standard (by Pega): CPM, Smart Investigate, Smart Dispute…

●       What is Framework:

Framework applications are generalized reusable tailor made applications that contains common functionalities re-used across Implementation applications

●       What are the standard Frameworks [Ex: CPM, Smart Dispute, Smart Investigate]

●       Note:

Type of ‘Built on’ Application (i.e. predefined FW) when using App Express wizard

1)      Classic: UI-kit

2)      Cosmos: Theme-Cosmos [written in React JS for better UI experience (UX & UI)]

☞      React JS is an open-source JavaScript library (Facebook, Twitter, Netflix, Uber …)

●       What is Framework Application: Built on Applications

🡪    Reusable work-related business rules are defined here like Case types / Flows / Flow actions / Sections

🡪    We reuse these FW rules in Implementation Classes

Ex: Call ‘FW Flow’ into Implementation class by using ‘Sub Flow’

⮚      Operator can have n number of Applications through corresponding Access Groups

⮚      Application creation: Either by App Express wizard (DCO) or by Manual approach

⮚      Skin rule is used for presentation of this Application

⮚      Referred at: Access Group, other Application rule (as Built on)

⮚      Mashup (web application hybrid - IAC) gadget:

●       Mashup is a way (technique) to generate code to interact with cases from external applications

●       The Pega Web Mashup, previously known as the Internet Application Composer (IAC), enables you to embed a Pega Platform application as a gadget on the pages of a Pega composite application

⮚      Path to create Application:

Create menu > Application Definition category > Application

4.      Access Group (Data-Admin-Operator-AccessGroup):

⮚      Definition:

Is the main security rule of type Data-Admin-Operator-AccessGroup used to provide group of access related information to specific group of users

●       Access related information like Application rule, Access Role, Work pool, Portal and Authentication Time Out (AT)

⮚      Relation of ‘Application to Access Group’: Many to One relation

🡪    Relation of ‘Access Group to Application’: One to One relation

⮚      Any requestor connects to Pega is identified only through Access Group (very important, don’t forget). So AG is provided not only to Operator ID but many places like Agents, Services… to locate the rules to execute

⮚      Path to create Access Group: Create menu > Security category > Access Group

5.      Operator ID (Data-Admin-Operator-ID):

⮚      Operator is the user who signs into PRPC, an instance of Data-Admin-Operator-ID that stores in pr_operators table as a record and identified by its class key pyUserIdentifier (OOTB Property)

⮚      Its pzInsKey: Data-Admin-Operator-ID  pyUserIdentifier

⮚      Each Operator can have n number of Applications & Portals which are provided (indirectly) through Access Group, not directly

⮚      Operators are mainly categorized into TWO:

Developers (To build & develop application) & Case Managers (To use it)

⮚      Operators created in App Express wizard are as below:

Admin, Manager, User & Author (Business Analyst or Business Architect or Process Architect)

Details of Operators box:

Developer (or Admin or SA or Application Architects)	Manager (Case Manager)	Basic User (Case Worker)
☞      Has full control (freedom)	Has Little freedom	Has full restrictions
☞      PegaRULES:SysAdm4 role	PegaRULES:WorkMgr4 role	PegaRULES:User4 role
☞      Developer (or DS) portal	Case Manager7 portal	pyCaseWorker portal

 

⮚      Operator’s features:

Profile / Personal Info / Organization / Access Group / Application / Access Role / Work Group / Workbasket / Calendar / Time Zone / Authentications [Basic (default) or Custom (Ex: LDAP / SAML …)] …

☞      Path to create Operator ID: Create menu > Organization category > Operator ID

⮚      Work Group:

It is a group of work lists and workbaskets together, that report to the manager identified by it & is created as an instance of Data-Admin-Work Group

☞      Path to create Work Group: Create menu > Organization category > Work Group

Note:

Work List is a list of assignments for a specific user, ordered by decreasing Urgency. Don’t forget it is not a rule but just an element, which is automatically associated with Operator ID creation itself

⮚      Workbasket:

Workbasket (Work Queue) is a list of assignments for a group of users, ordered by decreasing Urgency & an instance of Data-Admin-Workbasket

☞      Also called ‘Work queue’ - A centralized, shared pool of assignments

☞      Path to create Workbasket: Create menu > Organization category > Workbasket

⮚      Create Work Group & Workbasket instances interrelated & provide Work Group to Operator ID

Requestor Type

(Data-Admin-Requestor)

⮚      Whoever (user or system) is active on the Server is generally considered as a Requestor where as Operator is who logs on to the PRPC through Browser

⮚      Each Requestor is identified with random numbers through SMA where as Operator is identified with pyUserIdentifier

⮚      Each Requestor or Operator is recognized by Access Group

⮚      Each runs on its own Thread

⮚      Requestor types (instances of Data-Admin-Requestor)

1)      Pega APP (A) – handles external applications requests

2)      Pega BROWSER (H) – handles browser requests

3)      Pega PORTAL (P) – handles portal requests

4)      Pega BATCH (B) – handles scheduling jobs

5)      ASYNCPROCESSOR – also handles scheduling jobs (Job Scheduler & Queue Processor rules) start with B – similar to BATCH requestors