Application

Application is Set of Functionalities, which will be developed by using any technology. Application
achieves business Goals.

Application: Set of business Functionalities providing business solutions

it is a software product; we will use it to perform business. It has the components and user interface
screens using that we can communicate with application and perform some business.

Types:

1. Framework application
2. Implementation application.

1) Framework application: Generic

To capture or to create generic components (used anywhere in application).
Ex: Customer details, details collection forms.
Uses: Reusability, time save, no need to double work.

Pega will give 30-40% FA code, we can reuse and modify it.

2) Implementation application: Specific

Use for specific components which are specific to the business.

In application first we create the structure, then further we develop.

When we create new application, below components gets created.

1. Application name,
2. Application type,
3. Organization type,
4. Operators ID and Password.
Here, we may create specific functionalities like Vehicle Details in Vehicle Insurance Implementation.
Health Information form in Health Insurance Implementation.

The Advantages of Creating FW Application:

1. Re-Usability of features
2. Easy to maintain
3. Easy to extend the business processes.

FYI

Pega rule OOTB (Out Of The Box  Built-In or Predefined) application is also a kind of Frame Work
Application with built in Features.

Any application that we create must be created on top of Pega rules application.

When we create our application make sure it has both Framework and Implementations.

Pega Rules Process Commander

This is application Development environment provided (by Pega Systems) to develop Business
Process Applications, using it’s ready-made functionalities.

Business Applications can be developed without the need of coding (UI HTML, Business Logic, DB
Queries).
Login Screen

User name: Administrator@pega.com

Password: install (All Lower Case)

Operator ID: - The login ID or User Name which we use to login to PRPC environment to access it’s
applications.

Operator: - Is the person or user who login to PRPC to access it’s application.

On top left we can see Application: Pega Platform (The name of application is PegaRules).

When we use credentials administrator@pega.com, PRPC takes the Operator to a Built-In

Application

“PegaRules”

This PegaRules application is the one which holds all the readymade functionalities provided by
pega.

Organization Structure
Here Organization is Top most Parent.

Division is next level to Organization and being parents to different Units.

Units are the main Production area where business processing will get initiated and processed.

When we transform the above structure into classes.

In an application we need below classes.

1. Organization class (Parent Class of all the classes divisions, untis etc..)
2. Division classes (Parent classes of all Multiple different Units)
3. Unit class (This is where Business gets initiated and processed).

From this, after we create application, we must have to create classes of all levels.

But, PRPC has automatically create all these classes while we create new application.

EXAMPLE: Here we see ALLS-AllState-Work. These are the 3 different classes create

Org, Dev and Unit Levels.

Here

ALLS  Org Class

AllState  Division Class (Name Space Appliation Classs)

Work  Unit Class (Work Class , where the business process gets initiated and processed).

Relation between Current

Application and Built on
Application
To see built on applications. Follow below navigation.

Let’s look at built on application of IMPL App.

Login to IMPL app  application menu  Definition

IMPL is built on  BAJAJINS (Built on application)

Done.

Similarly, lets look at Built on application for FW application.

In order to open FW application definition, there is no need to login to FW app. We can do it from
IMPL itself..

Click edit icon beside FW app name

It will open FW application definition

Click on edit icon against Cosmos application

Click on edit icon against pega rules

Pega rules does not have any built on application. Pega rules is Base platform.

OOPS- Encapsulation
Group of Attributes and Methods (Functional Components), binding together into a package.

Class
What is a Class?

Class is a unit structure which contains business functionalities.

Class is executable and it takes a specific input to process the business transaction and it generates
a specific output as a result.

 Functional components will execute some business logic.

 We will create some rules in class, all rules together will execute some business logic.

Classes are created inside an application. Below diagram shows the same.
  We create an application
 We create classes inside an application
 We create functionalities inside classes.

Types of Classes
There are two types of classes.

Concrete Class:
Define the functionalities + Initiate transaction by executing functionalities + Generates a
transaction ID + the transactions get closed here.
We can reuse the functionalities.
Abstract Class: Define the functionalities + We can reuse the functionalities.

1. Concrete Class: Here we can Initiate business transactions and process it.

2. Abstract Class: Here we CANNOT initiate business transactions.

For example.

Imagine a business of Bank. We have below 3 classes.

1. Insurance (Concrete)
2. Loan (Concrete)
3. Verification. (abstract)

We can initiate Insurance and Loan transactions at the appropriate concrete classes of
“Insurance” / “Loan” respectively.
 But we CANNOT initiate above transaction at “Verification” class, because it’s an abstract
class.

Concrete class Abstract class

 Business can start and end here. Business cannot start and end here.

 Concrete can connect with Database.  Abstract cannot connect with Database.

 Work class available only in concrete.  Work class is not available in abstract.

Pega platform groups rules into classes according to their capacity id reuse. Each group is a class.
Each application consists of three class types.

WORK, INTEGRATION, DATA.

Work class: contains the rules that describe how to process a case. Such as process, data elements
and user interfaces.

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 data base or a third party
we server.

Data class: Contains the rules that describe the data objects used in the application, such as a
customer data type or order items, data types.

When we create an application, pega also creates the structure.

We have class layers available in pega. The layers are nothing but.

Organization layer
Data class

Integration class

Frame work layer

Data class

Integration class when we create an application,

Work class few classes got automatically created.

Implementation layer
Data class those are user defined classes.

Integration class

Work class

For every concrete class we have Test Connections in down available.

For every concrete class the table got created in data base, by using Test Connections we can find
the table in pgAdminConfiguration.

Go to pgAdminConfiguration

 Server
 Data base
 Schemas
 Data
 Tables

Class is identified by leaf symbol.

Classes are divided with eyephone – symbol.

Organization structure

 Org and division layers are abstract classes.

 Unit layer is concrete class.
 Only business process will happen in abstract class.
 Org and Division layers maintain common components.
 For every concrete class we have test connections in down side.
 For every concrete class the table got created in database, by using test connections we can
find the table in PG Admin configuration.
 When we create an application, few classes got automatically created those are the user
defined classes.
 Classes are divided with “- “eyephone.
Predefined Classes in Pega
The top most predefined classes are
@baseclass, Work-, Data-, Rule-, Code-, CMIS-, Assign-, Embed-, Index-, Int- , Branch- etc…

Class Group: - This is combination of One or more abstract classes and first Concreted class which gets inherited
from OOTB class ‘Work- ‘.
For our implementation application the class group is “ALLS-AllState-Work” which inheriting from Work-Cover-.

Looking at the Class Definition

When we create new application, PRPC has create ‘so many’ classes. Out of which we are focusing
on 2 different classes.

BAJAJ-BajajAuto-Work

Let’s look at the definition of these three classes.

Right click on class  Definition

Bajaj – Org Class – Abstract class

BajajAuto--- Division / Application class

Division class is: Abstract class.

Unit class is: Concrete class.

Work class  this is the class, where business transaction gets initialized. Transaction ID gets
generated and stored.

Inheritance in PEGA
Inheritance:
It is the process of accessing the attributes and functionalities of one class into another class.

Here at least two classes will be involved. One of the two classes acts as parent class and the other
one acts as child class.

Pega has two types of Inheritance.

1. Pattern Inheritance
2. Direct Inheritance
Patten Inheritance: -

After We create Implementation application, PRPC has created many classes out of these the three
important classes are

ALLS-AllState-Work

ALLS – Org , AllState – Div , Work – Unit

Here If AllState Class wants to Utilize the Components of ALLS Class, AllState Should be a child of
ALLS.

Similarly If Work Class wants to Utilize the Components of AllState and ALLS Class, Work Should be
a child of AllState.

Pattern Inheritance :- Pattern Inheritance used call name Pattern.

ALLS-AllState-Work : - This is 3 different classes.

1. ALLS
2. ALLS-AllState (AllState)
3. ALLS-AllState-Work (Work)

Here the ‘-‘ Sysmbol represents Inheritance Relation between Two Classes.

For Example :-

A-B , means B is Child of A.

A-B-C, here C is child of A-B

In PRPC the class definition is a Pattern of Multiple classes separate by ‘-‘.

For our Classes

1. ALLS-AllState-Work (Work)
Parent of Work class is ALLS-AllState
2. Parent of AllState is ALLS.

Summary: - By means of Pattern Inheritance PRPC utilizes the properties of Org, Div into Unit.

Direct Inheritance: - The parent class in direct inheritance is specified in the class rule form under
the dropdown “Parent class Directed”

For testing

Remove the parent class and try click on save.

It says mentioning direct parent is mandatory.

As that is mandatory try choose a class Assign-Archive.

We got a different error message

“Class Group should inherit from Work- or any of its subclasses.”

This means, for a class group the direct parent class must be “Work- or Work- child classes”.

We want to access the functionalities of FW work class into IMPL Work class.

To access the functionalities of different application classes. Pega provides another type of
Inheritance. “Direct” inheritance.

Let’s look at direct inheritance parent class of :FW work class & IMPL work class.

Direct inheritance is defined in the class rule form

Go to IMPL Work class

For IMPL Work class the direct parent is Work-Cover-.

Let’s look at FW Work class Direct parent.

For FW work class also, the direct parent is “Work-Cover-“

Now, we want the IMPL Work class to derive (Inherit) from FW work class. For that make below
changes
  IMPL Work class can access FW Work class
 FW Work class can access Work-Cover-
 At the same time, IMPL work class can also access the Work-Cover- via FW Work class,

Let’s make these changes in our application classes.

Login to IMPL application

Definition of IMPL work class

Remove Work-cover- and choose FW Work class.

Save. Done.

Understand Basic Rules in

Pega
FYI: Ignore, Reading RED COLOR Sentence for now.

The below are some basic rules in Pega

 Property, Section, Flow Action, Flow.

1. Property: - Property is just like a variable in other programming languages, it holds values,
it’s associated with name, Property Type (text, decimal, date etc), Control…
 This is an instance of Class Rule-Obj-Property.

Property

This can be created under Data Model Category.

To Create a property, follow below navigation

A Property will have below attributes.

1. Name: Name of the Property

2. Property Type: The Type of Data that a property can hold be identified by this attribute.
3. UI Control: - This identifies, how this property should be visible when it is added into
design Phase of UI (Section)
4. Table Type: Optional, to define the label values of Radio buttons, Dropdown etc…

2. Section
Section is a HTML Rule, used to design User Interface.

This is an instance of class Rule-HTML-Section

This can be created under User Interface Category.

A Section is going to hold different controls into it’s layout.
Layout is like a Table element in HTML which can be used to Align the Controls.

A Section can hold properties into it’s layout and associate them with Controls.

3. Flow Action: It’s a container of Section which adds an action to the UI like Submit, save,
cancel etc.

This is an instance of Class Rule-Obj-flowAction

Flow action can be created under Process Category.
Flow action is like a container of Section.
The section we have created should be added into flow action.
A Flow Action allows a user to perform an action like Submit, save, cancel etc…

A Flow Action Can be integrated into flow by using assignment shape’s outward connector.

4. Flow or Work Flow: Flow defines transaction Life Cycle.

This is an instance of class Rule-Obj-Flow

A Work Flow is heart of PRPC transaction processing.

 Any Transaction processing has to be designed using a work flow.

The below are basic flow shapes.

1. Start: A Transaction gets initiated at this flow shape.

2. Assignment: The primary purpose of this flow shape is, used to call flow action into flow.
3. End: A Transactions gets resolved at this flow shape.

 A Flow must have one and only one start shape and it can have at least one end shape.

To create UI and make it part of Work Flow, follow below steps.

1. Identify and create all the required properties.

2. Create UI, by section rule, drag and drop properties into Layout of section.
3. Create Flow action, Include section into Flow action
4. Create Flow, use assignment shape, and call the flow action into flow using assignment
shape’s outward connector.
5. To make the flow executable, choose the option, “Creates a new work object” and then run
the flow.

Working with Properties

Creating properties related to collecting customer details.

FirstName, Last Name, Date of Birth, Age, Gender, Country, State, City, Zip Code, Phone Number,
Email.

1. First Name Text

2. Last Name Text
3. Date Of Birth Date
4. Age Integer
5. Gender Radio Buttons [ Male, Female, Prefer Not to say]
6. Country Text, pxDropdown, Local List
7. State Text, pxDropdown, Local List
8. City Text, pxDropdown, Local List
9. Zip Code Text
10. Phone Number [ Double] [pxPhone]
 11. Email Address [Text] [Email]

Understanding Dropdown
control
pxDropDown: - A Dropdown control can be populated by using below options.

1. As Defined on Property (Values defined in Local list)

2. Clipboard page calling Activity or Data Transform.
3. Report Definitions
4. Data Page.

Clipboard page: This is the page on which we have, results fetched from Table.

This page name must exactly with the page name mentioned in Activity “FetchStates” Obj-Browse
Method.

Before we use the above page, it must be defined in Pages and classes tab of Section.

Activity: This is the activity which will browse data from table.

Working with Section

Question: Create a Screen to capture customer details.

Label: Customer Details Sec

Click on covert to full section editor

Go to layout properties

Choose display header and title Please provide your basic details.

Add control, map the properties.

Choose required = always (mandatory filed) for First name, Last Name, Gender.
Working with Flow Action
and Flow
Question: Design a transaction model to process auto insurance policies.

Make customer details form as a first screen to be displayed during the transaction process.

Label: Customer Details FA

Add customer details section.

Creating flow
Create this in the IMPL Work class

Label: Begin Vehicle Insurance

Double click on assignment shape’s outward connector to call the flow action

Go to process tab of flow

Select

Creates a new work object

Under work parties,

remove the ‘default’, choose ‘pyCaseManagementDefault’.

Save

Draft Off.

RUN the FLOW and test.

Draft Flow
When we create a new flow, every flow by default will be in Draft mode

Draft flows are dummy flows.

Draft On means, it’s in Draft mode and it is a dummy flow just for demo purpose. Draft flows are
non-executable in Production.

When we create a flow, after all the configurations are done, make sure you turn off draft mode.

To turn off the draft mode, go to diagram tab and click on the icon “Draft ON”. When we click on it, it
will be displayed like “Draft Off”.
Theory Understanding Work
Object
Why do we choose pyCaseManagementDefault option under Work Parties?

If we do not select this, When the flow is executed, we get a default screen displayed, which is
[provided by pega. To avoid displaying that screen, we have chosen above option.

Why do we choose Creates a New Work Object Check box, available under process tab of Flow?
When we select this check box “Flow will be executable” that means, we see run option available
under action dropdown.

Else Flow will be non-executable, means that, run option in action drop down will not be available.

Before you test it make sure you turn off draft mode.

Technical Explanation

Selecting the Option “Creates a new work object” makes the flow to generate or create a Work
Object when a transaction is initiated.

This Work Object is a virtual entity that gets created in the background and travels through the flow
from start shape to till end shape on its way to get resolve.

Work Object is Unique Identification for each transaction.

Work Object also called as “Case”.

Each Work Object can be uniquely identified by an ID called Work Object ID or Case ID.

EX : C-123

Here C- is called Prefix.

123 is sequential numeric number.

The Complete Transaction Data Will be held by Work Object.

After We submit the UI form, Work Object data gets stored into Backend Rulebase table.

Work Objects gets stored in a table called as Work Table.

“Work Table  PC_Work”.

Once, case is submitted, WO along with data gets stored into one of the tables called as

Work Table.
To see the Work Table and Work Object Created, go to Rule base.

Open PgAdmin4 Environment

Each Work object that we have create is a record in this table.

Work Object ID gets stored in a column pyID.

pzPVStream: - In this column WO data gets stored.

All the Entries First Name, Last Name Age, Gender etc. gets stored into this column.

Here the format of data is BLOB (Binary Large Objects).

BLOB – Binary Large Object.

When flow is created in Implementation class group, the created cases stored in Table

pc_ PRIM_VehicleI_Work

When flow is created in Framework class group, the created case stored in Table

pc_ PRIM _fw_Primerica_work

 When Work Object has been created by Implementation Class Group Flow, that work object
is called as Instance of Impl class Group.
 When Work Object has been created by Frame Work Class Group Flow, that work object is
called as Instance of Frame Work class Group.

Work Object: - It is an instance of Class Group.

Class Group: - It is instance class of Work Object(S).

To see the instance of a class Group.

Single Click on Class Group name it displays list of instances.

How does PRPC identifies the exact work Table to store work objects of a class group?

C-104 is an instance of Implementation class group PRIM-VehicleI-Work

Where as

C-103 is an instance of Frame Work Class Group PRIM-FW-Primerica-Work

Each instance has its own instance class.

 Each instance class has been mapped to one physical table in the Rule base.

To see the mapping

Right click on each of class as shown below.

Click on the above row

The Above rule is called “Data base table mapping Rule”. Which Maps a class to a physical table in
the Rule base.

This rule has been automatically created when we create new application.

Also, It has created a physical table in the backend with the name pc_PRIM_FW_Primerica_Work

The Table pc_PRIM_FW_Primerica_Work is amped to Frame Work Class Group “PRIM-FW-Primerica-

Work”.

When an instance is created for Frame work class group, it gets stored into its Mapping
Table.

Every Concrete class gets mapped to a Physical Table in the Backend.

The instance of concrete class gets stored into its mapped table.

Similarly Open the mapping rule of Implementation Class Group.

Our Implementation class group is mapped to a different table “pc_PRIM_VehicleI_Work”.

The instance or Work Object of Implementation class Group gets stored into the table
“pc_PRIM_VehicleI_Work”.

When A Work Object Created it gets stored into the Mapped table of Its class Group.

We can also get the mapping table name of a class group by below navigation.

Open the Class Group definition

Scroll down

Click on the button test connection.

More About Class Group:

Class Group is an instance class of Work Object(s).

From the above definition.

All class groups are of type “Concrete”.

Keys = By default it is been prefilled with an OOTB property “pyID”.

pyID is Key of Work Objects, which is going to hold work Object ID Value.

In the Rule base, work table, pyID is the column which stored work object ID.

This can never be modified.

Keys added once and saved can never be modified.

Flow Action
It is process rule, which allows us to perform an action on assignment and it moves the case from
current assignment to next level in the flow, by completing the current assignment.

Two Types of Flow Actions:

1. Connector Flow Action (Default)

2. Local Action: - It allows us to perform an action on the assignment but still WO will be there
on same assignment and assignment will not be completed.

Example: Pop Up Windows, Attaching document to WO.

Clipboard
This is one of the main debugging tools which stores WO data and other Information Temporarily.

In other Words

Clipboard an interface between PRPC and it’s rule base, which is going to temporarily, store Data.

When we run the flow, Once we submit the customer form, this data gets stored into rule base
Work Table.

Before it goes to work table, this data gets posted to temporary storage location called “Clipboard’.

In the designer studio, bottom we can see clipboard link

Click on link

Now data is available on clipboard.

When we submit UI, Data will get posted to clipboard  From clipboard it will take to Rule base
table.

The WO data that is posted on to clip board is posted to, system created Page “pyWorkPage”.

To find WO data on clipboard, we have to access pyWorkPage.

Page: Page holds Properties and values.

When we look at clipboard, each page on clipboard is referring to a class.

pyWorkPage is referring to class “PRIM-VehicleI-Work”.

Page is going to act as a reference to class.

Page holds the properties of it’s reference class as well as it’s parent classes.

Example :

A-B-C

FirstName

LastName

X-Y-Z

VIN

Company

Page1 (X-Y-Z )

VIN

Company
Page2 (A-B-C)

FirstName

LastName

PAGE
What is a Page?

Page is an aggregate or embedded property which refers to a class and holds the properties of its
referenced class. Generally, pages to access the properties of NON inherited classes.

What is the advantage of Pages?

Using Pages, we can reuse properties (rules) for different purposes.

Suppose we have one set of common properties, we can re use these properties for different
purposes by creating multiple Pages, referring the same class where these properties are available.

A-B-Person

FirstName

LastName

Age

Customer(A-B-Person)

FirstName

LastName

Age

Employee (A-B-Person)

FirstName

LastName

Age

Director (A-B-Person)

FirstName

LastName
 Age

Generally, pages to access the properties of NON inherited classes.

Example:

A-B-C

FirstName

LastName

X-Y-Z

Age

Gener

Between A-B-C and X-Y-Z, we don’t have any inheritance relation.

In order to access the properties of A-B-C class into X-Y-Z, we need to create a page.

X-Y-Z

Age

Gener

Page1 (A-B-C)

FirstName

LastName

Now, we can access FirstName and LastName from X-Y-Z class like

Page1.FirstName

Page1.LastName.

How to Create a Page?

Creating a page in PRIM-VehicleI class, which refers to FW work Class.

Create a property and select page type.

Select a class under page definition

Give the class where the properties available.

What is a Page?

Page is an aggregate or embedded property which refers to a class and holds the properties of its
referenced class.
 Property Modes
1. Single value property: a property which holds a value
Ex: First name: Vinod

2. Page: holds multiple single value properties.

Ex: Customer.FirstName
Customer.Age
Here customer is a page.
Page will refer to a class, holds the properties of reference class.

3. Page list: collection ordered single pages.

I want to collect multiple addresses together as a list.
Ex: student ID, First Name. Last Name (For 1)
If you want multiple students then go with page list.

If we want to work with table layout, then we have to create a page list property.

Data Classes
When we create new application, PRPC has created Org, Impl Work, FW Work classes.

Apart from these classes PRPC also created, Data, Int etc.

The other classes Data and Int are non-inherited classes w.r.to Work Classes.

If we create any rules, in Data or Int classes, we can access them into work classes by using Pages.

So, anything created in Data classes can be re used for multipurpose into work classes by create
multiple pages in work Class.
Data Classes inherits from OOTB class, Data-.

Data classes are non-inherited classes w.r.to work class.

Data Classes create are

PRIM-Data (Org Data Class)

PRIM-FW-Promerica-Data (FW Data Class)

PRIM-VehicleI-Data (Implementation Data Class)

Understanding Data Classes conti…

Data Classes are non-Inherited classes for Work Classes.

When we want to create properties, those should be created under “Data Classes”. We Have to
access the properties into work class using Pages.

Again, we create more child classes for the above data classes, create properties in the child classes
of data classes and access them into work class using pages.

We have to segregate properties by their usage and accordingly place then into respective data
classes.

Child Classes of Data Class are “Concrete Classes”.

Data Classes are “Does not belong to class group”, that means it can be accessed by any class group
by using pages.

Working with Data Classes,

Properties and Pages, UI
Question: Creating a screen to capture vehicle details

VIN, Manufacturing Company, model, Manufacturing year, vehicle type (Dropdown)[2,4 wheeler,
Heavy vehicle], prior insurance (Radio button Yes /No)

Create Data-Vehicle class in IMPL, Because Vehicle details are specific to IMPL category.

BAJAJ-BAJAJAuto-Data-Vehicle

1. VIN Text
2. Manufacturing Company Text
3. Model Text
4. Manufacturing Year Integer
5. Vehicle Type PicklistDropdownLocal
6. Prior Insurance PicklistRadio Buttons Yes/No

The above properties are created in data class. Now I want to access these properties into work
class. By using pages, we can do it.

Create a page in work class, where do you want to access these properties.

Property: Personal Vehicle (Single Page)

Page definition: BAJAJ-BAJAJAuto-Data-Vehicle.

Create a section in IMPL Work class, Personal Vehicle Sec.

Add controls, map the properties by using page. Give the layout header.

Create a Flow action, and open the existing flow and make changes according to the requirement.

RUN the flow and test.

Go to clipboard and see the structure. [User pagespyWorkpagePersonal Vehicle(Class)]

 Next Business Requirement
(Claims)
Question:

 Create a data class in Org layer. Because we can use it for further insurance.
 Create a screen to capture previous year claims details.
 This should be 3rd screen in flow.

BAJAJ-Data-Claims.

1. Prior Claims Check box [Boolean] True/False

2. Claim Amount Currency
3. Claim Date Date
4. Claim Reason Text paragraph

Create page in FW-Work class. Previous year claims. Page def BAJAJ-Data-Claims.

Create a section, add controls, map the properties.

Check box caption: Please select if there was a claim made in the past year.

Create flow action. Make changes to flow, this should be 3rd screen in flow.

Condition Visibility using when condition

This rule defines the condition based on properties.

Creates under Decision category.

When rule is instance of “rule-Decision-When” class.

We can evaluate the property allowed values.

We can add any property in when rule.

We need to define the conditions in Advanced tab.

Logic string

(1) Or (2) ----------- at least one condition must satisfied.

(1) Or (2)------------- Both conditions must be satisfied.

This rule can be called from many different other rules.

 1. Section  on controls and layouts to apply visibility conditions.
2. Flow Action Under Action tab
3. Activity  At beginning and ending of steps.
4. Data Transforms.
5. When Rule etc.

Paragraph
Created under user interface category.
Used to draft some paragraph of messages and where we can even properties, sections,
images etc.
We can also include the properties.
We can also insert the rule.
Paragraph is instance of class.
Rule-HTML-Paragraph

Working with when rules and visibility conditions in UI

Q: Make changes to personal vehicle info screen, previous claims info screen as described below.

1. Claim layout should be visible when prior insurance is YES, at the same time message layout
should be invisible.
2. Claim date, claim amount, claim reason these three controls should be visible when prior
claims check box is selected.
3. Add a paragraph message into claims screen in a new layout.
Add a dynamic layout above the current.
Add a paragraph control into new layout.
Map the paragraph to this rule.

Apply refresh condition on target property.

Apply visibility condition on source property.

Working with embedding sections into another

sections
Q: create a new screen to collect address details of a customer.

1. Billing Address
2. Shipping Address

Place a check box in between these 2 addresses.

Create flow action.

Make it as a second screen of our flow.

Design:

Create a data class in org and create properties (Door No, Street Name, Land Mark, City and zip code
from org).

Create 2 pages referring to BAJAJ-DATA-ADDRESS.

1. Billing address
2. Shipping address

For check box we can use OOTB property pySelected.

Create 2 separate sections and add controls and map the properties by using page reference.

Now create a main section and embed above 2 sections into main section.

Add a check box in between Billing & Shipping Sections, map this to OOTB property pySelected.

Check box caption: Select if both addresses are same.

Create a flow action and add the main section.

Open existing flow and make this as a second screen.

Embedding sections by using page reference {Best practice}

 Address_wrapper which is in data class, can be embed into work class section by
using page reference.
i.e., Billing address, shipping address.
* If you want any other to add further like (office address, school address) you can embed
into work class section by using another page reference.
* 100 addresses I want to collect, here we are creating only one section [Address_Wrapper].
By using page reference, we can embed.
* This is called “multi-purpose reusability”
* While using this method, we can observe that the wrapper section will not be loaded into
final section.
* By the time this screen loads, the two pages billing address and shipping address should
be available on clip board. Then only the section gets loaded successfully.
Go to clip board and see, there is no billing and shipping address pages. We have to fix this
issue.
 By the time screen loads, we have to make sure that the two pages to be created on
clipboard, then only the wrapper section loads into work class section.
 For this set at least one property of both pages to some values before the screen
loads.
  This can be done in the connector after start shape.
 Double click on connector after start shape.

Set Properties
Name Value

.BillingAddress.LandMark ““
.ShippingAddress.LandMark ““

 On the connector a symbol comes.

 By doing this when outward connector of start shape gets executed, billing and
shipping address pages gets created on clipboard.
 So, the screen should gets loaded without any issues.
 After run the case, go to clipboard and check billing address and shipping address
pages loaded.

Working with Section in Data Class embedded

into Work class by page reference.

Question: redesign the address details screen by creating an address wrapper section into the data
class, access into work class with different page references.

1. Create Address_Wrapper section in data class.

2. Embed the section of a data class into work class by using page references.

GO WITH NOTES.

Table layout
When we working with “table layout”, we have to use property mode as a “page list”.
 Open table layout properties,
 In general tab, choose source as a page list property.
 In operations tab, choose inline.
(By default, a table layout is read only. Add item, delete item does not function. To
make it editable, we need to choose inline)
 In presentation tab, choose enable row numbers, to give numbering to columns.
 While working with tables, we want to retrieve or show the data.
 By that time values or records will be 1000 to 10000.
 For each page we want to display 20 records only. Then we will use “pagination”.
 It is available in table layout properties.
 Working with page list property, table layout
Q: Create a new screen to capture commercial vehicles details.
This screen should be displayed after personal vehicle claims screen.
Design:
 We already have vehicle data class.
 Create a page list property in IMPL work class.
 Create a section in IMPL work with two layouts. One for label another for table.
 Select the appropriate options in table layout.
 Add columns (map the properties to controls in bottom line, then change names in
top line) or (drag and drop the properties into bottom line, in top name comes
automatically)
 Crate a flow action.
 Open our flow, add this flow action after claims.

Data types [Data Tables]

Data base: it stores and contains the data.
Data will be stored in the form of tables.

Table: Collection of data in columns and rows.

Types of tables:
1. Master table (or) Reference table (or) static table.
2. Transaction table (or) Business tables.

These two tables are independent tables.

1) Master table: To store the personal information.

It won’t affect the table while we make any transaction.
2) Transaction table: Only transaction related tables.
It gets impacted by insert or update or delete as user makes the transaction.
Work table = Transaction table
Data Type is Just like a Table which will have Data Storage.

Data Types were called as Data Tables in Pega 6 and before.

Data Tables Storage Capacity is 10 KB.

Data Types is more than that.

Make sure that Your Data Types create under Data Classes.

Data Types Must be derived from OOTB class “Data-“.

In pega we create the tables as a data type. Mostly tables are created in Org class, because
the tables can be available in FW, IMPL class.
Mostly we are going to create master tables. (Reference).
Pr_ ---- Master / reference table. {Data class without storage}.
Pc_ ---- Transaction table. {Data class with storage}.
To create the structure, go to records tab, click on configure source.
It will create a structure and order of the table.
 Select key column (Class key)
Key column------- To identify each row uniquely
 Class key’s we can see in the class rule form (keys).
 A class can have any no of key columns, but at least one key column is must.
 The table structure got created with defined columns in data model.
 To add info. go to add records.
 Also, we can add the data from different documents, by using import/export.

 When we create a data type (Table), few rules got automatically created by PRPC.
1. Concrete class.
2. Properties.
3. Physical Table.
4. Data page. (List type, page type, saveable)
5. Report definition.
6. Data base table mapping rule also gets created.

 Only for data type, the table got created.

 Table is not created for data class.
 Data type classes are concrete class, which does not belong to a class group.
 Does Not belong to class group: - This means the classes will not fall under inheritance path
of Class Group. This are Global to multiple different class groups.
 To see the tables, we have two ways
1. Test connection
2. View--- Sys admin-- Data base table.
If we want to access the content of Data Storage, we can use below OOTB Methods.

 Obj-Save :- It perform Insert or Update

 Obj-Browse :- It fetches multiple instances.
 Obj-Open :- It fetches one single instance based on Class Key.
  Obj-Open-By-Handle :- It fetches one single instance based on Primary Key.
 Obj-Delete :- Deletes instances
 Obj-Delete-By-Handle :- Delete an instance by Primary Key.

Working with Data Types

Question: Create a Data Type Country, with columns

1. Country Code (Class Key), {text}

2. Country Name. {text}

Activity (Business logic)

Activity is a rule which is used to implement business logic.

It can be created under technical category.

The implementation of our own business logic can be done by using OOTB methods.

Method: - Method is something which is already having predefined business logic written in Java
Code.

PRPC provides many different methods, those can be accessed under Method Dropdown in an
activity rule.

We need to learn what method is for What purpose and accordingly make use of these methods in
activity rule forms.

Activity contains series of steps, at each and every step we can call ONE method.

Max number of recommended steps to add per, activity is 28. More than 28 steps may lead to
performance issues.

---------------

If it is exceeding More than 28 steps, create multiple activities and call all together in one single
activity.

An activity can be called other activity by using below instructions

1. Call 2. Branch 3. Queue

Using an activity, we can do many things

1. Create Pages on clipboard

2. Assign values to properties.
 3. Call Other activities
4. Call DB Tables and pass Queries
5. Call Other Applications by using Web service protocols etc…

Below are basic Methods

1. Page-New  To create user pages on clipboard.

2. Property-Set  Perform assignment operations.
3. Page-Remove  To delete pages from Clipboard.
4. Obj-Open To open the single record based on key column. Page structure, Editable.
5. Obj-Open To fetch multiple records (max 10,000). Page list structure, read only.
6. Obj-Save To save the data into data base.
7. Obj-Delete To Delete the single record.
8. Obj-Open-by-Handle To fetch single instance based on Primary Key (PZINSKEY).
9. Obj-Delete-By-Handel To delete the record based on Primary key (pzinskey).

Steps while creating an activity:

 Go to pages and classes tab and define the pages that we wanted to create or access.
 Define the class from where we are using the data.
 Come back to steps tab
 Select the method and step page.

when we run the activity, to see the results on clipboard

 Go to clipboard
 Beside thread select Standard.
- User pages
-Page (Bajaj-Data-Vehicle).
Click on the page
We can see the results.
 Here we can see one OOTB property. pxObjClass.
 pxObjClass: this property holds the reference class name of page.

 When we use these methods PRPC auto generates SQL queries.

 If we want to access physical tables of any DB from PRPC, we need class name
parameter to be passed.
 If we want to communicate with tables, we can use activity methods.
 When we run the activity, we can see step by step execution in Tracer.

CALL, BRANCH, QUEUE

By using these we can call another activity.

CALL: overall execution of child activity will takes place.

 Parent activity will wait till child activity execution gets successfully.
 Then parent activity will resume from the next level.
 Then end the activity.
 Synchronous process. It will wait for acknowledgement.

BRANCH: Parent activity will not execute after child.

 Parent activity will wait to execute child activity.

 After child activity execution, the remaining steps from parent activity will be ignored from
execution.
 Then end the activity.
 Synchronous process. It will wait for acknowledgement.

QUEUE: Parent activity will not wait for child.

 We have to choose Asynchronous activity in settings of tracer.

 Then execute the activity.
 Parent will run in different thread.
 Child will run in different thread.
 Rest of the steps after child activity, will definitely get executed.
 Asynchronous process. It will not wait for acknowledgement.

Whenever child activity is called by queue, parent will invoke the child. But parent will not wait
for child to be finish its execution.

Tracer, Clipboard, Live UI

Tracer: It is a debugging tool in PRPC. To record step by step execution of rule.

Clipboard: it is debugging tool in PRPC. Which displays the information about what is being
executed.

Live UI: it is debugging tool in PRPC. To inspect the user interface.

Tracer
Tracer: it is a debugging tool, here we can see step by step execution.

When you don’t want to trace the pega OOTB code, only want to trace our code. Click on settings,
rulesets to trace. Here select only our rule sets.

 Before trace anything “clear” it.

 Then play it.
 Now run the activity.
 Come back to tracer.
 Now only our code is tracing, not OOTB code.

For 1 activity step, we have 2 steps in tracer.

  One for start (activity begin)
 One for End (Activity end)
 In status if any error comes, it shows fail.
 When you want to see the data in tracer, click on end shape, we can see the data here.
 If any exemption come [error], step will fail. We can see the exemption in status.
 When error comes, code will stop tracing.
 We can see parameter values in tracer only.
Click on good --- “Unnamed page” to see parameter values

Standard properties
Property: It holds the value.

Pega has provided some pre-defined properties, which starts with prefix px, py, pz.

These are pega OOTB properties.

PY Properties: we can Read and Write the values.

PX Properties: we can read only. (Retrieve)

PZ Properties: we can’t Read and Can’t Write.

Obj-Browse

Objclass :- The Table Class.

PageName : The data fetched will be placed on clipboard on the specified page.

Bottom Statecode or statename are select and where clause parameters.

In logic you can defined Where clause logic.

Done.

Page List Property: - It is a property mode, which refers to a class and holds multiple Pages of the
referenced class.

 Obj Results are read only page list.

In other words, page list is an Ordered collection of pages.

Each page will have an index value like 1, 2,3 and so on N…

Obj-Browse execution

When an Obj-Browse method is executed, the results on clip board will in Pega List format.

On any table if Obj-Browse is executed it retrieves the result on to an OOTB page list “pxResults”.

Which in turn will be available on another page which we have specified in Obj-Browse Method.

pxResults is a OOTB property which is available in OOTP class code-pega-list.

That’s why our page is holding (Code-pega-list).

Data will not fetch directly on pxResults. We will define one page in Obj-Browse. In that page data
will be available on pxResults format only.

Here ALLSStates Page is holding pxResults page list property, which is of class Code-Pega-List.

Hence ALLSStates page must be referring to Code-Pega-List class.

Each page of pxResutls i.e, pxRestults(1), pxResults(2) and so on…. Are holding State Code and State
Name Properties.
The structure will be like this,

States (Code-Pega-List)

States.pxResults (ALLS-Data-States)

i.e., Page.pxResults(Class)

On Browse page, it holds below prop

pxResultCount 4

SELECT "countrycode" AS "CountryCode" , "countryname" AS

pxSQLStatementPost
"CountryName" from data.pr_lic_data_countries

SELECT "countrycode" AS "CountryCode" , "countryname" AS

pxSQLStatementPre "CountryName" from {CLASS:LIC-Data-Countries}

Pre-Query will be transformed into Post Query.

Pre query contains class name in place of physical table name.

Post query will have physical table name.

Pre query class name will be converted into Table name by PC, reading the table name from Class
and Table Mapping Rule (Data base table rule).

For Dropdown, Radio Buttons,

There are 4 ways available to fetch the data from data type (Table).

1, As defined on property
2, Data Page
3, Clipboard page
4, Report definition

Working with Activity, Obj-Browse method

Q: Create an activity to fetch all the country codes and country names from country data
type.
Design: Create activity in org class. Choose country code, country name columns.
Run the activity and look at clipboard. The results will be in page list format.

Working with Dropdown, dynamically populating a dropdown

Q: populating a dropdown value dynamically at run time. Data source is a data type.
Make changes to customer details as described below.
 Remove the local list values from country property. Make the table type none.
 Populate country dropdown values at run time with the data taking from countries
data type.
Design:
 To retrieve the data from country data type, we have already created one activity.
 Open customer Details sec, open country property, remove the local list values and
make the table type none.
 Open section (Customer Details SEC)
Pages and classes tab
Page name class

Countries Code-Pega-List
Countries.pxResults Bajaj-Data-Country
Design tab
Open country cell properties,
List source type: Clipboard page
Clipboard page: Countries.pxResults
Run activity: Select the check box
Pre activity: Fetch Countries
Prop for value: .Country Code [for DB]
Prop for display text: .Country Name [for UI]

CREATE A CASE AND TEST.

RULESET
Rule set: Collection of set of rules.
To see the ruleset
 Application menu
 Definition.
 Open application RS, click on edit icon to open it

 Total 6 rules got created, 2 rules are common (ORG).

 Org rules are common rules.
 If we open the ruleset, we can see the total no. of rules.
 While we creating the rule, we have to choose
1. Application context.
2. Class
3. Ruleset
4. Version (always higher)
 When we open the ruleset, we can see total no. of rules created, versions.
 Version
We will create a version to

 Add new features

 To fix the bugs
 To update any features
 To delete some features
 Performance improvement

When we want to perform any of these operations, we will use versioning.

HDFC HDFC HDFC

O1-01-01 01-01-02 01-01-03

LOCK LOCK

ADD, DELETE, UPDATE BUG FIXES

01-01-01
Major version Minor version patch version

Versioning always starts from 01----99

1) 01-01-01-> 01-01-02->01-01-03------------------------01-01-99
2) 01-02-01-> 01-02-02->01-02-03------------------------01-02-99
3) 01-03-01-> 01-03-02->01-03-03------------------------01-03-99

01-01-99------01-99-99------99-99-99
We will increase the versioning as above.

Majorly we involved in development.

After developing we will move the code into test region.

After test production (Live).

Without versioning: one operator can finish the work first; he has to wait till other developers to
complete the work. He can’t move the code to test region. So without versioning dependency is
more.

With versioning: operator can move the code to testing with out waiting.

Versioning associates with rulesets.

When we create most of the rules, we need to associate with ruleset and version.

 Click on plus icon, to add the new version.

 Give the description.

How to lock a ruleset version

Locking a ruleset version prevents create, update, delete of rule in that specific version.
A ruleset version can be locked by securing it with a password.
 Locked version will have Private edit option.
 We edit it in privately.
 If we get the exact rule, save it to another higher version.
 If not discard the edit you have done.
 If there is any check out rules, then we can’t lock the version.
 We need to check in the rules and then only we can lock the version.
How to find different versions of rule?
Actions tab --------- view Reference

Check in and Check Out (Ruleset level)

 Useful for parallel development.
 By default, the rule will be without check-in, check-out.
If we don’t work in parallel development by using check-in, check-out, the latest changes by
one user got saved and another user lost this data. [Latest changes will save].
To prevent that we have the functionality called “Enable Check-out and Check-in”
“Use check-out” enable this option in Security tab
Application repository: Here the rule is available.
Operator repository: Here we are working.

Check-out: Pulling the rule from application repository to operator repository.

[Editable, save option will be shown, after changes check in back]
Check-In: Pushing back the rule from operator repository to application repository.
[read only, save option is invisible]
Use: useful for parallel development, changes not losing.
Rule instances: Associated with version [RS:HDFC:01-01]
90% of the rules in pega associated with version. We can enable check-in/check-out to rule
instances
Data instances: not associated with version.
10% of the rules in pega not associated with version. We can’t enable Checkin/Check out to
data instances.
How to enable check-in / check-out option
Open the rulesets and go to security tab.
Here we can see Use check out check box. Select this check box
 We can see check out rules from blue box after search bar.
 We can do bulk check-in.
 Report definition
Reporting can be done by using a rule called “Report definition”.

Create ----- Reports------- Report definition.

 We have to create a report definition in the same class [table class], from which we want to
retrieve the data.
 Report definition is a query rule.
 Results will be in “List view” format [Table format].

Features

Export to PDF: Data will get exported to PDF document.

Export to Excel: Data will get exported to Excel. This can be downloaded.

 Maximum records we can fetch 10,000.

 We can export the data into pdf, excel.

Charts tab

To display reports of charts, we must have at least one summery column [numeric column] in query
tab.

We can display it like pie charts.

Report viewer: tab

Display in Report Browser

 If you check this option, report will be available for manager portal.
 Business users [managers] can access the reports using report viewer.
 Once we create report definition, we need to add this report under some category and make
it available in report viewer browser.

Data Access: tab

 Used to perform joins, like class joins, index joins, associations.

 We can retrieve the data joining two or more tables using definition data access tab.

Different Type of Joins

1. Class Joins (Matching Keys)

2. Index Joins (To join with Index Tables)
3. Association Joins (Introduced from Pega 7 – This is like a reusable join rule).

A report can be scheduled to run in back ground and an email can be sent attaching the report
results in XML format or PDF format.

This can be done using report browser.

Report definition rule can be called from

 Dropdown
 Auto Complete
 Section using table layout.

When we execute a report definition, the OOTB activity that runs in the back ground is
“pxRetriveReportData”.

Edit Column [Select clause] Columns

Edit Filters [Where Clause] Filters [Conditions].

The best practice is to Avoid Activities whenever possible.

When we want to use activity always looks for using

1. OOTB(Predefined) rules.
2. Then go for below alternate rules. Reports, DPages, Decision rules, Declarative rules, Case
Type, Data Transform etc.

Joins conti………..

Working with report definition

Report definition as a source to populate dropdown.

Q: create a new data type state with columns state code [Key Column], state name.

Make changes to customer details form, state dropdown.

 Remove the local list values from state property, make table type none.
 Populate state dropdown with the data retrieving from state table [data type].

Design:

 Create a state data type

 Go to records tab, select key column [state code]
 Add data into state code, state name.
 Create a report definition rule in BAJAJ-DATA-STATES.
 In select clause, add state code, state name columns.
 Open the customer details sec, open state property.
 Remove the local list values and make table type none.

List source type: Clipboard page

Clipboard page: Countries.pxResults
Run activity: Select the check box
Pre activity: Fetch Countries
Prop for value: .Country Code [for DB]
Prop for display text: .Country Name [for UI]
Run the case and test.
 Data page
When the data is constant, and common data across requests, requestors then we can use Data
page.

Data page works as below.

When requestor Requests for data

1. look up the clipboard for page

if page is there on clipboard, copy the data from here.

If page is not there on clipboard

2. Execute the source rule, hit the data source, fetch and place it on clipboard page.

Clipboard contains pages.

Advantages of Data Page

1. The number hits to data base reduced from N to 1

2. number pages on clipboard reduced from N to 1

3. number of times sources executes reduced from N to 1

4. time taken to load in UI is reduced.

5. Overall performance of application is improved.

Details about Data Page

Data page is Shared (cached) page on server’s clipboard.

Data page is instance of Class Rule-Declare-Pages

It can be created under Data Model Category

Data Page name must start with D_ or Decalre_

Data Pages were called as Declare Pages before Pega 7 version.

When the data is constant data certain period of time, and also the data is common and sharing is
required, then we go for this type of algorithm. [Data page].

Structure:

Data Page Can be available in one of two structures.

1. Page: If this is the data page to hold single instance

2. Page List: if this is the data page which holds multiple instances.

Object type: Data Page reference class.

Edit mode:

Data Pages can be available in one of the below modes

Read only: - These Data Pages gets created on clipboard under ‘Data Pages”.

These cannot be updated or deleted. We go for read only mode, when data should not be
manipulated by business users. THREAD, REQUESTOR, NODE

[we can’t edit or delete]

Editable: These Data Pages gets created on clipboard under ‘User Pages”.

We go for this mode when the data retrieved has to be manipulated by the business users.

[we can delete or edit it] THREAD, REQUESTOR

Salvable: These Data Pages gets created on clipboard under ‘User Pages”.

This data page is required when we want to insert or update the data into table.

We can call this data page from 1. Activity, 2. Flow.

 activity using Save-Data page method

 Flow using ‘Save Data’ page flow shape.

[we can update or delete]. THREAD, REQUESTOR

Scope of Data Page:

1. Thread: - This Data Page will be available for sharing only within one specific work object
multiple times. But not available for other work object.
[data available with in the case or session]

2. Request: This Data page will be available for sharing across multiple work objects of a single
requestor session. But not with other requestors.
[data available with in login & logoff level]

3. Node: Data Page will be available for sharing across multiple requestors who logon to same
node but not with the requestors on other nodes.
[data available based on our requirement]
Ex: Netflix, amazon plans are same, conditions are same.
Access group is required for node.

 Editable data pages will not be available at node level.

The reason being editable data pages should not be modified by other operators.

 Node Level Data Pages must need an access group to be specified.

Access Group Required
 For other scopes thread and requestor access group is not required.

Node Scope is not available for Editable Data Pages, Why?

Data Modified by one requestor, should not be shared to another requestor. That’s why Pega PRPC
environment will not show up, Node scope or Editable data pages.

Advantage of Data Page: -

1. Data Sharing as per the scope.

2. Number of times the source rule gets executed is reduced to ONE.
3. Number of times the data source gets hit (Database, file or service etcc…) is reduced to ONE.
4. The number of pages created on server clipboard is reduced to ONE.

As a result of all this the performance of application gets improved.

Load management: refresh strategy is available read-only. For editable, saveable it is not required.
Because it will comes under user pages.

If we select reload once per interaction, it will always refresh when we interact with DB. In case
every time we are getting new data, frequent changes.

Ex: ATM balance, Bus tickets

 Clear data page: When we click on this, the data page gets deleted from clipboard.
When we click on this, PRPC internally calls an OOTB activity “Flush Declarative Page”.
 Do not reload when.
 Reload if older than [see the notes].
1, If we enter Data page refresh is 1 hour, first requestor-8am-D_Page created
9 am data page gets removed.
It gets created again when a new request is been made.
2, First request- 8am-D_Page created.
Request 2 – 8:45 am (he will use the same D_Page)
Requestor 3 – 9:30 am (New D_Page gets created)
10 am D_Page gets removed.

Server restarted --------- Data page will get created

Data source for data page:

When the data page is called, it runs a source rule to perform something.

 Connector
 Data transform
 Report definition
 Lookup (fetch single record) like obj-open
 Activity
 Robotic automation
 Robotic desktop automation
 Aggregate sources (more than one source).

Multi node environment

 We will create a data page whenever sharing the data is required.
 If sharing is not required, we will go for user pages.
 Users will be connecting to the application servers by using web browser.
 From a web browser user is going to send a request to the application server.
 Application server will send a response back to the web browser.

Web browser is a client.

Application server is a server.

Working with data page, source as report definition

Q: Create a new data type city with columns city code (key column), city name.

Make changes to city dropdown of customer form as described below.

 Remove the local list values from city property.
 Populate by using data page
Design:
 Create a data type, add columns, choose key column, add data in records.
 Create a report definition in Bajaj-data-city class, with city code, city name columns.
 Create a data page, structure list, choose source as report definition.
 Open city property from customer details sec and make changes as requested.
Run the case and test.
 Parameters
Parameters: These are just like Properties except these cannot be created under classes.
These can define with in rule forms under Parameters Tab.

 It holds the data and we can send the data from one rule to another rule.
 In all rules we can see parameters tab.
 By using “Param” page we can call parameters.
 We can access them by using “. Param “to assign the values.
 These parameters will not access any data from DB.
 It will not occupy any space on clipboard at run time.
 We can see the parameter values in tracer “Unnamed page”
 In child activity (rule) if we define parameters in parameters tab, in application where ever
you call this child activity, it will ask for parameters values.

EXAMPLE:
Here I want to assign the rule 2 AGE parameter value to the rule 1 Age parameter.
I can do it by enter Param.AGE in Age in rule 1.
1. Age Param.AGE
2. Fname Param.FNAME.
Same as for rule 3, I want to assign the rule 2 AGE parameter. I can do it by enter
Param.LNAME in rule 3
1. Lname Param.LNAME

Working with parameters, Cascading dropdown

Q: make changes to state dropdown of customer details form as described below.
Populate states filtered based on selected country.
 Altering the states table.
 Go to report definition rule that we used to populate state values.
Design:
  Open states data type, add country code column in records tab, enter exact country codes.
 Go to report definition, parameters tab, define Country code (text) parameter.
 Query tab of report definition, in where clause give column source .Countrycode with the
value Param.CountryCode. select use null if empty in settings.
 Open the section, open state dropdown cell properties, click on report definition again, it
will ask for parameter value, give the value as .Country.
 Run the case and test it.

Pass current parameter page

First, we will create a child rule with some parameters. Later we will create a parent rule with some
parameters and we select pass current parameter page.

We need to make sure that, define the parameters on calling rule (parent rule), which are exactly
matching with parameters of called rule (child rule). Matching by name and data type.

 If we have more parameters, we use this.

 It will send the group of parameters from one rule to another rule.
 Here we need to define same parameters in both rules.
Ex: in child rule if I define AGE, FIRST NAME.
The same way we need to define the parameters in the parent rule.
With same name and same data type. Then only this option will work.

Working with pass current parameter page, cascading dropdown

Make changes to city dropdown of customer details form as described below.

 Populate the cities filtered based on selected state.

Design:

 Open city data type, add state code column in records tab, enter exact state codes.
 Open report definition, parameters tab, define stateCD (text) parameter.
 Query tab of report definition, in where clause give column source .Statecode with the value
Param.StateCD. select use null if empty in settings.
 Go to data page which is calling this report definition (use view reference).
 Parameters tab of data page, define StateCD (text) parameter, go to definition tab, go down
to report def, click on parameters, select pass current parameter page.
 Now open the customer details section, open city cell properties, reselect the data page. It
will ask for parameter value. Give .state
 Run the case and test it.

Functions
we can build functions in expression builder. Build an expression.

Choose any function, click on test, if it suits our requirement, click on + to add.

Pre-Processing, Post-Processing
When we run the flow, first it will execute assignment shape, assignment shape will execute flow
action, flow action will execute the section.

If you open the flow action rule, go to Actions tab, here we can call Activity. (Pre / Post).

Pre-Processing: whenever the section loads, immediately if you want to execute the activity, you can
call the activity in “Pre-Processing”. Execute when section loads. (on load of section).

Post-Processing: I want to execute the activity when I click on submit button. You can call the
activity in “post-Processing”. Execute when click on submit. (on click of submit).

Launch portal
Case manager: whatever the flows which we have in development, those flows should be available
in manager.

Open case manager, click on ADD.

If the flow is not available there, come back to respective application where you have created flows.

Click on application menu definition.

Go to cases & data tab, here mention the flows and respective implementation class.

Come back to manager portal, click on ADD. So here we can see the flow. Open it.

Also, in case you don’t see the tables in data types after we add it.

Go to application menu definition, Cases & data tab. Here you can see the tables.

Obj-Save
This method can be used to insert or update data to the table.

The data will be stored in clipboard temporarily .pyWorkPage and then it goes to work table in data
base (permanent). Data stores in pzpvStream.

When we fill the customer form in flow and click on submit. First data goes to pyworkpage
(clipboard) and then it goes to DB.

But here I want to save the data in my own table. Because in DB, data saves in blob format. We can’t
see the data in BLOB format. BLOB = Binary large objects.
While Working with Obj Save follow below steps.

1. Define a page in “Pages and Classes” tab which refers to “Target Table” in which we want to
store the data.
2. Create this page
3. Get data assigned on this page
4. Obj-Save and mention step page as “Table Page”.
At run time, Process commander identified the Step Page Reference class by

pxObjClass TATA-Data-States
, from the class it resolved it into Table Name. Data gets stored into the respective table.

1. If the record being inserted is already found in the table matching with Key Prop Value, the
Query gets generated is “UPDATE” Query else “INSERT” Query.

Obj-Save behaviour
* When we run the activity individually, the data stores in clipboard in “Customer Data” page. We
created in pages & classes tab in activity. And that data did not store in data type (Table).

To save the data into data type (table), we have 2 options.

1. Write now. (Save the present data).

2. Commit. (Save all unsaved data).

Write-Now:

 Saves the data into tables.

 But this will save the same activity data which we are run.
 It will save the data immediately into table. It will go to differ queue and then immediately
save the data.
 This is not going to save previous unsaved records data.

Commit:

 Saves the data into tables.

 We can save the data from activity directly, when we run the single activity.
 This commit will save all the previous unsaved data.
 Commit method is been provided by pega which has to be used in the activity, when the
activity is not part of the flow.

 While using the activity in the part of flow, data is getting saved into work table while
run the flow.
 But while run the activity (independently) alone, the data is not getting saved into work
table. The activity execution is GOOD (in tracer).

For this (to save the data into table) we use above two options. Either write now, commit.
Q: why we are not using the commit in activity, which is part of flow?
Ans: when the transaction is getting processed, at the end of every flow shape process
commander is going to perform a commit internally.
Write now: saves the data immediately. It will save individual Obj-save data (Current) into table.

Commit: saves the data permanently. It will save/send all unsaved data which is available in differ
queue and present data.

Differ Queue: it is a memory, holds the “unsaved data”.

Obj-Save-Cancel: it will remove the latest unsaved Obj-save data from differ queue.

Roll back: it will remove all unsaved Obj-save data from differ queue

we don’t have any impact on already saved data with Obj-save-cancel, roll back.

Difference Between Write Now and commit

Write Now Commit

Write Now performs an Immediate commit on Commit Methods perform a commit of entire
specific Differ Queue Instance of specific Obj- Differ Queue. Thus all the Queue instances gets
Save. stored into their tables.

Obj-Save Cancel and Rollback

Obj-Save-Cancel Rollback
This method rolls back the latest un This method rolls back all the un committedobj-
commitedObj-Save. Save done so far.

It works on latest differ queue instance which is This rolls back entire differ queue.
not yet committed.

Working with Obj-Save

Q: when users make a transaction, the data of customer details form has to be stored into data type.
(table). For this.

 Create a new data type “Customer”.

With fields Customer ID, remaining fields from customer details form. All text fields.
 For customer ID generate a unique ID. This has to be done when customer form is submitted
 Create a activity to map and store the data.

Design:

 Create a data type (Customer), add columns and properties. Create a table structure.
 Create an activity in org. go to pages & class tab, create a page and refer customer class.
 Define parameters (except phone number, zipcode).
 Steps tab, page-New, Property-Set (customer ID[Build an expression], remaining parameter).
 Obj-Save [write now], page-remove.
 Open flow action [customer details fa], call this activity in post processing, because when
customer submit it will save the data.
 Open action tab, call the activity. Map the values to parameters.
 Run the flow and test. Open tracer and see any issue.
 Go to table and see the data.

Primary page and step page

Run record primary page:

When you run the activity individually, run record primary page is the start and end for execution.

pyWorkpage:

 When you run the activity in the part of flow. pyWorkpage will execute the start and end for
execution.
 Primary page will execute the activity.
 For steppage we will specify the steppage name. if we don’t give any steppage, it will take
“Primary page”.
 Always give the step page for best practice.

OBJ-OPEN
To fetch single record from table.

Obj-Open method will fetch singe record based on class key (key column).

This method is used to fetch single instance from table using class key. Country-Country Code

The clipboard structure is Page. State- State Code

When we do Obj-Open, we need to Pass below parameters. City-- City Code

1. Step Page (This page should refer to table class). Work table- pyID
2. Open Class (Table Class)
3. Class Key and value.
When we do Obj-Open the instance will be fetched on to step page (table Page), if we want to
display in UI, we need to assign data from table page TO UI related page. To do this we will use

Page-Copy.

Working with Obj-Open

Q: Create a new screen to perform “Customer Search” by Customer ID.

1) Screen contains customer ID field, Button, customer results.

2) When user enters the customer ID, click on the search button, then the results should be
displayed in read only format.
3) This should be the first screen of our transaction model.

Sol:

1) Create a page in work class which is referring to Customer Data class.

2) Create a section add text input control, map customer ID. Layout properties: inline label left.
3) Add a dynamic layout 2 and add text controls. Make controls read only always. Map the
properties by using page reference.
4) Create an activity to perform customer search by Customer ID and assign the results to UI.
5) Call this activity on click of search button.
6) Create a flow action. Add this into our flow, make it as a first screen.

In Activity the steps are,

1) Pages & classes tab, temppage BAJAJ-Data-Customer.

2) Parameters tab, CustID String.
3) Page-New, it will create a page for table class.
4) Obj-Open, it will open the record based on parameter value and place it on temppage.
5) Page-Copy, it will copy the data from temppage to primary page (pyWorkPage).
6) Page-Remove, it will remove the temppage.

Pre, Post Conditions in Activity (When Conditions in Activity)

How to Call When Rule in an Activity

When rules can be called in an activity at each and every step.

1. Step Beginning.
2. Step End.

For each step we can call at least one when condition before step and/or after step.
We can call when condition at “When” Before Step and/or at “JUMP” After step.

When: Pre-Condition.

Jump: Post-Condition.

We just need to click on When or Jump and choose the when condition rule.
There are multiple options provided to choose appropriate action after the condition is executed.

If the conditon is true or false we can choose below actions.

1. Continue Whens: It will proceed executing further when conditions, if no when conditions
available further, it will execute step.
2. Skip Whens: It will skip execution of further when conditions and proceed with executing
step.
3. Jump to Later Step: This requires a label to be specified. And execution jumps to labelled
step.
4. Skip Step: It ignores the execution current step.
5. Exit Activity: It exists the current activity at current step. Further steps will not be executed.
6. Exit Iteration: While looping it will exit out of current iteration.

Jump to Later Step: Process commander will execute from lower step to higher step 1-> 2->3->4
but not from higher steps to lower steps.4->3->2->1

1 1

2 L1 2 L2

3 3

4 L1 4 L2

Possible Not Possible.

 Step Status of Activity Steps
PRPC records the status of each and every step that is executed as part of activity processing.

Status will be assigned to an OOTB property “pxMethodStatus”.

Below are possible status values of Activity steps.

1. Good
2. Fail
3. Warn
4. Goodwarn etc…

PRPC provides OOTB when Condtion to identify step status at run time.

1. StepStatusFail : This returns true when the step status is failed. pxMethodStatus
Property value is FAIL. Other than this it returns false.
2. StepStatusGood
3. StepStatusWarn
4. StepStatusGoodWarn
 Working with step status OOTB when rules.
Pre, post conditions in activity, paragraph, Flag property
Q: Make changes to customer search screen as below.

1) Add a new paragraph rule with a message in a new layout.

2) When customer record is found Customer results to be visible, where as message layout
to be invisible.
3) When customer record is not found message layout to be visible and customer results layout
to be invisible.

Sol:

1) Create a flag property (True/False), OR for this we can use OOTB property “pySelected”.
2) Create 2 when conditions for TRUE, FALSE.
3) Create a paragraph rule, add customer ID property.
4) Add this paragraph in a new layout. Map this to paragraph control.
5) Go to layout properties and apply a visibility condition for results layout (true condition),
Message layout (false condition).
6) Open the activity, set the values of flag property to true/false based on Obj-Open step status

Case Type (Case Management)

Case: defines the work.
Flow: flow represents a transaction model.

Beginning to ending what are the different steps that are involved in the transaction that will be
defined by “flow”.

Flow defines work object life cycle. (Transaction life cycle)

Case: defines the work. Case
We will divide business flow into Stage
1) Stage Process
2) Process
3) Steps Steps
Stages depends on business requirement.

A stage can have no of process.

Actual work will be done in steps.

Case is collection of stages, Stage is a collection of process, process is collection of steps, steps = flow
shape.

Case types are mostly created in implementation class.

Because we can call FW application rules and pega platform rules also.

Case: Collection of stages.

Stage: Collection of process.

Process: Collection of steps.

Step: Flow shape.

Case life cycle going to start at start stage and gets completed at resolution stage(End).

Stage: General tab

 Automatically moves to next stage. (Go to next stage) OOTB activity pxChangeStage
This activity will change stage automatically when we select this option.
 Wait for user action. (Approval/reject)
 Resolve the case (End).
 Set case status on stage entry. (We can set the status for stage, process, steps)

Validation tab

Never

 Skip stage when rule like visibility condition.

Expression

 Set entry validation

 Add required attachment.

Goal & dead line tab

We can define SLA.

Process: General tab

Start process Always

When rule

Expression

Open process: by clicking on this we can configure the flow actions.

Goal & dead line tab

We can define SLA.

Steps:
  Route to (who will perform the assignment shape)
 Set case status
 Instructions for user
 Configure View [(add properties like sections in flow) after adding the properties click on
submit, pega automatically create section, controls, map the properties]

We can see the process (flow) manually in process tab. [open process].

When we click on save and run,

Enter details, data will come to clipboard.

Open pyWorkPage

Expand the pyWorkPage and see the data.

Work object data = case data.

When we create a case type, a case type class has been created under IMPL class. That is a concrete
class, belongs to a class group. (Child class of class group).

NOW open case type class, process, case type, pyDefault.

Pega has taken pyDefault as case type name. Vehicle insurance is just label.

If you create another case types, each case type is created with pyDefault. The name that we give is
just a label. pyDefault is the actual name of the case type that the system will create.

What is the name of the case type that gets created?

pyDefault

When we click on save and run, the work object should be created. To create this work object gets
created by internally running OOTB activity ADD activity. This is from 8.5 version.
8.4 version

The starting flow that gets executed in PRPC is pyStartCase. This flow will create a new work object.

Main points of case type:

When we submit the case data, first it will go to clipboard pyWorkPage, which is associating
with vehicle insurance. Then the data will go to the vehicle insurance table in the data base.
We can see it by
1) Test connection
Or
2) Vehicle insurance class -------View sysadminData base table.
But here the data stored in IMPL Class. [BAJAJ-BAJAJAUTO-WORK] but not in case class
[BAJAJ-BAJAJAUTO-WORK-VEHICLEINSURANCE].
There is a specific reason for this
When we click on save and run,

First rule that executing here is the “pyDefault” case type rule.

So, this case type rule is executing the “pyStartCase” flow.

This rule is calling one more sub flow.

Click on + symbol, it will open the sub flow here itself. pxStartCaseType.

This case type is executing the first stage in the case type.

1. pyDefault
2. pyStartCase
open this
Create a new work object

3. pzInitializeStage
pzGetFirstStage
pxChangeStage

Add
Add Work By using these OOTB activities, we can create a work object in case type.
Add Work Object

 Belongs to a class group

Case type classes are child classes of class group.
 It also creates a case type with name “pyDefault”.
About flows created:
 The processes we have added during case type design are sub flows, for those “Create a new
work object” option is disabled. Meaning that these flows can’t create a new work object.
 But definitely we need a starting flow which creates a work object.
 Case types have created another flow “pyStartCase” automatically.
Open this flow and see in process tab.
Create a new work object.
 That means when we run a case type, work object gets created by an auto created flow
“pyStartCase”.
 Apart from this, it is creates a case type rule with name “pyDefault”.
 When we click on vehicle insurance crate menu, it is going to execute pyDefault case type
rule.
 In vehicle insurance case type Process tab, we can see the starting process.
 Open pyStartCase flow.
 This pyStartCase flow is calling an activity. pzInitializeStage.
 This activity in turn is calling another two activities.
 1. pzGetFirstStage: this activity executes starting stage defined in case type.
 2. pxChangeStage: this activity will execute and change it to next stage.

Process commander finds the details of all stages from case type, in stages tab.

The execution of case types, stages, process, steps.

New menu-------Choose case type
 Executes pyDefault case type.
 Executes pyStartCase flow.
 Calls an activity pzInitializeStage.
 Calls an activity pzGetFirstStage.
 Calls an activity pxChangeStage.
Stage names will be read from pyDefault case type defined under Stages tab.
When we create a case type, it may create below rules
1. Case type class (Concrete class, belongs to class group) in IMPL class as a child class.
2. Flows (pyStartCase, sub flow (pxStartCaseType)).
3. Case type (pyDefault)
4. Properties, section, flow action.
5. Data transform. (pyDefault DT)
6. Work parties. (pyCaseManagementDefault)
7. OOTB activities (pzInitializestage, pzGetFirstStage, pxChangeStage) also ADD, ADD
WORK, ADD WORK OBJECT.

Working with case types

Q: create a new case type “Vehicle insurance”
 Transform the existing flow into case type.
Design: we have already created flow action, sections. So use them here.
1. Customer Search
Customer Search FA

2. Customer Info
Customer Details FA
Address Details FA

3. Vehicle info
Personal vehicle FA
Personal vehicle claims FA
Commercial vehicle FA

4. Case Close
Resolved.

Work object status, field

value rules
Status: we can apply the status in flow, in assignment.
We need to update the status in assignment shape.

 Useful for tracking and report purpose.

 If single word------ New.
 If double word----- Pending-Qualification.

In Case type: work object can be assigned with status.

 At stage level.
 At step level.

Created under field value rule.

Maintain same name of the field value rule and value of the field value rule. So that we can have a
clear idea about it.

Helps to understand and analyze the business.

Pega will provide some OOTB status.

We can use OOTB status. If the status is available. We don’t need to create that again.

 In clipboard pyWorkStatus------ to store the work object status.

 Choose pyStatusWork while we are creating field value rules.
We can also assign the status in assignment.

Open assignment  Assignment properties advanced assignment details case status.

Here we can give the status.

Field value: used to set work object status.

Field value must be associated with OOTB property “pyStatusWork”.

pyStatusWork is an OOTB property, which holds work object status on pyWorkPage. The same
column will be available in work table.

 Created under data model category.

 Choose pyStatusWork while we are creating field value rules.
 pyStatysWork--- to store WO status in pyWorkPage and DB.
 Maintain same name of the field value rule and value of the field value rule. To have a clear
idea.

Working with work object status, Field value rules

Q: assign below status too case.

Assignment name Status

1. Customer Search New
2, Customer Details Pending-Custinfo
3, Address Details Pending-Addressinfo
4, Personal Vehicle Pending-PerVehiInfo
5, Previous Claims Pending-ClaimsInfo
6, Commercial Vehicle Pending-Commvehiinfo
7, Case closed Resolved-Completed (OOTB)

Design:

 Create field value rules in IMPL Work.

 Select pyStatusWork.
 Give the same name for value of the field value rule.
 Create all filed values for 2,3,4,5,6,7.
 Open case type and apply the status at step level.
 Create a case and test it.

Work object locking

To prevent parallel processing of work object and to avoid data inconsistency.

WO locking functional:

 When an operator tries to edit a case, PRPC verifies if there is a record in the table
PR_SYS_LOCKS.
 If record is found (means already case is locked by another user). It displays a message to
current user saying that some other operator edit the same case.
 If there is no record in the table, PRPC inserts a record into the PR_SYS_LOCKS table
(meaning that lock is acquired by current operator), allows the current operator to edit the
case.

Note:

 Acquiring lock: insert record into PR_SYS_LOCKS table.

 Releasing lock: Delete record from PR_SYS_LOCKS table.

PR_SYS-LOCKS table = SYSTEM-LOCKS class

Lock idle time: 30 minutes

After that time release the lock and remove it from PR_SYS_LOCKS.

Two types of locking:

1, Default.

2, Optimistic (soft)

Default: Lock will be acquired when the “case is opened”.

Optimistic: lock will be acquired only when an “action is been taken on the case”.

Type of locking can be chosen under settings tab of case type.

Lock when:
 A case is opened. (Default)
 An action taken on case (optimistic).

 In default locking multiple operators can not open the case at the same time,
 In optimistic locking a case can be opened parallel by multiple operators. They can’t submit
at same time.
 Lock idle time is 30 min. after that time release the lock.

Obj-Open Obj-Open (Lock)

Lock Property-Set (Update clipboard)

Release on commit Obj-Save

Unlock, Commit.

 When we update or modify the data, we use Lock, other times we don’t use.
 After modify the data we have saved it by using Obj-Save or Commit. The data saved into
data base, after that only we release the lock by selecting Release on commit.

OOTB Properties and their

prefixes
pxCreateDateTime: holds the date & time value when the case is created.
pxUpdateDateTime: holds the date & time value when the case is updates.

pxCreateOperator: holds the operator ID of work object creator.

pxUpdateOperator: holds the operator D of work object latest update operator.

PyID: holds work object ID.

pzInsKey: holds primary key of instance. case or work object or any instance)

Prefixes:

PX: identifies the special properties, we can’t input the values from HTML form (section).

PY: not special, values can be input by user on HTML form (Section).

PZ: starts with PZ are to “support internal system processing”

 User can’t directly manipulate pz properties. Don’t change.

 Key properties.
 We can’t read, edit, delete.
Ex: PZINSKEY.

Work object is instance of class group.

 If we create a data class without any dedicated table (key column), these classes will be
mapped to “PR_OTHER”
 There won’t be any key for these classes.

Understanding pzInsKey
For LOOP
OBJ-OPEN-BY-HANDLE.
WORKING WITH OBJ-OPEN-BY-HANDLE.
DATA TRANSFORM
Data transform: it is like a property set.
We can assign the values to property.

Created under data model category.

We can assign

1. Single value to property. (Property)

2. Update source page to target page. (page)
3. Update source page list to target page list. (Page list)

We can perform these actions by using data transform.

1. Set: we can set the values to one property.

2. Remove: we can remove the property from clipboard.
3. Update page: we can update the data of one single page to another page for selected
properties. Target (paste)---------------Source (Copy)
4. Apply data transform: we can call another data transform.
5. Sort: it is for page list.
Page list will be sorted in order to the properties provided below, with the first
property given the highest priority.

Sort page list by properties ---------------- Order [Ascending, Descending]

6. Comment:
7. When: we can apply when conditions.
8. Otherwise when:
9. Otherwise:
10. Append to: copy the data from one page list to another page list of same class.
11. Append and map to: copy the data from one page list to another page list of different class.
12. For each page in: it is like a loop condition.
When you want to execute the same step again and again.
13. Exit for each page: when you want to exit the control from this.
14. Exit data transform: we can completely come out of data transform.

A data transform can be called from:

 Section (on click or on change of controls (buttons)).

 Data transform.
 Activity (using the method apply-data transform).
 Flow action (under action tab).
 Data page.

We can call the activity in DT, by using two functions 1. Call Activity

2.pxExecuteanActivity.

Differ load content:

When we select this option, whenever the section loads, we can call an activity in pre load
activity. Activity executes before the section loads.
PRPC provides an OOTB data transform “PYDEFAULT” which is called under process tab of
every flow.
This “PYDEFAULT” data transform is responsible setting values to properties, before actual
work object gets created.
When we run a flow, first “PYDEFAULT DT” will get executed and then case gets created.
In PYDEFAULT DT, we can set work ID prefix to the OOTB property. “PYworkIDprefix”.
Work ID prefix can be set at two places
1, Application rule form.
2, pyDefault data transform.

The order of assignment of pyWorkIDPrefix is

 pyWorkIDPrefix

Execute pyDefaultDTF
Set pyWorkIDPrefix = C-
Look up application rule form if Prefix is Defined or not
If Defined , Override pyWorkIDPrefix = Prefix Defined in datatransform.
Else
Do not override pyWorkIDPrefix = pyWorkIdPrefix

 This pyDefault DTF is available in OOTB classes and rule sets

Work-cover- and Pega-ProCom.

OOTB Rulesets are locked permanently.

 If we want to modify any OOTB rules, we have to Save as the rules with same ne into User
Defined rule sets and modify it.
 If a rule is available in OOTB and User Application rule sets, PRPC always picks the rule from
User Defiled rule set.

Steps to create DT: 1. Create data class with properties (Address)

2, create pages in work class (Billing address, shipping address)
3, check box (Boolean)
4, when condition (add check box above one)
5, data transform, flow action, flow.

Alternative rules for activity:

Activity (Obj-browse) ---------- Report definition.

Activity (Property-set)---------- Data transform.

Why data transform is best practice than activity?

Why activity should be avoided?

Pega is going to say activities to be avoided. Pega did not say avoid all activities.

Pega says user defined activities should be avoided. (You should avoid creating your own activities)

We can use pega OOTB activities. No problem with it.

Working with data transform

Q: when user selects a check box, copy billing address details into shipping address. Make shipping
address read only that time.

If check box is un selected make shipping address editable and empty.

Design:

 Create a when rule based on check box in impl class. For true value.
 Create a Data transform.
 Open check box and apply refresh condition and call DT.
 Make shipping address layout read only when bill and ship same.
 Create a case and test.

pyDefault Data Transform

C-10001
C ----- work ID prefix. 10001 ----------sequential numeric number.

We can set the work ID prefix from 2 steps.

 Application rule.
 pyDefault data transform.

C- is the default value to work ID prefix.

Application rule:

Application menu > Definition We can change here.

Cases & Data tab

Name work id prefix IMPL class

pyDefault Data Transform:

open any flow / case type.

Process tab

Data transform

pyDefault Open it (it will take into pyDefault DT)

Set pyWorkID Prefix “C-“

This data transform is used to assign (set) default values to properties. Here for work object ID.

 Change work id prefix for Vehicle insurance case type and Begin vehicle insurance flow.

When I add the flow here, it will come in the case manager > create menu > New.

 First pyDefault Data transform will gets executed, and it is going to set “py work id prefix”.
 Then application rule form will gets executed, in the application rule form it will check prefix
is mentioned, then set prefix to that value. (it will remove the default prefix value from DT).
 If not, it will take the default prefix value.

The order of the assignment of pyWorkID prefix is

 Execute pyDefault data transform. Set py work id prefix.

 Look up application rule form, if prefix is defined or not. If defined then override the prefix
which is defined in data transform.
 Else do not over ride pyWorkID Prefix.
 This pyDefault DT is available in OOTB classes and ruleset WORK-COVER- and PEGA-
PROCOM.
 OOTB rules are locked permanently.
 If we want to use OOTB rules, we can save as it into our ruleset and modify.
 If rule is available in booth OOTB and our ruleset, PRPC always picks our ruleset.

Working with pyDefault Data Transform.

Q: customize OOTB data transform py Default, to set work object ID prefix value.

Set the Work ID prefix to today date.

Design:
 Remove the prefix from application rule form. If we mentioned any.
 Open OOTB pyDefault data transform. [open any flow, process tab, open pyDefault].
 Save as this OOTB rule into our ruleset [IMPL] with same name.
 Open and change prefix from build an expression to get current date stamp.
 Create a case and test.

Validations
The purpose of validations is to check the property values to be expected, before we actually
process it.

To verify the data (property value) as expected or not.

Ex: Credit card, password.

In general, there are two types of validations.

1. Client-side validation.
2. Sever-side validation.

 Client-side validation: Before click on submit it works.

To write the validation HTML+ JAVA Script browser.

 Server-side validation: when we click on submit it works.

JAVA.
When we click on submit, request will go to application server, then response will be
received from server.

In pega we have 3 types of validations

1. Validate (server-side),
2. Edit validate (Client-side),
3. Constraints (Client-side).

Validations can be called from

1, Flow action (validation tab) (works on click of submit buttons).

2, Activity (Obj-Validate) post activity.

3, Validate rule.

Created under process category.

Validation is instance of Rule-Obj-Validate class.

Understanding validate rule

 Used to implement validation logic.
 It is an instance of class Rule-Obj-Validate.
 It can be created under process category.
 In a validate rule we can add no. of conditions for different properties.
 Validate rule can be called from flow action under validation tab.
 It gets executed on click of submit button. So, it is server side.
 Validate rule is specific to the flow action on which we call it. It will not work for all screens
(flow action) automatically.
 Validate rule can be called from validate rule, activity (Obj-Validate).
 When a validate rule is called on flow action, if validation fails, case will not move to next
step, instead it will be on same screen.
  Using Obj-Validate we can validate multiple properties.
 Open validate rule and click on any condition. Here we can see check box of continue
validation is by default selected.
 When we uncheck this check box, it acts like a break point.
 Validation happens up to that break point. After this is fixed, then validation proceed to next
break point and so on.
 For message we will create a message rule. Error category, and classification invalid inputs
(we can change).

Working with validate

Q: Validating customer form as below.
1, last name should not match first name.
2, Age should be between 18 and 65.
3, Zip code length must be 6 digits.
4, DOB should be past date.
Design: create---- Process---- Validate

 Create under fw class , org ruleset.

 Last name [first string relation second string].
 Age [first number relation second number].
 Zip code [expression evaluates to true]. Click on expression builder. Length(.zipcode)!=6.
 Date of birth [a date time is the past/future].
 Open customer details flow action. Call this validation.
 Create a case and test it.

Understanding Edit Validate

 Client-side validation.
 Instance of class Rule-Obj-Validate.
 Created under data model category.
 Single property. This edit validate is only applicable to specific property.
 This is useful when we want to apply the validation on single property many times.
 In edit validate we have to write the java code to define our validation logic.
 Even though we are writing the java code here, it is a client-side validation. We are
not directly executing the java code.
 AJAX rule is executing our java code.
 Ajax will execute in browser level. So, this is client-side validation.
 Edit validate can be called on property (advance tab), Activity (property-validate).
 In org class we don’t create edit validate.

Difference Between Rule Obj Validate and Rule Edit Validate

 Validate Edit Validate
We can write validation logic for multiple We can write validation logic only for one
properties. property
This is Service Side Validation This is client-side validation which executes java
code using Ajax Calling.

This validation is specific to one flow on which Validation happens at all different places
we call it. wherever we use property because validation is
applied on property.
We implement using OOTB functions We have to write Java Code

Working with Edit validate

Q: validate age based on below conditions.
1, if age is less than 18 = minors are not eligible.

2, if age is greater than 65 = senior citizens are not eligible.

Design:

 Use OOTB edit validate rule Is Non-Negative integer. Save as it to our ruleset, change name
and modify it.
 Open Age property. Go to advanced tab, mention our validate rule here.
 Open customer form, apply refresh condition on age. (change).
 Create a case and test it.

Difference Between Rule Edit Validate and Constraint

Constraint Edit Validate

Here, it’s a dependency validation, multiple We can write validation logic only for one
properties gets involved. property
This is Client Side Validation This is client side validation which executes java
code using Ajax Calling.

Validation happens at all different places Validation happens at all different places
wherever we use property. wherever we use property because validation is
applied on property.
We implement using OOTB functions We have to write Java Code
There in no need to call declare constraint, it This edit validate rule have to explicitly called
gets automatically executed where ever we use on property.
properties.

Declarative rules
  Declarative rules executed without calling.
 We don’t need to call these rules from anywhere. Just create the rules.
 Created under decision category.
 Instance of RULE-DECLARE-( ).
 Dependency validation.
 When we create a declarative rule, we will include properties in the definition.
 If any of the properties are been used or values gets updated, immediately declarative rule
gets executed.

Example: in constraints we add Age, Gender properties. In application anywhere we use Age, Gender
properties. If we change any value either Age or Gender, then Declarative rules will execute.

Types of Declarative Rules:

1. Declare constraint.
2. Declare Expression.
3. Declare on change.
4. Declare Trigger.
5. Declare index.
6. Data Pages. (Declare Pages).

There rules are instance of RULE-Declare-( ).

Working with Declare Constraint

Q: Validate Age based on Gender.

Design: create----Decision----Constraints.

 Create under org class.

 Gender = Male, Age > 21. Message “Male age should be 21 or more” to Age.
 Gender = Female, Age > 18. Message “Female age should be 18 or more” to Age.
 Create and leave. We don’t need to call this from anywhere.
 Create a case and test it.

Declare Expression
Created under decision category.
  While creating the declare expression, mention which property you are going to use as a
target property.
 ID:( ), Created with property name.
 Whenever source property value changes, then declare expression gets automatically called
and executed.
 This can be used to assign a target property based on source properties value changes.
 Whenever source property value changes, then automatically target property value changes.
 We will use the declare expression for calculation purpose.

Forward chaining: Whenever source property value changes then automatically target property
values changes. Whether you use the property or not in anywhere.

Backward Chaining:

Example: Amazon products.

Person 1 Person 2

1st Product RS:50/- 1 2

2nd Product RS: 100/- 1 3

Total amount = No. of 1st product * Cost of product 1 + No. of 2nd product * Cost of product 2.

Target prop Source properties

1 Person ------ 1*50 + 1*100 = 150/-

2 Person ------ 2*50 + 3*100 = 400/-

Working with Declare expression

Q: calculate Age based on Date of birth. Make age control read only
Design:
 Create declare expression in org.
 Mention age as a target property.
 Go down, click on add condition.
 If Date of birth = “ ”, set Age = value of, check notes for condition or google the
condition.
 Open customer details section, add refresh condition on date of birth. (Change) &
(refresh).
 Make age property read only (always).
 Create a case and test.

Working with UI, Data class,

Sections
Q: Create a new screen to capture transaction details. This screen has 3 different portions.

 Insurance Details,
 Agency Details,
 Policy Details.

Insurance Details: Properties 1. Insurance type (Dropdown).

a. Personal Vehicle,
b. Commercial Vehicle.

Agency Details: 1. Agency Code. (Text)

2, Agency Name. (Text)

Policy Details: 1. Policy Effective date. [Features Date]

2, Policy Term [Dropdown]. 1,2,3,4,5.

3, Policy Expiry Date.

Modify the case type by adding a new stage Transaction Derails.

Design:

 Create 3 Data classes in org, add fields.

 Open policy effective date and make it feature date in advanced tab.
 Create 3 pages, data class sections, work class sections, embed data class sections into work
class.
 Set properties to default values to create pages on clip board while loading the section. Do it
in flow action or data transform.
 Create a case and test.

If you have any doubts go with Sharath notes once.

Working with Declare Expression

Q: calculate policy expiry date based on policy term and policy effective date.

Policy expiry date should be read only (always).

Design: go to transaction details sec

 Make expiry date read only.

 Apply refresh condition on policy effective date, policy term (on change & refresh).
 Create declare expression in the respective data class (Policy).
 Select policy expiry date as a target property.
 Click on add condition below.
Policy Effective Date = “ “
Click on add condition +
Policy Term = “ “
Then set policy expiry date = values of “ ”
Set policy expiry date = value of (Click on build expression)

Add calendar +,
 @add calendar(.PolicyEffectiveDate,.PolicyTerm,0,0,-1,0,0,0)
Year, Months, weeks, days, hours, minutes, seconds.

These are the parameters that we have to pass.

We already passed year in insurance term. So add 6 parameters.
Days = -1. Because we need to show 365 days.

 Create a case and test it.

Declare on change
Declare on change: if the property value changes anywhere in the application, it will execute an
activity.

Activity type should be On Change.

Working with Declare on change, Data page lookup

Q: REVISE ONCE AGAIN
 Create a data storage for agency data class. Choose agency code as key column.
 Make changes to agency details as describes below.
 Change agency code control to be auto complete, populate agency codes with data taking
from agency data type.
 Whenever user enters agency code, auto prefills the respective agency name. The agency
name to be retrieved from agency data type.

Design:

 Create a data type. Agency. In records tab choose agency code as key column.
 Add records. Add some agency codes and agency names.
 Open agency details section, make agency name read only (always).
 Open agency code, change property type to auto complete.
 List source Data page (D_AgencyList). Data source property .AgencyCode.
 Apply refresh condition on agency code (Change & Refresh).
 Now in order to retrieve agency name from agency table, which is based on agency code.
 Let’s use Lookup, data page. This data page has got created while creating the data type.
 Data page: Agency.
 Data source, go to parameters below and check Param.AgencyCode created. This is
parameterized data page.
 Now create an activity (type: On change), which will call above data page and pass Param
value in case class.
(Property-set)

Primary.AgencyDetails.AgencyName =
D_Agency[AgencyCode:Primary.AgencyDetails.AgencyCode].AgencyName

 Create a declare on change rule under case class.

 Properties to watch = .AgencyDetails.AgencyCode
 Conditions, when, .AgencyDetails.AgencyCode!=” “
 When true run, activity, Mention our activity here.
  Create a case and test.

Decision Rules
Decision means, taking an appropriate action based on condition.

Decision rules evaluates conditions and returns required results.

When Condition returns true or false.

Using other decision rules, the return value can be anything.

We have below rule are decision rules.

1. When
2. Decision Table
3. Decision Tree
4. Map Value.
5. FORK (Which is not a rule – Can be used only for decision purpose in the flow using Decision
flow shape).

Decision table and decision tree both are used to apply the decision logic.

Decision Table: Rule which we use to evaluate the conditions. Conditions in table format. If the
condition is true, it will return the value, it will not evaluate the other values here. If the condition is
false it will go to next condition (else if), again it will validate, if the condition is true, it will return the
value or it will go to the next step.

If all conditions are not satisfied, then it will go to otherwise. We have to define some default value
in otherwise condition. Which will execute when all the conditions fail.

In decision table we can add columns and rows. In columns we can call the property. In that we can
define few more conditions.

Columns follows AND rule. i.e, all the conditions in that column must satisfy then only it return the
value.

Rows follow OR rule. i.e., anyone of the condition satisfy it will return the value.

In column if the property have 2 are more possible values, we can add it by Insert before and after.

We can import or export the values in the decision table.

When we click on any cell we can see the expression builder, with this we can call functions
(Complex logic).

Results tab.

Even though one of the conditions satisfied here, I want to execute all the conditions in the table. By
selecting Evaluates all rows we can do it. Anyone condition satisfy in the table; it will evaluate all
rows in the table.
 1. When (already worked)
2. Decision Table.
3. Decision Tree.
4. Map values.

By using decision rules, we can define conditions.

Decision Table:

Conditions Actions

pxObjClass Return
If
Else If
Else If
Other wise
Set Of Properties.

In decision table we can define only set of properties as a column, on that column only we can apply
the condition to evaluate.

Decision Tree:

We can apply the conditions on different properties in each condition.

Decision tab Configuration tab

Allow selection of “call decision” option.

By selecting this option, we can call decision table, decision tree, map values.

 Decision rules can be called from each other (DTABLE, DTREE).

 Decision rules can be called from Activity by using below methods.
1. Property-Map-Decision Table,
2. Property-Map-Decision Tree.
 Decision table, Decision Tree rules can be called from Decision shape of the flow shapes.

Map value:

Go to Harsha YouTube channel.

Decision rules can be called from

1. Decision rules. (We can call one rule from another rule).
2. Activity. (Property-Map-Decision Table, Property-Map-Decision Tree).
3. Flow. (Decision Flow shape).
The return statement decides whether to proceed forward or not return - means go to calling
rule.

Decision table, Decision tree when a condition is been satisfied, the rest of the condition will not
execute, because of return statement. (if true it will stop there and pass the value).

Decision Table:

Results tab

Evaluate all rows.

 If we select this, it will evaluate all rows. Because there is no return value.
 When we select this option ACTIONS will come.
 After actions tab, we can add another columns.
 But without selecting evaluate all rows, we can’t add columns after return.

 For example, when you select this option.

2nd, 5th row condition satisfied.

Q: what will be the final value for property 1,2,3?

Ans: value from 5th place.

 Evaluate all rows, means it is not going to return, instead it is going to do a property set.
 Decision table, Decision tree are alternate rules for activity. [Property-Set], Data transform.

Alternate rules for activity

1. Report definition: in place of Obj-Browse.
2. Data transform: in place of Property-Set.
3. Data Page: in place of constant and common shared data for certain period of time.
4. Decision Table & Decision Tree: as a conditional property-Set.

In activity you are calling a decision table, decision tree, if it is returning a result, you are capturing
that return value into property.

Property Name ------------Prop 1

Decision Table name-------DT1

This is also a property-set method based on condition.

Q: How to return multiple results by using Decision tree / Decision table?

Ans: By using evaluate all rows, we can do this. It is doing a property-set.

Working with decision tree, decision shape

Q: make changes to vehicle insurance case type flow path as described below.
 1. If insurance type is personal vehicle, then personal vehicle assignment should be displayed
to customer.
2. If insurance type is commercial vehicle, then commercial vehicle assignment should be
displayed to customer.

Design:

 Create a Decision tree in case type class.

.Insurance Details.Insurance type = “Personal vehicle” then return Personal.

Add one more condition.

.Insurance Details.Insurance type = “Commercial vehicle” then return Commercial.

 Open case type (Vehicle Insurance)

Open vehicle info flow from process----open process.
Add decision shape and make changes to path.

Start

Commercial Personal

Commercial Vehicle Exit Personal Vehicle

Previous Claims
End

 Open decision shape and enter decision tree.

 Open decision shape outward connectors and give the specific output in results tab.
 Create a case and test.

Working with Decision table, Property-Mao-Decision Table method in activity

Q: make changes to agency details screen as described below.
  At present agency name is getting auto prefilled being retrieved from a data type.
 Create a decision table which returns agency names, based on agency code.
 Agency name in the agency details screen should be a written value of the above
decision table instead of data type.
Design:

 Creating decision table in vehicle insurance (case class).

 Click on conditions to add the properties. Add agency code in conditions. Add return values.
 Add otherwise also.
 Now open activity which we called in declare on change. Comment on the step property-set.
 Add a new step property-map-decision table. Prop name: .agency details.agency name.
decision table: Agency DT.
 Create a case and test it.

Circumstance
Circumstance: creating a new variant of rule based on condition.

 Based on the situation the behaviour changes.

 Rule will be single, but multiple forms will be there.
 Original rule which we have is called as “base instance”.
 Rule which we created by circumstance is called as “Circumstance instance”.
 If we want to get more than one behaviour of a rule, then we go for circumstance.
(It is called as method overriding in java).
 We can circumstance a rule for “32” times.
 At run time if condition is met, circumstance variant rule will get displayed.
 If the condition is not met, then base variant will get displayed.

1. For property we can’t do circumstance.

2. For classes we can’t do circumstance.
3. For rulesets we can’t do circumstance.

Circumstance by:

 Template
Template Definition

 Property and date. (Single property circumstance).

Property value
 .Age 25
At run time PRPC will verify the condition. If the condition met then circumstance will get
executed. Else base rule will get executed.

Date Property start date End date

Date Qualifier if the date is in between these dates, then circumstance execute.

Single property circumstance: (Property & date)

 Only one property gets involved in the circumstance condition. Whereas date is optional.
 If the property and value met the condition, it will execute circumstance.
 Even though circumstance condition is met in property & value, if it is not met the condition
in date to fall in between the specified dates (Start and end), then base rule will get execute.
 Also, if the condition is not met only date is met, then base rule will execute.

Multi property circumstance: (Template)

 We can add multiple properties in the circumstance.

 We need to create a circumstance template rule under technical category, in this rule we
can add multiple properties.
 Then we need to create circumstance definition rule under technical category. we need to
mention the template in definition.
 It looks like decision table.
 But it will not return any value.
 Then we create circumstance and mention this template.
 When anyone of these condition gets satisfied, then circumstance rule will get executed.
Else base rule will gets executed.

Example for circumstance:

1. 49 recharge plan.
2. 199 recharge plan.
3. 220 recharge plan.
4. 50 recharge plan.
5. 12 recharge plan.

Circumstance is not an alternate for Decision tree. Both are different.

For template exercise go to Harsha notes.

Working with Circumstance

Q: Implement decision tree requirement using circumstance. When insurance type is
personal vehicle, then it will go to personal vehicle info assignment. If insurance type is
Commercial vehicle, then it has to go to commercial vehicle info assignment.
Design:
 Create a new version.
 Let’s implement this by circumstancing a section rule.
 Create a common rule by name “Auto details sec” include personal vehicle sec which
is a base rule now.
 Create a section “Auto details sec” in case class. Embed personal vehicle sec.
 Circumstance this rule by save as, property and date.
 Property: .Insurancedetails.InsuranceType. Value: Commercial vehicle.
 Remove personal vehicle sec and include commercial vehicle sec in circumstance
section.
 Create a flow action in vehicle insurance case class.
 Open the case and make changes.

Auto details Auto details FA

 Create a case and test.

 Once with personal vehicle.
 Once with commercial vehicle.

Flow action (Types)

Flow action: Flow action is container of a section.

By using flow action, we perform an action on UI (submit, save, cancel).

After submitting assignment, work object is going to move from one assignment to another
assignment in flow.
PRPC internally runs the activity, Finish assignment.

Finish Assignment: Is the OOTB activity which gets executed, when we click on submit button in the
screen (UI).

Two types of flow actions:

1. Connector action.
2. Local action.

When we create any flow action, by default it is used as a “Local and Connector”, we can see it in
Action tab of flow action.
  If you want to use it only as a connector action then you choose “connector action”.
 If you want to use it only as a local action, then you choose “local action”.

Local action: It allows user to perform the actions, when an action is been performed, WO will not
move to next assignment. Instead, it will be in the same current assignment.

Action will be done, but work object will not move to next assignment.

Example: add some files, attaching files, check details.

Click on this.

Files and documents. Click on gear icon. (Here there is no save button). We can attach files. When
we submit it, we are still at same assignment.

This is called local action.

Local action can be called from

1. Controls,
2. Assignment shape,
3. Flow,
4. Case management.

 Controls: on click of any control (Buttons, hyperlink, icon, any HTML control).
We can see local action only in that section.

 Flow: Design tab

When you call the local action from flow, it will be accessible from Action menu.
We can access the local action at any assignment shape throughout the flow.

 Assignment shape:
Open assignment shape (Ex: Customer details).
Go down
Advanced
> Local Action TEST
+ Add local action. (We can add more local actions).
When we run the flow, work object reaches to customer details, it will display TEST in
actions menu. After executing it, work object is still on the customer details assignment.

When we call local action on assignment shape, when the work object reaches that particular
assignment, the local action of the assignment will get displayed in the action menu of that
particular assignment. It won’t be accessible from any other assignment.

We can access the local action from particular assignment where we call it.

 Case management:

If we define local action in case level, pyDefault. It will be applicable for all flows in case.
 If we enter customer details data, then we want to modify the customer details in any section,
assignment, flow that section can be added in throughout the case. The local action will get
displayed in the action menu throughout the case.

So, we can modify the customer details throughout any section, if we define in case
management.

We can access the local action throughout the case.

 Local action can be accessible from Actions menu of

1. Assignment,
2. Flow,
3. Case Type (Case Management)

Working with Local actions

Q: Facilitate the business user to modify policy details when the case is at Auto details
assignment, they should be able to modify it.
Design:

Policy information section is already available in data class. There was a page in work class referring
to respective data class.

 Create a local action in case type class.

 Go to pages and classes tab, page name: Policy details. Class: Bajaj-Data-Policy.
 Layout tab,
page context: Use Clipboard page.
Page: Policy details.
Applies to: Bajaj-data-Policy.
Section: Transaction details_Policy details.
 Action tab
Indicator
Used as: Local Action.
 Call the local action on auto details assignment.
Open vehicle info process, open process.
Double click on auto details assignment (open)
Go down
Local Action: mention our local action here.
 Create a case and test it.
 Once work object goes to vehicle info, click on actions, you will get our local action here.
After changing the policy details, the work object is still at vehicle info.

Binary Files (Browse files)

 Browse------------Upload excel file.
In order to upload the particular file into PRPC server we have used a
control called “File Path”.
File path is a control which will give you a facility of browsing a
document (File).
Browse Upload excel file
 By adding our own button upload excel file, in that button we will call one activity to process
the upload.
 In this activity we will calling one OOTB activity pxPrseExcelFile.
 This activity opens the document and reads the content of file and place it on a clipboard on
a pagelist.
 In our own activity, we need to provide path of the file in the OOTB which we are calling.
FSFileName pxRequestor.pyFileUpload.
 This property holds a value of source path of where excel file is available.

We are doing two things here.

1. Clicking on a button, taking the excel file.

File will be placed in some path.
Path value will be assigned to pxRequestor.pyFileUpload property on a clipboard.
While clicking on a button, we will call one OOTB activity pxParseExcelFile.
This activity has ability to open a file, read the content of excel file, assign the content to
page list on a clipboard. We will provide the path with above property.

Data will come to a page list on a clipboard, I want to display in UI.

Q: How do I display?

Ans: copy from that particular page list to whatever the page list you are using in User Interface.

How to see the file path on a clipboard?

Clip board

+ System pages

+px Requestor (Code-Pega-Requestor)

pyFileUpload.

If you want to process an excel document in pega

 1. We need to remember one OOTB activity name. pxParseExcelFile.
In pega 7 it is MSO ParseRxcelFile.
2. pxParseExcelFile activity takes two parameters.
 Actual excel file which contains the data.
 The template excel file, which talks about which column value of the excel file to be assigned
to which property.
 Actual excel file we are submitting the path of the file.
 Template we are submitting to this activity by upload the template into binary file. We are
creating a binary file, upload the template, giving binary file rule name to the OOTB activity.

We are supplying excel file with content, excel file with template to pxParseExcelFile activity, taking
these two it will be able to get it on to clipboard.

Working with Binary file rule for excel, file path control, pxParseExcelFile
OOTB activity
Q: create a new screen to collect nominee details in a table format.
1. Nominee Name.
2. Date of birth.
3. Age
4. Relationship
5. Percentage (of assurance amount)
Facilitate the business user to upload the nominee details from an excel file. The upload
excel file data to be displayed in UI.
When working with excel file upload, we need to know about
1. Excel template- Columns, page list, properties.
2. Binary file rule- To upload the template.
3. User Interface- File path control.
Browse the document-- Copied to PRPC server-Folders- (Ex: static content/Global)
4. Clip Board- pxRequestor.pyFileUpload (Property).
5. Create activity- pxParseExcelFile – [what is the excel file which has data, excel file
with template].
6. Excel data file.
For this if you use wizard, when you create a case, by default it will show you one empty
column. To remove this column, go to pyDefault Data Transform (pySetFiledDefaults).
Remove Nominee list(1).pyLabel “ “.
Or
Create them by without wizard. So that you don’t get any default empty column.
Design:
First create UI form for nominee details
 Create a data type. (Nominee)
Properties:
1. Full name
2. Date of birth (Use already existing)
3. Age. (Use already existing)
4. Relationship (picklist-Dropdown-Local list-Father,Mother,Spouse)
5. Percentage. (Percentage)
 Create a page list (Nominee List) in FW, page ref Bajaj-Data-Nominee.
 Create a section, add controls, map the properties.
 Create a flow action.
 Add stage in case type. Add the flow action.
 Create an excel file with data. (Nominee Data)
(Take the above fields and create an excel with 3 records).
 Create an excel template. (Nominee Temp)
Ex: {.pxResults().Model Input} ---------- {} curling braces, page list().Property
{.pxResults().FullName Input}
{.pxResults().DateOfBirth Input}
{.pxResults().Age Input}
{.pxResults().Relationship Input}
{.pxResults().Percentage Input}
Template says about which column value to be given to which property in the page list.
Q: if you want to have only one row, do we need to take page or page list?
Ans: Page list. Because table works with page list.
 Now, create binary file rule with an extension of XLSX.
Created under Technical category. (IMPL Class).
Label: Nominees
App name: webwb
File type: XLSX

Upload file --- click on this

Click on Browse (Choose File). Choose the file nominee temp. upload the file.

Click on download file to test, to see if the file got uploaded or not. Open the file and
see it.

 Now create a section in case class.

Add label control. (Please click on browse button to select the file, click on upload)
 Add button control. Open the button and change the control from button to Filepath
(from others)
Property: pyFileName
Add a button control.
Open the button text: Upload Data.
Presentation: Strong Other: Primary swipe action.
Action tab
Click Refresh
Target: Section
Activity: Upload Nominee Excel (Create)

Refresh
Target: Other section
Section: NomineeDetails_Nomineelist
 Activity: Upload Nominee Excel
Pages & Classes

FileData Code-Pega-List
FileData.pxResults BAJAJ-DATA-Nomoinee
pxRequestor Code-Pega-Requestor
(to get the file path)

Steps
1. Page-New FileData
2. Call pxParseExcelFile FileData

FSFileName pxRequestor.pyFileUpload
Template RFB webwb!NomineesTemp!XLSX

Has header

Template RFB means ---- Binary File Rule Name

3. Property-Set FileData
Primary.NomineesList Filedata.pxResults
 Now open Nominee details section,
 Add dynamic layout, above to current section.
 Embed section: Upload Nominee Details Excel

 Create a case and test it.

User interface
Control, Guided tour, Harness, Navigation, Paragraph,
Portal, Section, Skin.
 * * *

Portal: Portal rule is an instance of class Data-Portal

DevStudio

Entire Browser = Portal

Portal will have top panel, bottom panel, left panel, right panel, work area.
Middle one is called as work area.

1. Top panel,
2. Bottom panel,
3. Right panel,
4. Left panel,
5. Work area (middle).

Portal gets loaded into the entire browser.

Portal will call “Harness”.

 Harness
Harness: Harness is container of section. (Like FA).

A harness rule is going to have a layout (screen layout).

 Harness defines the appearance and processing of the UI forms. (WO).

 Harness is called from portal.
 In harness we can call section.
 In section we call controls in layout.

Portal- Harness Section-LayoutControls.

 In harness we can call different layouts. (Screen Layouts).

You are given with requirement to create a section. After creating a section, we have two options to
embed the section

1. Flow Action.
2. Harness.

Q: which one out of these two you have to choose? How do you know?

Ans:

1. If the UI form should be displayed with submit, save, cancel buttons, when an assignment is
created.
 During the transaction model, when work object reaches an assignment, if we want to
display the UI with these buttons. Then we will create “Flow Action”.
 UI should be accessed as a optional screen with buttons as a local action.

2. Other than these everything is harness.

Harness can be called on any event of control. (HTML control).

Every screen that gets loaded in pega is harness. Work object loaded with in the harness.

The life cycle of work object has user interface forms, those forms are harness rules.

 Perform harness
When the work object reaches first assignment in flow, perform harness will execute.
(Editable).
Perform harness gets loaded on every assignment shape.
Perform harness loads Flow action + Buttons into it.

 “New” harness
(Editable)
Ex: (welcome screen) (Capture some data from customer).
Before the work object gets created in the transaction model pega is displaying one screen.
We can display (or) ignore it in work parties of flow.
 Work parties

pyDefault
We can include and edit.

Work parties

pyCaseManagement Default
We can ignore it.

 Confirm harness
(Read-only)

When there is no assignment to perform after completing all assignments, pega has
provided one screen. Confirm harness will display.

To display final confirmation messages in the transaction.

 Review harness
(Read only)
To display the forms in read only format, to review purpose.

pyCreate--- is a copy paste of perform harness. (From 8.5 version).

New:

 Creates the new work object.

 We can see it in process tab of the flow. (pyDefault).
 Before the work object gets created in the transaction model pega will display one screen.
 We can display it (or) ignore it.
 (Editable)

Perform:

 When assignment executes, perform harness executes.

 We can see it in every assignment shape of flow.
 It allows to process the work object.
 Loading flow action + buttons.
 (Editable).

Confirm:

 It displays the confirmation.

 If there is no assignment shape to perform after completing all assignments.
 Completing all the assignment.
 We can see it in process tab of the flow.
 (Read only).
Review:

 To display the forms in read-only format (Review purpose) after completing all the
assignments.
 (Read-only).

New: at the very beginning of the transaction model. [Editable].

(Welcome to amazon, warning messages, Terms & Conditions).

Perform: gets loaded at the assignment. [Editable].

Confirm: gets loaded at the end of transaction. End of all assignments. [Read-only].

Review: Access any time where you want. [Read-only].

Interview question:

ADD: OOTB activity.

 This activity is responsible for creating the work object.

 It is not only ADD activity, ADD activity calls another different activities within it.
Add work: Call ADD WORK (open it).
Add work will call another activity.
Generate ID: Call GENERATE ID.
This will generate the SNN. (Sequential numeric number), based on prefix.

OOTB activities responsible for creating the work object?

1. Add
2. Add work
3. Generate ID
4. Save New
5. Work commit.

These activities get executed when we click on Create button in the new harness.

Whenever we ignore to display new harness, still these activities will run.
 Perform Harness
Perform: Responsible for loading flow action, buttons.

 Work area has been loaded by an OOTB section. pyCaseActionArea.

 This section will load the flow action + buttons.
OOTB section for buttons, pyCaseActionAreaButtons.
 We can save as it and modify according to our business requirement.

How the flow action is getting loaded?

Ans: Open section pyCaseActionArea.

 When it is loading, it loads two sections.

1. Flow action HTML_simple,
2. pyCaseActionAreaButtons.

Open “Flow Action HTML_simple”

HTML tab

 Flow action gets loaded into PRPC by loading an OOTB section “Flow Action HTML_simple”.
Where it has HTML coding. This code is responsible for loading the connected flow action.
 Process commander is going to load a Non-Auto generated section.
If you go to Design tab, you don’t see any tabs to include.

Auto generated--- Sections that we are creating.

Non-Auto generated--- Sections that we are not creating, we can write HTML coding.

 Flow action gets loaded along with buttons into “Perform” harness.

Customizing OOTB UI – Confirm Harness

Q: Display entire work object data at the end of the transaction. This data should be displayed only at
the confirm harness.
Design:

 Create a section in IMPL class which contains all the sections of transaction.
[Total transaction data sec]
Don’t need to go full section editor. (see pdf once)
Include all the sections here. Data display----Embed section.
1. Customer Details Sec,
2. Address Sec,
3. Transaction Details Sec,
4. Auto Details Sec. (Because it is circumstanced),
5. Previous Claims Sec,
6. Nominees Sec.
  Create a case and go to last screen. (Resolved and completed).
Use live UI.
Open case information section. (Section in cell).

Case Information
This is an OOTB activity, save as and modify.
Save as into IMPL class. Because I want to include a section which is created in IMPL class.

Remove the inner layout (Delete the inner layout).

Embed the section. (Total transaction data sec).

 Add a visibility condition.

Open the section cell properties.
General tab.
Visibility: Condition (Expression).
Open build expression, .pyStatusWork = Resolved – Completed.

 Uncheck, Run the visibility condition on client.

(Uncheck to stop client-side execution)

 Create a case and test it.

 Add all the data and go to resolved and completed check the data.

Rule instances vs Data Instances

Rule instance: instance class name starting with Rule-
 Rule instances will have a Ruleset + Version.

Check-In & Check-Out buttons available.

Data Instance: Instance class name starting with Data-

 Data instances are non-versioned rules.

We can add Ruleset.
 No Check-In & Check-Out buttons available, because there is no versioning.

 Data instances are usually system level (Operator ID).

 We can directly modify data instances.
 We can’t trace data instances on tracer.
 There is no duplicate for data instances.
 Operator ID
Operator: Operator ID is the login ID, which we used in order to login into PRPC to access its
application.

Operator ID is the instance of class DATA-ADMIN-OPERTAOR.

If you do to test connection of operator ID class, it will display PR_Operators table name.

Operator ID are getting stored in the table PR_Operators.

Operator ID is the class key for this table. Search by Obj-Open method.

Operator details will be placed on clipboard under “System pages”

+ System pages

+ Operator ID (Data-Admin-Operator-ID)

What is the clipboard page that holds operator details?

Ans: Operator ID page.

PyUserIdentifier: This property holds Operator ID (User ID) Value.

Operator = Employee in the Org

PyUserName: This property holds operator name (User Name).

PyReports to: This property holds the reporting manager of this operator.

PyWorkGroup: This property holds to which work group this operator is belongs to.

If you open PyUserIdentifier

Operator ID: _____________

Work tab

Reports to

Reporting to which manager.

This value also assigned to clipboard

Every Operator will have access group, work group (Team), reporting manager.

Operator ID:

1. Full name
2. Email Address
3. Access Group
Work tab
4. Team (Work Group)
5. Reports to.

Access Group
How the PRPC knows about what is the application to be loaded and what is the portal to be
displayed?
Access group will provide access to application that operator can have. It also has portals, roles.

Access group acts as a interface between operator, application, portals, roles that operator can get.

Based on the access group of the operator, the process commander should be loading the
application.

For an operator who is having the access group of BajajAuto: Authors, it is going to load the
application of BajajAuto.

If you open the access group, this will be referring to application, Portals, roles.

Operator is connected to access group, Access group is connected to application, portals.

Portal should be loaded when operator login.

 If we want to change the portal, we have to login into application, open operator, open
access group, you can see the application and portal. We can change it here.
 We can select one portal by default.

There is a relation between operator, application and portals. This is been defined by access group.

Access group provides access to the application, portal and assigns the respective roles to the
operator.

PyAccessGroup: It holds the access group name.

An operator can have more than one access group. We can do it in Operator ID Profile Tab.

We have to select one by default access group.

If the operator has more than one access group, in the application menu we can switch application.

1. Bajaj Auto Insurance

2. HDFC Auto Insurance.
  Operator will have an access group.
 Access group is will have application, portals, roles.
 Application will have rulesets.
 Rulesets will have rules.
 Portal should be loaded when operator login.

Operator Access group applicationrulesetsrules.

Operator Access groupPortalsHarnessSectionControls

Operator Access GroupAccess RolesAccess roles to object Access level when privileges.

Access Group:

1. Application name, version,

2. Portal
3. Available Roles (Access Roles)
 Rule Resolution
It gives a clear-cut idea about how process commander is going to function internally.

(How the rules will get picked and processed by process commander).

Entire Pega will run on this algorithm.

Rule resolution: identify and pick the right rule that can be processed and presented to the
requestor.

Check Points:

1. Class Inheritance,
2. Ruleset Hierarchy,
3. Circumstance,
4. Rule Authorization, first always looks in the current class where execution begins
5. Rule Availability,
6. Rule Cache.

1. Class Inheritance: when a requestor requests the rule, PRPC looks at the current class first.
If the rule is not present in current class, then PRPC looks for the rule pattern parents, if the
rule is not found then it will go for direct parent.
HDFC-HDFCAuto-Work
HDFC-HDFCAuto
HDFC

HDFC-FW-HDFCIns-Work
HDFC-FW-HDFCIns
HDFC-FW
HDFC
Work-Cover-
Work-

@Baseclass

2. Ruleset Hierarchy: First it will check in the current application ruleset, if not found go
further. Parent/Built on application.

HDFCAuto: 01:01
HDFCAutoInt: 01:01
HDFC: 01:01
HDFCInt: 01:01

HDFCIns: 01:01
HDFCInsInt: 01:01
HDFC: 01:01
HDFCInt: 01:01
 3. Circumstance: we can have 2 instances with in single version, by using circumstance.

How does PRPC knows which rule has to be picked-up from the circumstance?

If the condition satisfies, circumstance rule will gets executed. If not base instance will gets
executed.

4. Rule authorization / Operator Authorization:

5. Rule Availability:

Available
Not Available
Withdrawn
Blocked
Final

Available: it will execute current rule of the highest version

Not Available: It will execute the below version of higher version (if the version is not available).

If the higher version is available then it will execute the higher

Withdrawn: higher version of current class is withdrawn, PRPC ignores all the lower versions of that
same class.

Then it will pick from pattern parent, if not found it will go to direct parent till base class.

Blocked: PRPC will stop processing the rule

 No rule will execute with that name in all versions. HDFCVehi--HDFC-FW

 It will not execute that rule.
Final: Highest version will be picked.

If we make it final any rule, we can’t modify it anymore. We can’t save as and modify it in
other versions.

6. Rule Cache: Temporary Memory.

Whenever you open (or) run any rule,
First that goes to rule cache. If the rule is not available in that rule cache, then PRPC will
search in 1,2,3,4,5 follows this pattern.
 Assignment Shape Routing
Assignment = Task (Work Item) 1. Calling Flow action

Task will be assigned to operator. 2. Routing

Routing----------- Assigning Task

Routing: Assigning the work to someone (Operator) or a common bucket (Every operator in that
group can access)

Route to:

1. Current Operator
2. Operator
3. Work Queue
4. Custom
5. Use business logic.

1, Current Operator: The person who executed the previous assignment and who is currently
working on this assignment.

Create Operator: Who initiated the work object.

2, Operator: Single Operator (Only he can access)

3, Work Queue (Work Basket):

It is a common bucket where everybody in that group can access the task (work item).

But only one person at a time can open the task. Then that will be locked by default locking.

4, Custom:

Assignment type:

Route to:

5, Business Logic:

 We need to add one decision tree that will decide for whom to assign.
 Written values of decision tree will be either Operator ID or Work Queue.

Business analyst will decide this.

 WORK LIST, WORK QUEUE (BASKET)
We can see work items in My Work.

Work list: list of work items which are assigned to the individual operator.

We can see it by login into operator-case manager- my work

Work queue (work basket): it is a common bucket where everybody in that group can access the list
of work items.

We can see it in Case manager- Dash Board - work queue

 When assignment is routed to single operator, that will be available in work list.
How?
In order to perform routing PRPC internally runs OOTB activity.
Activity

TO WORK LIST
Activity Type

ROUTE

 When assignment is routed to work queue, that will be available in work queue.
How?
In order to perform routing PRPC internally runs OOTB activity.
Activity

TO WORK BASKET
Activity Type

ROUTE

When the work object created, it will get stored into table in the back ground work table.

When the work object reaches assignment shape, assignment gets created, when it created that
should be stored into either PC_ASSIGN_WORKLIST or PC_ASSIGN_WORKBASKET tables.

Servers > Local host > Data base > Postgres > Schemas > Data > Tables >

For assignment there are two instance classes available.

1. Assign-Worklist
2. Assign-Workbasket.

When operator perform the assignment and click on submit then PRPC internally runs one OOTB
activity, to complete the assignment.

FINISH ASSIGNEMNT
Once the assignment is get completed, the record that is been inserted in the work list (or) work
basket will be removed.

 When assignment is routed to single operator, assignment will be accessible from portal,
My work
My work is the place which will have the task assigned to me.
Work list
OOTB internal activity to perform routing TO WORK LIST.
PC_Assign_WorkList
PxAssignedOperatorID: To which operator this particular assignment is routed to.

 When the assignment is routed to work queue, assignment will be accessible from Operator
Case manager -Dash Board - Work queue.
Click on your work queue to see the assignments.

Every operator in that group will get access to work queue (work basket).

If we are going to route the assignment to particular work queue, all the operators in that
work group which is connected to this work basket can access to Work basket and its items.

An operator can be part of more than one team.

Team should have manager.
We will have operators; operators will be divided into teams. TEAM = WORK GROUP.
Team will be connected to work basket.
We can add operator to work group from work tab of the operator.
We can give more than one work basket to operator.

Work group: Group of people working together.

(Team)

Work Basket: it is the place where the task will be available.

Relation between Operator ID, Work Group, Work Basket.

  First, we create work group,
 Then we create work queue,
 Refer the work queue from work group,
 Refer the work group from work queue,
 Then create operator ID,
 Refer the work group in operator.

Relation between work table and work list / work basket table
There are few columns to understand.

pxAssignedOperatorID: To which operator this particular assignment is routed to

 When operator login, go to my work. Here the list of assignments that are been assigned to
the operator are getting displayed.
 These records are being fetched from work list table.
 When operator login, click on My work, PRPC loads a Report Definition.
 This report definition will fetch urgency, Due, ID, Description, Category, Owner.
 Login operator ID matches with pxAssignedOperatorID, then it will fetch the assignments.

OperatorID.pyUserIdentifier = pxAssignedOperatorID

Work object is there in work table, the related assignments of work objects are there in work list /
Work Basket table.

How can we say that this particular assignment is related to which work object?

For this there is a relation column.

 Work object ID value will be there in work table PYID.

 Work object ID value will be there in assignment table, Work list/Work basket
pxRefObjectInsName.
Then matching records will be retrieved.

PyID = pxRefObjectInsName.
Then matching records will be retrieved.
 pzInsKey = pxRefObjectKey. this matching columns records will fetch.

pzInsKey = pxRefObjectInsName

When the assignment is created before it gets stored into table [PC_ASSIGN_WORKLIST],
[PC_ASSIGN_WORKBASKET], its data should be there on clipboard, on system created page.

NewAssignPage (Assign-Worklist)
(Assign-WorkBasket)
 Create Operator ID, Access Group
Q:
1. Create 10 operator ID with managers access group.
2. This 10 operator ID should have a valid email address.
3. Create a manager access group with managers role. The above operators should
have this access group.
4. Assign the reporting manager, Manager 1 to the developer operator ID. (Dev IMPL).
5. Create three user operators with user access group. Each of this operator reporting
to manager 1, manager 2 and manager 3 respectively.

Design:

Create manager access group with manager access role.

 Open current operator of the application,

 Open the developer access group, save as [Bajaj Managers]. Name: [BajajAuto: Managers].

Create 10 manager operator ID with manager access group.

 Open current operator of the application,

 Save as, [Bajajmanager 1] [Bajajmanager 1],
 Choose access group as managers, [BajajAuto: Managers], application: [BajajAuto:01:01:01].
 Full name: [Manager 1],
 Email: Vinodparuchuri1994@gmail.com
 Save.

Create 9 more operators, Manager2, Manager3,4,5,6,7,8,9, Manager 10.

Create 3 user operator ID’s

 Default user access group is already available.

 Save as, [Bajajuser1], [Bajajuser1],
 Access group: [BajajAuto: Users], application: [BajajAuto:01:01:01],
 Full name: [User1].
 Email: Not mandatory.
 Work tab: Reports to

Bajajmanager1
 Save.
 Create Bajajuser2 by following above process and choose reports to BajajManager2.
 Create Bajajuser3 by following above process and choose reports to BajajManager3.

Open developer operator and add a reporting manager [Bajajmanager 4].

Save
Done

Approve/Reject step, Alternate Stage

When there are exceptional things are available, to handle that exceptional things we will use
alternate stage.

The above stages are primary stages.

Below stage is alternate stage.

When we use approve/reject step, then automatically alternate stage will come in down side of the
case.

Alternate stage: A secondary path of case process.

Ex: in insurance policy,

If the vehicle cost is below 20,00,000. It will be processed in primary stage.

If the vehicle cost is more than 20,00,000. It will be processed to alternate stage. Here additional
processing is required.

It is not mandatory to have the alternate stage in case. But the advantage is it will divide into
properly.

Approve/Reject: if we add this step in any stage of the primary path, then automatically it will add
approval rejection alternate stage automatically.

We can customize it to add more properties.

Add approve/reject step and see the different options that we have in the right panel. Also, we can
route to based on our requirement.

Working with Routing to

Single Operator
Q:

1. Route customer search assignment to user 1.

2. Add an optional stage in the case type before case close.
Add an approval step in this stage and it should be routed to reporting manager of current
operator.

Design: Modify the case type to add approval stage.

 Open case type,

1. Route first assignment (Customer Search) to User 1.
Route to

Specific user
User Name
Bajajuser1

2. Add a new stage before case close.

Add approval / Reject step.
Then automatically alternate stage gets added.
Route the reporting manager approval to Reporting manager

Save

Done

Create a case and test.

Login with User 1 in another portal (Chrome) and search, task assigned to user 1.
Login with user1
Task assigned to user 1

Go back to developer.

Click on go.

Enter all the details up to nominee details, when we click on submit. You will come to approval
screen.

Approval assignment got routed to manager4

Login with manager4

Open assignment
Write something in notes and click on approve.

Done.

Creating Operators, access

group,
work group and work Queue
Q: Creating operators, access group, work group, work queue (Basket).

1. Create an access group “Loss Inspection”.

This access group is same as default users access group.
2. Create a work group (Team), “Loss Inspection Team”.
3. Create a work queue (Basket), “Loss Inspection Work Queue”.
Refer the above queue into team, team into work queue.
4. Create 2 operators,
1. BajajLossOp1,
2. BajajLossOp2.

Having loss inspection access group, this operator should be part of loss inspection team.

Design:

Let’s create all this by save as the default rules.

 Create Access Group,

Open default access group (Users), save as to create new one.
Records--Security---- Access group.
 Open BajajAuto:Users
Save as to create new one.
Access Group Description: [Bajaj Loss Inspection]
Access Group Name: [BajajAuto: Loss Inspection]
Save.

 Create a work group

Open default work group, save as
Open any operator----go to work tab----Team (open it)
Open team, save as
Work Group Description: [Bajaj Loss Inspection Team]
Work Group Name: [Bajaj Loss Inspection Team]
Save.

 Create Work Queue (Basket)

From the above work group,
Click on edit icon from work queue, which open default.
Save as
Work Queue Description: [Bajaj Loss Inspection Work Queue]
Work Queue Name: [Bajaj Loss Inspection Work Queue]
Save.

 Refer the above work group into work queue and refer Work queue into work group.
 Create 2 operator ID under the team Loss Inspection, with Bajaj Loss Inspection Access
Group.
Open any operator ID.
Save as.
Bajaj Loss Operator 1.
BajajLossOperator1
Full name: Loss Operator 1
Access group: [Bajaj Auto: Loss Inspection]. Application: [BajajAuto:01:01:01]
Work tab.
Team

Bajaj Loss Inspection Team

Save.

Create one more operator

Bajaj Loss Operator 2.
BajajLossOperator2
Full name: Loss Operator 2
Access group: [Bajaj Auto: Loss Inspection]. Application: [BajajAuto: 01:01:01]
Work tab.
Team

Bajaj Loss Inspection Team

Save.
Done.

Service level agreement (SLA)

SLA: It defines the time line within which a task/assignment must be complted.

SLA also defines the urgency (Priority).

We can create SLA under process category. Create----Process-----SLA.

SLA Defines, 3 Time Intervals.

1. Goal Time
 2. Dead Line Time
3. Pass Deadline Time.

We can call the SLA from

1. Step level / Assignment.

2. Process level / Flow level. (Process tab).
3. Stage level.
4. Case level.

Step level: if we define SLA in step level/assignment level, then this SLA is for particular
step/assignment.

Process level/Flow level: All the steps must be completed within the SLA.

Stage level: all the processes in that stage level must be completed within the SLA.

Case level: all the work in that case must be completed within the SLA.

For case types we can define SLA in Goal & Dead line tab. We can define our SLA from Custom SLA,
and also we can use existing SLA.

For Flow, we need to create SLA from process category.

When the assignment is created, we can implement the SLA from 3 different types.

1. Immediately.
2. Dynamically defined on a property. (Dynamic SLA).
3. Time delay. (Static SLA).

GOAL and Deadline times gets calculated the same moment once the SAL is active.

Goal time must be less than Dead line time.

Passed line starts calculating the moment deadline is completed.

How SLA times gets calculated?

For example, SLA Times are as below

Goal = 1 hour

Dead line = 2 hours

Passed deadline = 3 hours.

For the above figures,

Let’s say assignment is created at 8 AM and SLA is active.

Goal Breach Time = 8 + 1 = 9 O Clock

Dead line Breach Time = 8 + 2 = 10 O’ clock

Passed Deadline Breach time = 10 + 3 = 1 PM

Only calculate using business days.

It will calculate only in working days.

We can define working days.

Create-----Organization----------Calendar. (or) Records--Organization-----Calendar.

Passed deadline:

Limit passed deadline events to

After deadline reaches to here, then how many times this passed deadline should execute.

Ex:

Limit passed deadline events to

3

Days Hrs Mins Secs

3
Means 3 hours gap and execute 3 times with this time gap.

1. 10:30 am
2. 1:30 pm
3. 4:30 pm
Urgency: “0-100”.

We can define below urgencies.

1. Default Urgency : This is can assigned using pyDefault Data Tansform to an OOTB property
pxUrgencyWorkClass.

This value gets assigned, when is case is executed. Before case gets created it self this value
will be assigned.

2. Initial Urgency
3. Goal Urgency
4. Dead line Urgency
5. Passed Dead line Urgency

Initial, Goal, Deadline and Passed deadline urgencies can be mentioned in SLA Rule Form.

 Urgency is assigned to each and every assignment.

 Whenever the assignment is ready, by the time itself urgency will calculate if we select
immediately in assignment is ready.
 After assignment is ready by default urgency is “10”.
 If the goal time reaches, urgency will increase. If the deadline time reaches, urgency will
increase.
 Based on the urgency we have to work on the work items picked from work queue (basket).
 First, we have to work on higher urgency work item then come to lower urgency work item
respectively. (Highest emergency work item = Served first)
  The task with highest urgency value will get sorted to top of work list or work basket. That
means highest urgency task should be work on with first priority.
 Service level events is the agent which will calculate these urgencies in the background.

The calculation of Urgencies.

For example

Initial Urgency = 5, Goal Urgency = 15, Dead line Urgency = 20, Passed Dead line Urgency = 75

Let’s say the case is initiated.

Urgency Value = Default Urgency = 10

Once assignment is created, on which we have applied SAL.

Urgency Value = Default Urgency + Initial Urgency = 10 + 5 = 15

Once the goal is breached

Urgency = Default Urgency + Initial Urgency + Goal Urgency = 10+5+15 = 30

Once the dead line is breached

Urgency = Default Urgency + Initial Urgency + Goal Urgency + Deadline Urgency = 10+5+15 + 20= 50

Once the passed dead line is breached

Urgency = Default Urgency + Initial Urgency + Goal Urgency + Deadline Urgency + PSD Urgency =
10+5+15 + 20 + 75 = 100 (Rounds off to 100).

 SLA gets executed as a Back Ground Process.

 SLA will be invoked by an OOTB agent called Service Level Events which is in Pega-Pro Com
Agents category.
 SLA Queue table is PR_SYS_QUEUES_SLA.
 When SLA is created, A Queue Item will be sent to above table and the above agent
processes the SLA events in back ground.
Escalations in SLA:

We can define any of the above actions.

We can add more than one escalation at a given time interval.

At dead line and passed deadline the same type of escalations can be defined.

All these escalations gets executed in Back ground upload goal, deadline and passed deadline times
breaches.

Below are escalations

1. Apply Data Transform: Calling DTF

2. Run Activity: Calling Activity.
3. Call flow: Flow which is called will be executed.
4. Advance Flow:
5. Transfer: Assignment gets auto rerouted to work list or work queue accordingly.
6. Notify Assignee: Email will be sent to assigned operator.
7. Notify Manager: Email will be sent to reporting manager or current assignee.
8. Notify Party: Email will be sent to work party.

SLA Can be initiated

 Immediately.
 Dynamically define on a property,
 Time delay.

1. Once assignment is ready (Default): Once assignment is created SLA starts running.
2. Dynamically Defined by Property: We can use a Date time property, once this property value
is matching with current server time then SAL will get start running.
 3. Time Delay: We mention

Once the assignment is created and after the above number of days, SLA starts running.

How to define SLA Goal and Deadline time intervals by a Property Value?

We can define Goal and Deadline times being passed dynamically using a Date Time Property.
Once the above property value is matching with current server time that means goal is breached.

The advantage of defining goal and dead line by a property value is, Once SLA can be used for
different assignments with different goal and deadline times being defined dynamically.

SLAs cannot be applied on Screen Flows.

Working with SLA

Q: Apply an SLA and apply it on customer search assignment. When goal breaches assignment should
get automatically rerouted to manager 1.
Creating SLA to apply on customer search assignment

Design:

Creating SLA

Create ----- Process---SLA

For our practice.
Give initial urgency = 10.

Goal = 1 min,

Amount to increase urgency = 15

Define escalation: Transfer to bajajmanager1. (Work list).

Dead line = 2 min,

Amount to increase urgency = 55.

Passed deadline = 1min.

Amount to increase urgency = 50

But the final urgency will be 100 only.

Apply the SLA on customer search assignment [Step].

Open customer search assignment, go to goal and dead line, choose existing SLA [Our SLA].

Done.

Route the first step (Customer search to User 1).

Create a case and test it.

Login with user 1.

Don’t do anything just leave it.

Wait for one minute, refresh the screen. It will be disappeared from user 1.

Assignment got moved

It should get auto rerouted to manager1.

Login with bajajmanager1.

Escalation has happened.

Done.

Flow Types
1. Process Flow
2. Sub Flow
3. Screen Flow

 Process flow: starting flow of our transaction, which creates a work object.
 Sub Flow:
 Similar to process flow in all aspects.
 We can call this flow from another flow.
 Ex: flow A, Flow B. {flow B is called from flow A. then flow “B” is said to be sub flow.}

 Screen Flow: Screen flow can not create any work object.
 While creating a screen flow, from process------- flow.
 Click on view additional configuration options and select standard template for screen flow,
then click on create and open.
 If we go to process tab, we can see creates a new work object is disabled.
 In a screen flow, we can call the flow action from assignment shape.
 We can’t call the flow action from outward connector of assignment shape.
 For a screen flow, we can’t call more than one flow action.
 There is no routing for screen flow from assignment shape.
 Routing option for screen flow is available in start shape.
 Entire screen flow gets routed to either single operator (or) work queue. Where all the
assignments of screen flow can be worked by one operator (or) work queue.
 Harness option is available in start shape for screen flow. All the screens in screen flow will
have same appearance. (only one harness).

Working with screen flow

 In the existing case type, we have customer details, address details assignment.
 Transform these 2 steps into a screen flow and route to user 2.
 Create a new version.
Design:
 Create a new version and lock the existing version.
 Create a screen flow for customer details and address details.
Create-----Process-----------Flow.
In case class.
In case type multi-Step form = Screen Flow (we can select it like approve/reject).

Label: Customer Details SFL.

Choose * standard template for screen flows.
Create and open.
 Add one more assignment.
 Double click on each assignment and call the flow action from assignment.

 Open case type [Vehicle Insurance].

Open customer info process.
Remove two assignments and call screen flow by using sub process shape.
Start-----------Sub process----------end

Double click on sub process

Filter flow by, Screen flow.
Flow name: Customer details SFL.
 Let’s create address pages at pyDefault data transform.
To create pages in clipboard.
Open pyDefault Data transform from case type.
7, Set----.BillingAddress.LandMark----equals to ------ “ “
8, Set----.ShippingAddress.LandMark----equals to---- “ “

 Route the screen flow to user 2.

Double click on start shape of screen flow.
Route to: Operator
User name: Bajajuser2
 Create a case and test it.
After run the case type, see the below
Tab tab tab tab

Customer Address

 All the assignments will be displayed in one screen.

  Screen flow will have two assignments. (Customer details, address details).
 Instead of submit, we can see Continue.
 For the last assignment we can see Back and Finish.
 We can go back to previous assignment. (Customer details).
 By directly clicking on address details (tab), we can go to address assignment.

 Pega provides screen flow by default appearance as tabbed screen. This appearance will be
defined by harness.
Open start shape
Harness
Harness name: Tabbed screen flow 7.
 Based on the appearance of the screen flow assignments. Screen flows are categorized into
three types.
1. Tabbed screen flow.
2. Tree navigation screen flow.
3. Perform screen flow. (Similar to…

Once change the harness to tree navigation screen flow and create a case and test once.
Customer details

Address Details

Main points of screen flow:

1. Screen flow can’t create any work object.

2. In a screen flow, we will call flow action in assignment shape.
3. Screen flow routing option is available under start shape.
4. All assignments will get routed to single operator or work queue.
5. Harness option is available in start shape for screen flow.
All assignments will have same appearance.
6. Based on appearance of the UI, screen flows are classified into three types.
 Tabbed screen flow.
 Tree navigation screen flow.
 Perform screen flow.
7. We can go back from one assignment to another assignment. We can jump.