PRPC Platform Fundamentals

WorkPool in PEGA is a logical grouping mechanism that collects similar Work Objects together based on shared characteristics or criteria. This organization helps in managing and tracking related work items efficiently. WorkGroups and ClassGroups are different organizational structures in PEGA.

PEGA PRPC defines multiple standard roles including Process Architect, System Architect, and System Administrator, each with distinct responsibilities. Process Architects design solutions, System Architects handle technical implementation, and System Administrators manage deployment and infrastructure. All these roles are fundamental to the PEGA development lifecycle.

The System Architect role in PEGA primarily works with Properties and data modeling, defining the data structure and property definitions for applications. While flows and harnesses are important, they are typically owned by Process Architects or Developers. Correspondence rules are template-based and not the primary focus of System Architects.

In PEGA, pz properties are system-protected read-only properties that cannot be modified by users or developers, ensuring system integrity. px and py properties can be modified under appropriate circumstances. The pz prefix specifically denotes protected system properties.

Ordinary work objects in PEGA inherit from the Work-Object- base class, which provides standard work object functionality. Covered work objects inherit from Work-Cover- class, not Cover-Object-. Folders can contain multiple covered objects, and folders themselves are organizational structures, not work objects.

The Property-Set method is the standard and recommended way to update property values in PEGA activity steps, providing proper framework integration. Java methods break abstraction, AtSetValue is not a standard PEGA method, and {PropertyName INPUT} is a reference syntax not a method for setting values.

Rule-RuleSet-Version is the only rule type among the options that can be locked and unlocked to control changes to specific rule set versions. This prevents unauthorized modifications while maintaining version control. RuleSet names, lists, and ProCom rules have different versioning mechanisms.

Rule-Obj-SummaryView is specifically designed to display aggregated counts and summaries of work objects by status or other criteria. ListView displays detailed lists, not counts. Count and GroupBy rules serve different purposes - SummaryView is the appropriate choice for status count displays.

The pxRequestor page contains information about the current user and their context. pxUserIdentifier is the property that stores the user's identifier on this page. pxFlowInsKey is typically found on pyWorkPage, pxAssignmentKey on assignment pages, and pyID is a generic ID property not specific to pxRequestor.

The New selection list in Process Work gadget displays flows that have the 'Creates a New Work Object' setting enabled. To add a new work type to this list, you create a new flow and check the 'Creates a New Work Object' option. Creating a work class alone does not add it to the New selection list without an associated flow.

In Pega, declarative expressions (Rule-Declare-Expressions) are used to automatically calculate the value of a property (like pxUrgencyWork) based on a formula and other property values. The other rule types serve different purposes like decision logic, database triggers, or tracking changes.

Data-Admin-Operator-ID is the class that stores operator information including Full Names and User Identifiers. Rule-Obj-Operator is not a valid class name in Pega. Rule-Obj-ListView and Rule-Access-Role-Name are different rule types unrelated to operator data storage.

pyWorkCover is the standard page name in Pega that contains the covering work object (also called the cover object). This page holds the parent work object when there are multiple covered work objects under one cover. pyWorkPage, pyObjectCover, and pyObjectWork are not valid page names in Pega's standard naming convention.

Edit Input rules (Rule-Edit-Input) are used to convert or transform user input data into a standard format before it's processed. They can perform conversions like changing case, formatting values, or transforming data types. They are not used for testing values (that's Validate rules), database operations, or defining comparison relationships (that's Declare Expressions).

When creating a class in Pega, Direct Inheritance is mandatory - every class must have a parent class specified through direct inheritance. Pattern Inheritance is optional and provides an additional inheritance mechanism based on naming patterns. A class cannot exist without specifying its direct parent.

Services in Pega allow external systems to access PRPC application data and processes by exposing functionality through standard protocols. Connectors are used when PRPC needs to call external systems (the opposite direction). 'Servers' is not a valid Pega integration term in this context.

Correspondence types in Pega are stored as Rule-Obj-Corr rule type. This rule type defines the template and configuration for correspondence such as emails, letters, or faxes. Rule-CorrType, Rule-Obj-CorrType, and Rule-Corr are not valid Pega rule type names.

The status of a work object in Pega is stored in the pyStatusWork property. This property tracks the current status such as New, Open, Resolved, or Closed. pyTaskStatus, pyWorkStatus, and pyWorkObjectStatus are not valid property names for work object status.

Work Objects are created during Starter Flows, which are specifically designed to create new work objects. Starter flows have the 'Creates a New Work Object' setting enabled. Primary flows, Secondary flows, and Sub flows are not responsible for creating work objects - they process existing work.

Pega-ProCom is the mandatory prerequisite ruleset for all initial application rulesets. It provides foundational process commander functionality required by Pega applications. PegaApp and Pega-Rules are not the correct prerequisites for initial application rulesets.