Pega Preparation notes according to the concepts:

1) Single Value:
The simplest property mode is Single
Value. A Single Value property contains text that can
represent HTML, a date or time, an identifier, a number,
or a Boolean true/false value. On the clipboard,
a Single Value mode corresponds to a Java String
object. Properties with this mode can directly
correspond to columns in the Pega RULES database.
Properties with a mode other than Single Value are
known as aggregate properties.

2) Page:
A page is a data structure that holds name-value
pairs. A page may be contained in memory, or can be stored
in the system database. The system has many types of pages
— named pages, unnamed pages, embedded pages,
parameter pages, and so on.

3) Page List:
A Page List mode property is a data structure
consisting of an ordered list of zero or more pages,
each identified by an integer index (starting with 1).
4) Page group :
Page group properties contain unordered groups of
embedded pages. For example, you can create a page group
that stores information about work parties, and each
embedded page stores information about one work party,
such as a customer or a worker.

5) Value List :
One of eleven property modes, a Value
List property is a single property that has as values an
ordered list of text values. The system does not limit
the number of entries in a list.

6) Value Group:
One of eleven property modes, a Value
Group property is a single property that has as values
an unordered set of values of any Type. The system
does not limit the number of entries in a group.

7) Operator ID :
An Operator ID data instance provides a user
identifier (ID), a password, and other facts
and preferences. This data instance also locates a user
with in an organization structure, and identifies
appropriate access roles and other characteristics.
8) Data page:
A data page manages the integration to the data
source, separating business processes from any integration
details. This separation allows application developers to use
sourced data in an application without knowing the data
source and connection details.

9) Access Group:
An access group identifies the access roles granted to
members of the group. As you extend the access control
model for your application, you add new roles to an access
group. Adding a role to an access group grants the access
control and privileges for the role to the user.

10) Case Type:

A case type is an abstract model of a business
transaction. Case types model repeatable business
transactions. A case is a specific transaction instance. To
model the online order transaction in Pega Platform, you
define an online order case type that advances from
submission to processing and then delivery
 11) Property :

A property provides a name and characteristics for

data in an object. Because a property definition is a rule, it
shares the benefits of versioning, inheritance, and access
control that the Pega Platform provides to all rules.

The following tabs are available on this form:

 General
 Advanced

12) Flow :
A flow defines a business process or part of a
business process. A flow governs how work items are created,
progress through your application, and become resolved
(completed). A flow consists of a network of shapes and
connectors (lines), each with associated parameters and
values.
Types :
12.1) Screen flow :

Screen flows are designed for a single user

completing a multi-step process. Steps are shown to the
right of the content (tree navigation) or above the content
(tabbed screen flow).

Use a “tree” screen flow when there are more

than five steps, or steps are dynamic based on content, or
some steps have sub steps.
 12.2) Process Flow :

In a Pega Platform application, a Process

Flow is a sequence of events that models a Process in the
Case Life Cycle. Whereas the Process in the Case Life Cycle
designer depicts the sequence of events a Steps, the Process
Flow uses graphical shapes and connectors to define the
sequence of events

13) Flow Action :

A flow action is a choice available to users as an
interim or final disposition of an assignment they process. Each
flow action is defined by an instance of the Rule-Obj-Flow
Action rule type.
Flow actions are of two types:
13.1) Connector flow actions appear as lines on Visio
presentation in the Diagram tab of a flow rule. A line
exits from an assignment shape and ends at the next
shape in the flow. At runtime, users choose a connector
flow action, complete the assignment, and advance the
work object along the connector to the next shape.
13.2) A local flow action, when selected at runtime,
causes the assignment to remain open and on the current
user's worklist. Local flow actions are recorded in the
Assignment Properties panel and are not visible on the
flow diagram.
13.2.1) Case level :
This flow action it is in the case level
13.2.2) Assignment level :
This flow action it is in the assignment level
13.2.3) Stage level :
This flow action it is in the stage level
14) Class :
Class contains the rule by which objects behave.
Define rules such as properties, activities, flows, HTML forms,
etc. available to other subordinate classes. Classes are
organized into a hierarchy in which lower classes inherit from
upper classes. A class is an instance of a rule-obj-class rule.

15) Section:
A section is a portion or area of a standard user
form that is incorporated on a harness form. Sections may
contain other sections, informally called subsections.
The appearance, behavior, and contents of a section
are defined by a section rule (Rule-HTML-Section rule type).

16) Harness :
A harness organizes the structure of a portion
of the user display. In Pega, you use a harness to organize
either a work form or a portal.

Pega applications commonly use four standard

harnesses to organize the content of user forms.

Types of harness they are the

16.1) New Harness:

It is a dammy harness
16.2) Conform Harness:

Conform or successful message will get

16.3) Perform Harness:

Give Data and submit

16.4) Review Harness:

Not editable means review harness

17) Portal :
A portal is a web channel in use by your application. End
users experience the portal through a browser, regardless of
device type (such as a desktop or mobile device). A portal
allows simple and intuitive authoring of an application web
channel.

18) Paragraph :
A paragraph is a rule of the Rule-HTML-
Paragraph rule type. A paragraph rule, referenced on a
user form, presents formatted text that can include
colors, fonts, styles, and images.
Paragraphs can provide extensive and attractively
formatted instructions
 19) Rule Availability :
The availability setting determines if a rule is available for use during
rule resolution. The availability of a rule also determines if you can
view, copy, or edit a rule in Dev Studio.

You can set the availability of a rule to one of five values types.
Branch Version:

19.1) Availability = Available

An availability of Available indicates the rule may be used during the

rule resolution process.

Tip: When you create a rule, the default availability of

the rule is Available.
You can view, copy, edit, and execute rules in Dev Studio when the
availability is set to Available.

19.2) Availability = Final

An availability of Final indicates the rule may be used during the rule
resolution process.

Rules marked as Final can be viewed and executed in Dev Studio, but
cannot be edited or copied into another ruleset.

Note: The Final setting is used by Pega Platform™ to

indicate that Pega-provided rules might change in
subsequent releases.

19.3) Availability = Not Available

An availability of Not Available indicates the rule may not be used
during the rule resolution process. When a rule set to Not Available is
found in the rule cache created during the rule resolution process, the
rule in the next-highest version is considered for rule resolution. The
following table represents an ordered rule cache. The availability of
the rule named Create Request in the Purchasing:02-01-10 ruleset is
set to Not Available. The rule in the next-highest version
— Purchasing:02-01-05 — is considered for rule resolution.

You may choose to set the availability of a rule to Not

Available during initial development. Doing so allows you to save a
rule without validation. Rules marked as Not Available can be
viewed, copied, or edited in Dev Studio, but do not execute.

In the center of the following image, drag the vertical line to see the
skipped rule candidate. The selected rule is in bold in the image on
the right.

19.4) Availability = Blocked

An availability of Blocked indicates the rule may be used during the

rule resolution process. Rules marked as Blocked can be viewed,
copied, or edited in Dev Studio, but do not execute. If a blocked rule
is selected during rule resolution, execution is halted, and an error
message is added to the log file.

In the following table, the availability of the highest version of the

rule named Create Request in the Purchasing:02-01-10 ruleset
is Blocked. This version of the rule is available during rule resolution
but does not execute. There are no higher versions of the rule
available, so in the case of the example section rule, the section does
not display.

Block a rule when access to the rule must not be used and you need
more time to develop and release an updated rule.
In the center of the following image, drag the vertical line to see that
the process does not skip any rule candidate. The selected rule is in
bold in the image on the right.

19.5) Availability = Withdrawn

An availability of Withdrawn indicates all rules that are in the

current version ruleset and previous version ruleset and have the same
purpose (or rule type) and Apply to: class are hidden and no longer
considered after Availability is checked during the rule resolution
process.

When a rule marked as Withdrawn is found during rule resolution,

the system looks for an instance of the rule in the parent class or next
highest ruleset in the application ruleset stack.

In the following table, the availability of the rule named Create

Request in the Purchasing:02-01-10 ruleset is Withdrawn. All rules
that are in the same ruleset with an equal or lower version number and
have the same purpose and Apply To class are not considered during
rule resolution. The rule named Create Request in the Purchasing:02-
01-15 is considered during rule resolution because the ruleset version
is higher than the ruleset version of the withdrawn rule. If the rule
in Purchasing:02-01-15 did not exist, a rule in the parent class, TGB-
Purchasing-Work, would be chosen.

Rules marked as Withdrawn can be viewed, copied, or edited in Dev

Studio, but do not execute.

In the center of the following image, drag the vertical line to see the
skipped rule candidate. The selected rule is in bold in the image on
the right.
 20) Rule Resolution :
Rule Resolution is the process Pega uses to determine the most
appropriate rule to execute.

When a rule is referenced in a Pega application, rule resolution

attempts to locate instances of the rule in the rules cache

The rule resolution process

The steps in the rule resolution process are as follows:

Step 1: Check the Rules Cache.

Using rules already in the rules cache avoids additional database lookups.

If the rule is there, go to Step 8. If not, continue to Step 2.

Step 2: Choose instances with the correct purpose.

The purpose, or "family name" combines all the key properties of a rule, excluding
the "defined on" class.

For an activity rule, the key properties include:

  the Applies To class that the activity is defined on

 the activity name

The purpose in this case is the activity name.

For a Field Value, the key properties include:

 the Applies To class, as above

 the Field Name

 the Field Value

The purpose in this case is the Field Name plus the Field Value, for example
"pyActionPrompt.ViewHistory".

The system chooses all items of the appropriate purpose and puts them in a
temporary list.

Step 3: Discard rules where Availability = No.

The system drops unavailable rules from the temporary list.

Step 4: Discard inapplicable rulesets and versions.

The system drops from the list rules that belong to rulesets and versions that are
not enabled for the current requestor. For instance, if the user's profile includes the
ruleset version ThisRuleSet: 05-01, rules belonging to ThisRuleSet: 04- or
ThisRuleSet: 06- are dropped.

Step 5: Discard all candidates not defined in a class in the 'ancestor tree'.

Only rules found in classes from which the current class descends by either pattern
or direct inheritance will be retained in the list.

Note: This step is not used for rules which do not have the Use class-based
inheritance to arrive at the correct rule to execute check box selected in their
class definition.

Step 6: Rank remaining candidates.

The system ranks the remaining rules on the list in order of

 Class
  Ruleset

 Circumstance

 Circumstance Date

 Date/Time Range

 Version

Note that:

 The ruleset and version rankings are based on the ordered list in the user's
profile.

 A rule with a specific qualifier ranks higher than one with no qualifier.

 Circumstanced rules rank alphabetically by Circumstance value.

 Circumstance Dates rank in descending value.

 Date/Time ranges rank first by their end-date (in ascending order) and
then by their start-date (in descending order).

 Rules which do not have the Use class-based inheritance to arrive at

the correct rule to execute check box selected in their class definition
are not ranked by class.

Step 6a: Discard choices that occur after the first "default" rule

A default rule (with no qualifiers defined) is considered a match for any

Circumstance, Circumstance Date, or Date/Time range. Therefore, the process
discards any rules lower in the list than the first default rule it finds.

Step 7: Set the cache.

The process adds the rules that remain on the list to the cache as being selectable
for use.

Step 8: Find the best instance and check for duplicates.

The process searches down the list for the first rule that:

 exactly matches a Circumstanced Rule

 has the correct Circumstanced Date

  is in the correct Date/Time Range

 is the default Rule, with no qualifiers

When it finds a rule that matches these conditions, the process checks whether the
next rule in the list is equally correct. If it is, the process sends a message that there
are duplicate rules in the system and stops processing.

If no duplicates are found, the system prepares to use the rule that matched the
listed conditions.

Step 9: Check Availability is not Blocked.

The process checks Availability again, to see whether it is set to Blocked for this rule.
If it is, the system sends a message that it could not find an appropriate rule to use.

Step 10: Verify requestor is authorized to see the rule.

The process finally verifies that the requestor has authorization to access the
selected rule. If so, the system uses it. If not, is sends a message that it could not
find an appropriate rule to use.

Example

Your use of an application can cause Pega Platform to search for a flow named
Repair in the class Work-Contract-Application-Complete.

The system first examines in the Work-Contract-Application-Complete class, and then

(if no match is found) searches higher classes in the class hierarchy. Only flows
belonging to rulesets and versions that are present on your ruleset list are
candidates.

Exceptions

A few rule types have instances that are not associated with a ruleset and version
and no rule resolution processing occurs when an instance of these classes is
needed. For example, access roles (Rule-Access-Role-Name rule type) must have
names that are unique system-wide.

Additionally, some other rule types do not support circumstanced processing.

 21) Skin Rules :
A skin rule is an instance of the Rule-Portal
Skin rule type. It defines a skin — a collection of styles
— that determine the presentation of your application,
including colours, fonts, images, and layout of portal,
work forms, and report displays.

22) Routing :
You route an assignment to the current user if the user
who completed the preceding assignment should complete the
current task.

You route an assignment to a specific user if an

individual user must complete the assignment. For example,
you route an assignment to the manager who approves
expense reports and it appears in her worklist.

You route to a work queue if anyone in the group can

complete the assignment.

This contains two types of routing they are the

22.1) work list :
This is the one to one operator
22.2) work queue (or) work basket :
This is the one to many operators at once .
23) developer Studio :
In Dev Studio, implementation experts access rule
forms directly to address complex or less-common
configuration requirements. In addition, Dev Studio provides
features for configuring security permissions and access
control, managing rules to promote reuse, and addressing the
performance limitations of an application.

24) Admin Studio :

Admin Studio is a workspace for system
administrators, database administrators, and security
administrators that provides runtime information and
configuration options for system resources.

25) App studio :

App Studio provides core features for application
development, such as case design, data management, and
user experience. App Studio is designed for low-code users.
Typical users include application developers, front-end
developers, data engineers, and business analysts

26) Prediction studio :

Prediction Studio is the dedicated workplace for data
scientists to control the life cycles of advanced analytics
models. The model types available in Prediction Studio are
predictive models, text models (for categorization and entity
extraction), and self-learning adaptive models
27) Rule Set :
A ruleset identifies, stores, and manages the set of rules
that define an application or a significant portion of an
application.

28) Rule Set Version :

A Rule Set version is an instance of the Rule-Rule
Set-Version rule type. The version number in the form NN-NN-
NN, defines six digits in three groups that characterize the
evolution and development of a rule instance, and of the
application it belongs with. The three segments are known as
the major version, minor version, and patch version.

29) Major – Minor – patch :

The major version number of a Rule Set
version consists of the first two digits of the complete
version number. For the Rule Set version Alberta:04-
01-07, the major version number is 04 and the minor
version number is 01.
The Skin operation creates a new major version.

The minor version number of a Rule Set version

consists of the middle two digits of the complete version
number. For the Rule Set version Alberta:04-01-07, the major
version number is 04 and the minor version number is 01. The
final two digits are known as the patch version.
 The patch version number of a Rule Set version
consists of the final two digits of the complete version number.
For the Rule Set version Alberta:04-01-07, the patch version
number is 07.

30) Check In :
The Check In feature lets a team of application
developers work on an application (associated with a Rule Set
Name) without interfering with or overwriting each other's
efforts. Only one developer can have a specific rule checked
out at any one time.
On the toolbar, the check in button

31) Check Out :

A checkout is a private copy of a Rule- instance
that you update and later check in to replace a base
rule version. All checked out rules reside in a ruleset
that is only visible to your operator known as
your personal ruleset.
Two types of checkouts are supported: standard
checkout and private checkout.

32) Private Editor :

Check out rules as private edits to edit rules that belong
to locked rulesets.
Private edits are useful for quick debugging without
interrupting other team members, because during a private
edit other system architects can edit a rule at the same time.
33) Discard :
It comes to the previous changes only

34) Branch :
Pega Platform™ uses branches to help teams manage
parallel development in distributed environments. A branch is
a container for rulesets with records that are undergoing rapid
change and development. The rulesets associated with a
branch are called branch rulesets.

35) Abstract Class :

An abstract class is a rule (an instance of the Rule-
Obj-Class class) created to support the definition of rules,
including other classes. Such rules can be inherited by
subclasses of the abstract class.

36) Concrete Class :

A concrete class can have instances stored in
the database. In contrast, an abstract class cannot
have any instances.
A selection on the Class form determines whether a
class is concrete or abstract.
 37) Layout format :

Layout types

You can use the following layouts when you create the user interface
for your application:

Dynamic layout
Arranges item and label placement and alignment depending on
the type of screen, such as mobile, desktop, and laptop. You can
define breakpoints for dynamic layouts that improve readability
by determining the contents of screens on mobile devices.
Column layout
Displays main content next to supporting content in up to three
columns. For example, you can have case data in the main
column, and relevant attachments in a supporting column.
Layout group
Contains various layouts that optimize screen space by grouping
related information. You can configure layout groups to appear
as a set of tabs, a menu, or a stack after reaching a breakpoint.
Layout groups are especially effective with large amounts of
data.
Dynamic layout group
Creates repeating dynamic tabs which present information from
a property or a data page. The dynamic layout group provides
the same responsive behaviour as the layout group component.
Navigational tree layout
Organizes data into expandable and collapsible branches to help
you focus on relevant content. You can configure the branches to
allow further actions, such as opening data objects in a branch.
Repeating dynamic layout
Automates the display of repetitive data. For example, in a self-
service portal, you can arrange items in a shopping cart into a
list that contains information about each product, such as name,
type, and price. Repeating dynamic layouts support sorting and
progressive data display.
Table layout
Helps organize and compare data by column and row.
Screen layout
Determines the overall structure of a screen at a page level
through the use of templates. Screen layouts support responsive
display and can automatically adjust your interface to fit various
mobile displays. These layouts also use semantic HTML tags to
mark regions in the page and provide Accessible Rich Internet
Applications (ARIA) roles by default. Unlike other layouts, you
can use screen layouts only within a harness.
Sample repeating dynamic layout that arranges user cards
You can find more visual examples of layouts in the Gallery. For
more information, see Accessing the UI Gallery.

 Best practices for layouts

Ensure that you build a well-structured and consistent UI by

learning about best practices for using layouts as building blocks
for your interface.


 Creating a dynamic layout

Reduce UI maintenance and development efforts by using

dynamic layouts, which display content flexibly while
separating content and presentation. When you add UI elements
to a dynamic layout, the layout's format automates the alignment
of fields and labels, and saves you manual work.


 Creating a column layout

Organize data in your UI with a column layout, which displays

primary content, such as a work item, alongside related
supporting content, such as an attachment. When you structure
your content with a column layout, you enhance the readability
and visual appeal of your application.


 Creating a navigational tree layout

Help your users navigate large numbers of nested entries by

creating a navigational tree layout with expandable branches.
Navigational tree layouts source data from a page list property,
and reflect the structure of the source.
  Creating a repeating dynamic layout

Save development time by automating the display of repetitive

data records with a Repeating dynamic layout.


 Layout Groups

Layout groups help you modularize closely related information

and optimize the window area. By using conventional and
dynamic layout groups, you can present the information that
your users need in neat chunks, and create clearer user interface.


 Table layout

Tables are flexible user interface components that help you

present large amounts of information in a clear and consistent
way. Because you can quickly customize and expand tables,
they provide a reliable basis for users to view or compare
information.


 Creating a hierarchical table layout

Help users access and compare nested data with a Hierarchical

table layout. Hierarchical table layouts support expandable
rows, which can provide you with a more compact view of your
data.


 Configuring a screen layout

Determine the purpose of each area of the screen layout and

identify the section to be placed in each area. When you create a
new harness, the application populates it with a default screen
layout, which you can reorganize conveniently by using one of
the out-of-the-box templates.
 
 Managing field validation in hidden sections

Define whether your users receive a warning when they leave a

hidden required field empty. For example, if you use tabs, you
might want to display validation errors for empty fields that are
not currently active.


 Configuring semantic headers

Configure semantic headers to ensure that users across browsers

and assistive technologies have an equal and accessible
experience in your application. You can use semantic headers as
navigation landmarks for screen readers, an organizational
component for content, or as table of contents for a page.


 Configuration options for layouts

Learn about the layout configuration options that you can use to
customize your layout. For example, you can specify the format,
the visibility of the layout, and the source of data for dynamic
layouts.
38) Validations :
A validation rule is one way to restrict input in a
table field or a control (such as a text box) on a form.
Validation text lets you provide a message to help users who
input data that is not valid.
And validations it is divided into the two types they are the
38.1) Client side validation :
38.1.1) Always :
It is a mandatary field should be write
38.1.2) Expression :
By using the expression should be write
38.1.3) When rule :
By using the when rule should be write
38.1.4) Edit input :
 Edit input processing occurs automatically,
as the system accepts user input and places it on
the user's clipboard.
38.1.5) Edit validate :
 Edit validate processing occurs only later,
when an activity uses the Property-Validate
method with that property or uses client-side
format validation.
 38.2) Server side validation :
When you enter data, the browser and/or the web server
will check to see that the data is in the correct format and
within the constraints set by the application. Validation done in
the browser is called client-side validation, while validation
done on the server is called server-side validation
In the Validate at a time multiple properties we can handle
And flow actions should be configure and list functions

38.2.1) Obj-Validate method:

Use this method to apply a validate rule

( Rule-Obj-Validate rule type) for the object identified on the
primary page or step page.

Use the Page-Validate method — not this

method — to validate all the properties on a page against
the requirements defined in their respective Rule-Obj-
Property rule instances.

38.2.2) Edit validate:

Edit validate rules are defined on

properties, and not on activities or flow actions. Edit validate
rules are used for client-side validation, which means that
the value users enter is validated immediately without
referencing the server. Validation occurs when users make a
change to the entered value.
39) Environment :
The environment is divided into five types they are
the
39.1) Development :
39.2) SIT : System Integration Testing :
39.3) UAT : User Accestance Testing :
After you complete testing in a
Test environment, it is common to perform User
Acceptance Testing (UAT) in a designated UAT
environment, which could be a preproduction
environment. UAT ensures that users will be able to
successfully complete their work and meet business
objectives.
39.4) Pre- Production :
The standard staging, or pre-production environment,
supports 45 concurrent users.

The production environment scales according to your

business requirements and runs on Pega’s highly available,
fault-tolerant, and resilient architecture, which is designed
to provide uninterrupted service.

39.5) Production : Live

In the production environment, you can select a
subset of users to test the modifications in a
production environment, and then roll out the changes
to all users when the test results are acceptable. In this
case, you activate the change request right away.
40) Time Bound requirements:
SLA : service level argument
It can perform only single task
A service-level agreement (SLA) establishes a
work completion deadline. Organizations often
establish service-level agreements to enforce on-time
performance. These obligations range from informal
response-time promises to negotiated contracts.
Agents : It can perform repeadly task (or) single task
also
An agent is an internal background process
operating on the server that runs activities on a
periodic basis. In a multinode cluster, an agent can run
on multiple nodes.
And it is SLA divided into four types they are the

40.1) Case level :

In this should be configure in the case level only
40.2) Stage level :
In this should be configure in the stage level only
40.3) Flow level (or) process level :
In this should be configure in the flow level (or) process
level only
40.4) Assignment level :
In this should be configure in the assignment level
41) Urgency :
An urgency value is a numeric value used for
indicating priority of work to be performed, both for
automated tasks and assignments requiring user
interactions.
In the each and every where urgency default will be 10
only . And the urgency time increases up to 100.
And it is divided into three types they are the
41.1) Goal :
41.2) Dead Time :
41.3) Pasted Deadline :

42) Correspondence :
Correspondence is the PRPC term for
outgoing email messages, printed letters, or
facsimile transmissions produced by the system
and its users. These are typically associated with
one work item (or a cover or folder) and may
consist of text, images, or both.

A correspondence type rule indicates whether a

piece of correspondence is a printed letter, fax, email, or
SMS phone text. Each type is associated with a different
Data- subclass, such as Data-Corr-Email, that holds the
content of correspondence items.

Correspondence refers to letters, emails, forms, and similar

materials that are sent to these parties.

You can send correspondence by email, fax, text message,

and conventional mail.

And it is divided into the four types they are the

 42.1) Email correspondence :
In Pega Platform™, the system can send
automated email correspondence to all relevant parties. For
example, consider a requirement for an automobile claims
application. The application sends an email to customers
when their claims are successfully filed, and any time the
status of the claim changes.

42.2) fax correspondence :

42.3) Text message correspondence :

42.4) conventional mail

correspondence :

43) Data Transforms :

A data transform defines how to convert data
that is in one format and class (the source) into data of
another format and class (the target). The supported
formats are clipboard and JSON. Using a data transform
instead of an activity to set property values speeds up
development and makes application maintenance
easier.
43.1) Set :
The Set action has a fixed Relation setting
of equal to. That is, the Set action always sets the
target equal to the source, and establishes no other
sort of relationship between the target and source.

43.2) Remove :
 To remove a top-level page, the page must
be specified on the Pages & Classes tab.

You cannot use Top, Parent, or param in the Remove

action.

You cannot remove the primary page (the page of the

Applies To class of the data transform).

You cannot remove a parameter (specified on the

Parameters tab).

43.3) update Page :

The Update Page action sets the page
context for the subsequent (children) steps.
Use the Update Page action when you want to set
values on a target page that is different from the data
transform's primary page, and you want to:
 Avoid entering the target page name each time in
the children Set actions
43.4) Apply Data Transform :
In the Step properties pane, in the Run data
transform list, select the data transform that you want to
call in this step.
43.5) Sort :
With the Sort action, you can sort a Page List
property according to single-value properties in that
Page List. For each single-value embedded property,
you can specify sorting in either ascending or
descending order of that property

43.6) Comment :
 A response data transform is required
when the data source class is incompatible with the
data page class (the recommended pattern to achieve
true data virtualization). Select the data transform to
use in the Response Data Transform field on the Data
Page rule form on the Definition tab, in the Data
sources section.
43.7) When :
It is a single condition type
43.8) Otherwise When :
It is a multi type condition type
43.9) Otherwise :
It is a other than when type of condition
43.10) Append to:
Use the Append to action to copy a page
from the source to the target, or to copy all of the
elements in a source Page List property to a target Page
List property. The target must be of a class that is
compatible with the source page.
43.11) Append and map to:
Use the Append and Map to action to
append a page to the target Page List mode property
and set the context to that page for subsequent child
actions to map properties on that page. The target and
source can be of different Applies To classes.
43.12) For Each Page in:
Use the For Each Page In action to have
the system apply the subsequent actions to every page
in a target Page List or Page Group mode property.
After the For Each Page In action row, the system goes
down the subsequent children rows and iteratively
 applies the actions in those rows to each page in the
target.

43.13) Exit For Each :

Use the Exit For Each action to stop the

iterations of the For Each Page In action. Actions at the same
level as the Exit For Each row (its siblings) are not performed
by the system.

The Exit For Each action is typically used as part of an overall

conditional structure

43.14) Exit Data Transform:

Use the Exit For Each action to stop the

iterations of the For Each Page In action. Actions at the same
level as the Exit For Each row (its siblings) are not performed
by the system.

The Exit For Each action is typically used as part of an overall

conditional structure.
44) Data Page:
A data page defines the contents of a
clipboard page and enables the system to access data
from a range of sources on demand. Learn about the
components of a data page that you can define
depending on your business requirements.

Scope of data pages:

The scope of a data page defines
the thread that can access the data page. You can select the
scope on the Definition tab of the data page.

A data page scope can be node, thread, or requestor:

 Thread –

The page is created in a single requestor

thread and can be accessed as often as needed by
processing in that thread.

 Requestor –

The requestor can access the page(s)

loaded across all threads.

 Node –

Any requestor executing on the current node

can access the pages.

Types of data pages

There are three types of data pages:

 Read- only :
This is a read-only page available to only
one thread, a requestor, or multiple requestors (on one
node) in your application. Read-only data pages can be
modified only during page load and post-activity
processing. These data pages are displayed in the data
page list on the clipboard.

 Editable:
This page contains initial contents that can
be accessed in read-write mode. Editable data pages do
not have a refresh strategy or save plan and cannot be
node-level in scope. These data pages are displayed in the
user page list on the clipboard.

 Savable :

This page provides a save plan through a

database source or an activity so that users can update
data and write to a system of record. Only savable data
pages can be referenced in save data page locations,
which are areas in the application where you can list
data pages to save. For example, you can list the pages
to save in flow actions during postprocessing, the Save
Data Page shape to use in Case Designer or the Flow
form, and the Save-DataPage method to use in activities.
In Data page the data source is divided into the
eight types they are the

1)Connectors :

Connectors pass application data to an

external data source through required or optional
parameters and parse the response to map source data to
the data structure used in the application.

Consider the process of applying for a loan with a Pega

Platform application.

2) Data transform :
A data transform rule provides a
purpose-built rule for easily transforming and mapping
clipboard data without using activities.

3)Report definition :
A data page is simply cache. A report
definition is simply a SQL query used to retrieve records
from a database - that we then store in our data page
(cache).

4) Lookup:
A lookup data page creates a "Page" data
structure data page, i.e. it contains only 1 record.
5) Activity Type :
The Activity Type is a field
on the Security tab of the Activity form describing
the activity's characteristics. An Activity Type has
one of the twelve values listed here. Five of these
types identify activities that you can reference
directly in flows.

6) Robotic automation :
Robotic process automations (RPAs)
are automations that run in the back office. For example,
you can use an RPA to obtain a credit score from a legacy
system that you can then display on a Pega Customer
Service application account overview dashboard.

7) Robotic Desktop Automation :

Robotic desktop automation (RDA),

also known as attended automation, refers to a desktop bot or
virtual assistant bot that lives on an employee or end-user’s
desktop. Not only does it drive efficiency and productivity, but it
also helps to boost employee and increase customer
satisfaction.
8) Aggregate data :
You can now configure data pages to
aggregate data from multiple sources. With this
enhancement, data pages load more easily, making your
implementations faster and easier. For example, by
aggregating sources, you can call multiple REST connectors
to load your data page, instead of using an activity.

45) Report Definition :

A report definition rule defines a
report definition report. This rule generates an SQL query
that retrieves and sorts information from the PegaRULES
database, an external database, or an Elasticsearch index,
and generates HTML that displays the results in a variety of
formats. You have a range of options for interacting with the
results, depending on the settings on the Report
Viewer tab.