10. Explain Requestor Type in Pega.

What are the different types of Requestor types in

Pega?

A Data-Admin-Requestor instance defines a requestor type. The BROWSER requestor type,

for example, indicates characteristics of interactive user connections, such as guest
connections, utilizing Internet Explorer or another web browser. Agents employ the BATCH
requestor type for background processing.

Pega Platform comes with four requestor types for the system name we specify during
installation, as well as a reserved requestor type prpc.BROWSER for exceptional cases.
Typically, we only require the four requestor types that contain your system name. If we want
to modify the system name after installation, we go to Designer Studio => System =>
Settings => System Name to get to a landing page tab where we can do so. When we change
a system's name, new requestor instances are created that correspond to the previous name's
instances. If the prior system name did not include all requestor types for some reason, the
missing requestors are also produced when the system is renamed.

Following are the different requestor types in Pega:

 Application:This is used by listeners and external client systems to access the Pega
Platform, such as through a service request (other than JSR-168 requests using Rule-
Service-Portlet rules). Requestor IDs that begin with the letter A are used in requestor
sessions that use this requestor type instance.
  Batch: This is used by listeners, services, agents, and daemons all executing
background processing. The requestor ID for requestor sessions using this instance
begins with the letter B. All BATCH requestors have access to the PRPC:Agents
access group when it is first implemented. If you make a change to Data-Admin-
Requestor.BATCH so that it no longer has access to the PRPC:Agents access group
and subsequently upgrades the Pega Platform, the system may fail to start.
 Browser: This is used for accessing the Pega Platform portal via a web browser via
HTTP or HTTPS, or from a browser displaying a Pega composite application. The
requestor ID for requestor sessions utilising this instance begins with the letter H. All
BROWSER requestors have access to the PRPC:Unauthenticated access group when
it is first implemented.
 Portal: This is used in conjunction with Service Portlet rules, for HTTP access as a
portlet. The requestor ID for requestor sessions utilising this instance begins with the
letter P.

11. Explain about Access Groups and Access Roles. Differentiate between them.

Access Group :

Access Group is used to restrict access to our application’s functionality. To accomplish

varying levels of access control, we can create multiple access groups for the same
application.

An access group decides on the following:

 After logging in, users can access the portals.

 The roles, or privileges, that users have access to.
 Advanced parameters are applied to new rules, such as the default rule-set name and
version.

The Operator ID of a user is used to associate an access group with that user. When a user
logs in with more than one access group established, the application associated with the
principal access group is used. Privilege inheritance can also be used by security managers to
make the process of allowing the user access to a feature protected by privilege easier. The
Data-Admin-Operator-AccessGroup class defines access groups.

Access Roles :

Through the Access of Role to Object and Access Deny rule types, access roles determine the
classes that a user can see, alter, and delete.

To grant permissions (capabilities) to users, use an access role name. In requestor type and
access group instances, access roles can be mentioned. For a range of users, the Pega
Platform includes built-in access roles ( names that begin with PegaRULES: ):

 Guests
 Administrators
 Developers
 Authenticated work users
The Rule-Access-Role-Name rule type defines access roles.

Difference :

 Authorizations are granted according to a user's access group rather than their role.
The degree of authorization for the access group is determined by the most permissive
role in the access group.
 A list of Data-Admin-Operator-AccessGroup instances is displayed on the Access
Groups tab. The table shows the system's access groups and the number of operators
assigned to each group whereas for the present application, the Access Roles tab
displays a list of Rule-Access-Role-Name rules. You can examine, add, and remove
roles from this tab.

12. Explain Page-Validate and Property-Validate methods in the context of Pega. How
are they different from one another?

 Page-Validate: This method is used to check all of the properties on a page. If a page
has embedded pages, this method validates all of the attributes in a recursive manner.
This method is time-consuming and uses a lot of system resources. Use the Obj-
Validate method with the Rule-Obj-Validate rule to validate specified properties.
 Property-Validate: This method is used to set limits on the value of a property. To
implement constraints, use the Edit validate rule in conjunction with the Property-
Validate method. The Property-Validate method can be used to validate multiple
properties.

Discover your path to a Successful Tech Career for FREE!

Answer 4 simple questions & get a career plan tailored for you

Interview Process

CTC & Designation

Projects on the Job

Try It Out
 2 Lakh+ Roadmaps Created

13. How would you create a dynamic layout in Pega?

Following steps must be followed to create a dynamic layout in Pega :

1. Look for and open a Section form that already exists.

2. Expand the Structural list on the Design tab, then drag the Dynamic layout onto the
work area.
3. Click the View properties icon in the Dynamic layout header.
4. Set the layout format in the Properties window in either of the following ways:
1. Choose one of the predefined formats.
2. Select Other and then specify the custom layout format in the adjacent field to
use a skin-defined custom layout format.
5. Select when you want the Dynamic layout to appear in the Visibility field in either of
the following ways:
1. Choose one of the pre-defined options.
2. Select Condition (expression) and then the Open condition builder icon to
construct your own condition.
6. Submit the form.

14. Describe the different types of layout available in Pega.

Following are the different types of layout available in Pega:

  Screen Layout: Screen layouts are only used within a harness and are typically used
to establish portals for an application.
 Dynamic Layout: A dynamic layout is a DIV-based layout that allows content to be
displayed in a variety of ways.
 Column Layout: A Columns layout allows you to show major content, like a work
item, alongside supporting stuff, like an attachment.
 Grid Layout: Table layouts make it easier for users to obtain and compare data.
Tables can be used as a flexible base for users to process vast volumes of data in your
apps. Tables in price comparison software, for example, can assist customers in
quickly identifying the best deal.
 Tree Grid Layout: The properties in pages in an embedded Page List property can be
viewed, navigated, and accessed using a tree layout. To identify entries of current
interest, the user can swiftly extend and collapse branches of the tree.

In sections, dynamic layouts and column layouts are employed. In a dynamic or column
layout, you can add content to a section, such as properties, controls, and other sections. The
format of the skin determines the positioning, alignment, width, and arrangement of
components in a layout.

15. What are the different types of SLA? Explain them.

Following are the different types of SLA:

Assignment SLA: Assignment SLA is an SLA that refers to an assignment. This SLA begins
with the creation of the assignment and ends with the completion of the assignment. The
assignment urgency is set in the attribute pxUrgencyAssignSLA on the newly Assigned Page.

Case Level SLA: When an SLA is referred to at the case level, it is referred to as a Case
level SLA. This SLA is relevant throughout the lifecycle of a case. It begins when a case is
opened and concludes when the case is closed. The standard property pySLAName is used to
identify this SLA under the workpage. It's set in pyWorkPage's pxUrgencyWorkSLA
parameter. The pxUrgencyWorkSLA property under pyWorkPage controls the urgency of
case-level SLAs.

Stage Level SLA: When an SLA is referred to at the stage level, it is referred to as Stage
level SLA. It begins when a case enters a stage and ends when it exits the stage. The
pxUrgencyWorkStageSLA property under pyWorkPage controls the urgency at the Stage
level.

Step level/Flow level SLA: An SLA is considered a Step level or Flow level SLA when it is
referred to as a step or flow level. A step-level SLA begins when a process or step is initiated
and ends when it is completed. When a flow is begun, a flow level SLA is started, and when a
flow is stopped, it is stopped. If a step SLA is present, it takes precedence over a flow SLA.
Step SLA can be referenced in every step under the stage in the case type rule. The process
tab of the flow rule refers to a flow SLA. The pxUrgencyWorkStepSLA property under
pyWorkpage controls the flow or step level urgency.

16. What do you know about SLA in the context of Pega? What is its importance?

SLA is an acronym for Service Level Agreement. It is one of the most useful features of the
Pega CRM platform. As part of the case management process, Service Level Agreements
allow us to set targets and timelines. The major goal of SLA is to assist the task force in
completing all tasks on time. Pega Rules Process Commander will keep track of each SLA
rule's performance of a specific event action that was configured for that rule. By increasing
the urgency number, also adjusts the urgency associated with that assignment. This may draw
attention to the item on the employee's to-do list because it necessitates attention. So we can
sort the work-list based on the task's urgency.

A Service Level Agreement (SLA) establishes time intervals as a goal and time frame for
standardizing how you solve work in your application. It establishes a time limit for
completing the work. Pega establishes an SLA when we set a goal and a deadline. Service
levels can be set for processes, steps, stages, and entire classes.

There are four levels in SLA. They are as follows:

  Start: This is the point at which the service level timer starts ticking. It all starts at the
zeroth hour.
 Goal: Its purpose is to specify how long the assignments should take. This step is
counted from the start of the assignment or case.
 Deadline: The term "deadline" refers to the amount of time a case or process can take
before it is considered late. It is calculated from the start of the assignment or case.
 Passed Deadline: When the assignment or case has passed the deadline, the term
"passed deadline" is used to indicate when further action should be taken. It calculates
the amount of time that has elapsed since an assignment's deadline.

Following are the benefits of SLA :

 SLA ensures that your service provider and you are on the same page as far as
standards and services are concerned. Setting explicit and measurable rules is vital
since it reduces the possibility of client dissatisfaction and provides remedies if the
commitments are not met.
 SLAs mention recourse to be taken in case of service commitments failure. If your
service provider fails to meet their duties, it will have serious ramifications for your
company's reputation. As a result, if performance standards are not reached, we must
incorporate repercussions in the SLA.
 Your clients will have peace of mind with SLA. They have a contract that they may
refer to in order to hold their service provider accountable and to specify the type of
service they anticipate. They can lessen some of the consequences if the agreed-upon
conditions are not reached by receiving financial compensation from their supplier.

17. What do you understand about DCO in Pega? What are the benefits of DCO in the
context of Pega?

DCO stands for Direct Capture of Objectives. It is the process of acquiring, organising, and
storing data by using Pega's integrated solution, the Pega Platform. Processes and tools for
gathering and organising application artefacts are included in DCO. More crucially, IT,
business, and testing teams, as well as other resources, employ this enabling technology. It
saves time, effort, and money while also improving the quality of projects and people's lives.
DCO is not a methodology or a step in the methodology development process. It's not just
one tool. Instead, the goals and benefits are to centralise the data so that it may be used
continually across departments at the right time and at the right level. DCO eliminates
communication obstacles by providing a centralised repository for linked application artefacts
(objectives, requirements, specifications, and implementation rules). All resources have real-
time as-built documentation and a single view of the application.

The following tools are used by DCO to automate the work:

 Case Lifecycle Manager

 New Application Wizard
 Application profiler
 Document generation
 Effort Estimation
 Specification documents

Following are the benefits of DCO in Pega:

  DCO enables collaborative teams to model situations that must be addressed by the
application's end users. The modelling and simulation tools allow users to take a
critical interim step after documenting the application but before incurring the cost of
development to see if the software is meeting our objectives. When we can think
through and work out solutions as part of the software development life cycle, we are
less likely to be blindsided in production.
 Organizations can use DCO to improve their efforts and use iterative processes. Issues
and risks are not allowed to be discovered and mitigated at the conclusion of a
project; they are detected and mitigated in real-time. The software development
process is more visible, and it allows teams to learn and improve on a constant basis.
DCO technologies and best practices give organisations several ways to deliver go-
live, increasing their return on investment and allowing them to reliably accomplish
their objectives.

18. What do you mean by a work object in the context of Pega? How do you create a
work object in Pega?

A work object is the most basic unit of task completion in an application, as well as the most
basic collection of data on which a flow runs. Work objects are generated, updated, and
eventually closed when an application is used (resolved). A unique ID (property pyID), an
urgency value, and a status are all assigned to each work object (property pyStatusWork). A
work object is also known as a work item in some companies.

Work objects under specific application settings may have a traditional name from the pre-
automation era. Work objects in a help desk or service desk system, for example, are
frequently referred to as trouble tickets.

We can create a work object in Pega in the following steps :

  Create a button that looks like a section or a header.
 Click the action tab after expanding the cell property within the button.
 Add an action set to the button.
 The button should have a focus class and a flow name.
 With “Param.prevRecordkey,” we can get the current work object ID.
 Open the case with "Obj-Open-By-Handle."
 Copy the data from pagers with Page-Copy.

Also, a work object can be created from an activity. To create a workpage for the case type
we desire, we use the activity "createWorkPage." The data transform that will be used to
initialise properties might be specified. If it's a stand-alone work object, use "addWork," and
if it's a covered work object, use "addCoveredWork."
19. Explain about classes in Pega. What are the different types of classes available in
Pega?

The Pega Platform allows users to reuse rules across case types and applications. Developers
frequently reuse rules in their systems, ranging from single data pieces to complete processes.
Reusing rules increases the quality of an application while also cutting down on development
time. Pega Platform divides rules into classes based on their re-usability inside an application.
Each cluster is referred to as a class. Each application is made up of three different class
kinds.

 Work Class: Processes, data items, and user interfaces are all part of the Work class,
which provides the rules that govern how to process a case or cases.
 Integration Class: The Integration class holds the rules that specify how the
application interacts with other services, such as the integration resources that connect
it to a customer database or a third-party web server.
 Data Class: The rules that specify the data objects used in the application, such as a
customer data type or order items data type, are stored in the Data class.

When we add a rule in App Studio, it automatically selects the proper class. We can
concentrate on what we want the rule to accomplish rather than how to develop it. We can
write the rule in Dev Studio if you need control over the class. Switching to Dev Studio is a
good idea if we want to write a rule that we can reuse in another app.