Understanding of class group

A class group is an instance of the Data-Admin-DB-ClassGroup class and corresponds to tables

in the Pega RULES database. Class groups cause the system to store instances corresponding to
two or more concrete classes that share a common key format in a single database table, which
is known as a work pool.

• The Work class contains the rules that describe how to process a case or cases, such as
processes, data elements, and user interfaces.
• The Integration class contains the rules that describe how the application interacts with other
systems, such as the integration assets that connect the application to a customer database or a
third-party web server.
• The Data class contains the rules that describe the data objects used in the application, such as
a customer data type or order items data type.

On creation of application, by default classes will be created.

“TATA-CreditCard-work” Implementation class group.

“TATA-FW-HDFCBank-Work” FW class group.

external class

An external class is a concrete class (instance of the Rule-Obj-Class rule type) that corresponds
to a table in an external relational database, rather than to a table or view in the Pega RULES
database.

internal class

An internal class is a concrete class (instance of the Rule-Obj-Class rule type) for which
instances are stored in the Pega RULES database, rather than in an external database. The
properties @baseclass.pzInsKey and @baseclass.pxObjClass are defined for every internal class.

Pega RULES database

The Pega RULES database is a relational database that holds the rules, data instances, work
items, history, and other concrete objects from the internal classes of the Pega
Platform system. External classes are not part of the Pega RULES database.

2 Types of classes we have in PEGA

1. Abstract
2. concrete
Abstract: :-

• An abstract class is a rule (an instance of the Rule-Obj-Class class) created to support
the definition of rules, including other classes.
• Rules with a class as a key part (such as properties, activities, flows, data transforms,
etc.) can apply to an abstract class.
• Unlike concrete classes, abstract classes cannot be instantiated (i.e., they do not create
objects to be stored in the database).

When to Create an Abstract Class:

• Reusable Rules: Abstract classes are useful for creating reusable rules that apply to multiple
subclasses.
• Common Behavior: If you want to define common behavior or properties that should be
inherited by multiple subclasses, consider creating an abstract class.

• Inheritance: Abstract classes can be inherited by subclasses, allowing you to establish a

hierarchy of related classes.

Example: Abstract class

• Suppose you have a set of classes representing different types of vehicles (e.g., Car, Truck,
Motorcycle).
• You can create an abstract class called Vehicle with common properties
(e.g., Make, Model, Year) that apply to all vehicle types.
• Subclasses (e.g., Car, Truck, Motorcycle) can inherit from the Vehicle abstract class and add
specific properties or behavior.

Remember: Remember that abstract classes provide a way to structure your class hierarchy and
promote code reusability. They are particularly useful when you want to define shared characteristics or
enforce a common interface across related classes.

Concrete: -
In Pega, concrete classes play a crucial role in defining and managing data. Let’s explore why they are
essential and when to create them:

• A concrete class is a rule (an instance of the Rule-Obj-Class class) that can be instantiated,
meaning it allows creating objects (instances) that can be stored in the database.
• Unlike abstract classes, concrete classes have instances with actual data.
Why Do We Need Concrete Classes?

• Data Persistence: Concrete classes are used to store data in the Pega database. When you need
to capture and persist information (such as case data, customer details, or transaction records),
you create concrete classes.
• Work Objects: Concrete classes are the foundation for creating work objects (cases). Work
objects represent specific instances of a business process or workflow. For example, a “Loan
Application” case or a “Customer Service Request” case.
• Historical Data: Concrete classes allow you to maintain historical data. When a case is resolved
or updated, the historical information is stored in the database, enabling auditing, reporting,
and analysis.
• Integration and Reporting: Concrete classes facilitate integration with external systems. Data
can be exchanged between Pega and other applications using concrete classes.
• Security and Access Control: Concrete classes define access control and security settings. You
can restrict who can create, read, update, or delete instances of a specific class.

When to Create a Concrete Class:

• Business Entities: Create concrete classes for business entities such as customers, accounts,
products, orders, etc.
• Case Types: When designing a case type (e.g., a loan application process, customer
onboarding), create a concrete class to represent that case type.
• Reusable Data Structures: If you have common data structures that need to be reused across
different parts of your application, create concrete classes for them.
• Reporting and Analytics: When you want to analyze data or generate reports, concrete
classes provide the necessary data points.

Example:

• Suppose you’re building a banking application. You might create the following concrete classes:
o Customer: To store customer details (name, address, contact information).
o Account: To represent bank accounts (savings, checking, etc.).
o LoanApplication: To track loan applications submitted by customers.
Remember:

Remember that concrete classes are the backbone of your data model in Pega. They allow you to
manage and manipulate real-world data within your application.

………………………………………………………………………………………………………………………………………………………………..

Data Base table mapping with class:

In Pega, class-to-database mapping is essential for connecting your application’s data model to the
underlying database. Let’s explore how this works:

Class Mapping to Database Tables:

• Any Pega class that has instances (such as case types, data types, or custom classes) can be
mapped to a database table.
• When users create cases or store data, Pega assigns a unique ID to each instance and saves it as
an individual row in a database table.

• Reports retrieve data from these rows in database tables, using class mappings to locate the
relevant information.

Records Used for Mapping:

Pega uses two records to identify the database table a class is mapped to:

Database Record: This record defines how Pega connects to a specific database. It contains
connection information (such as JDBC or JNDI details) to access the database. Each database record
establishes an alias that can be referenced elsewhere.

By default, Pega uses the following standard databases:

 • PegaRULES: Stores Pega rules and system data.
• PegaDATA: Stores data and work instances (such as cases).

Database Table Record: This record identifies a specific table in a specific database and specifies the
corresponding Pega class. It tells Pega which table to write case data when users create or update cases.

Example:

• Suppose you have a custom class called MyApp-Work-CustomerCase representing

customer cases.
• You would create a database table (e.g., CUSTOMER_CASES) in your database.

• The Database Table record for MyApp-Work-CustomerCase would specify the table name
(CUSTOMER_CASES) and link it to the class.

Mapping Multiple Classes to a Single Table:

• Sometimes, multiple classes share the same table (e.g., work items, assignments, etc.).

• Pega ensures that data from different classes is correctly stored and retrieved from the same
table.

Remember:
Remember that class-to-database mapping is crucial for data persistence, reporting, and
efficient data retrieval in Pega applications. It bridges the gap between your application’s logical
structure (classes) and the physical storage (database tables).
What is PR4_, PR_, PC_ tables in pega
By clicking on Test Connection from the Class definition, we can check the backend table name which is
mapped to the respective class.

There are tables in PEGA, which are divided in to 3 types (pr4, pr, pc)

a) Table name Start with pr4_ : All core rules of pega (including Properties, Sections, Flow actions,
flows, activity, data transforms etc) are stored in tables with pr4_ as prefix.

b) Table name Start with pr_: These tables are generally cache tables [Data pages] data types, data
rules tables, Data classes, queues etc.

c) Table name Start pc_: These are the worktables & work history tables, attachments, links etc…