SSA 716 StudentGuide 20150211

Senior System Architect
STUDENT GUIDE (v. 7.1)
Copyright 2015
Pegasystems Inc., Cambridge, MA
All rights reserved.
This document describes products and services of Pegasystems Inc. It may contain trade secrets and proprietary information.
The document and product are protected by copyright and distributed under licenses restricting their use, copying,
distribution, or transmittal in any form without prior written authorization of Pegasystems Inc.
This document is current as of the date of publication only. Changes in the document may be made from time to time at the
discretion of Pegasystems. This document remains the property of Pegasystems and must be returned to it upon request.
This document does not imply any commitment to offer or deliver the products or services provided.
This document may include references to Pegasystems product features that have not been licensed by your company. If you
have questions about whether a particular capability is included in your installation, please consult your Pegasystems service
consultant.
PegaRULES, Process Commander, SmartBPM and the Pegasystems logo are trademarks or registered trademarks of
Pegasystems Inc. All other product names, logos and symbols may be registered trademarks of their respective owners.
Although Pegasystems Inc. strives for accuracy in its publications, any publication may contain inaccuracies or typographical
errors. This document or Help System could contain technical inaccuracies or typographical errors. Changes are periodically
added to the information herein. Pegasystems Inc. may make improvements and/or changes in the information described
herein at any time.
This document is the property of:
Pegasystems Inc.
1 Rogers Street
Cambridge, MA 02142
Phone: (617) 374-9600
Fax: (617) 374-9620
www.pega.com
DocumentName:SSA_716_StudentGuide_20150211.pdf
Date: 20150211
Table of Contents
Orientation........................................................................................................
Completing the Exercises...................................................................................................
Application Design...........................................................................................
Starting an Application.......................................................................................................
Introduction to Rulesets.....................................................................................................
10
Working with Branches......................................................................................................
19
Rule Resolution....................................................................................................................
26
Enterprise Class Structure.docx........................................................................................
35
Circumstancing....................................................................................................................
42
Reuse and Specialization....................................................................................................
52
Case Design......................................................................................................
58
Case Management Under the Hood.................................................................................
59
Case Lifecycle Management..............................................................................................
67
Case Hierarchy.....................................................................................................................
75
Creating and Editing Flows.................................................................................................
90
Advanced Flow Processing.................................................................................................
100
Screen Flows........................................................................................................................
108
Work Status..........................................................................................................................
119
Work Parties.........................................................................................................................
125
Data Model.......................................................................................................
134
Building a Solid Foundation...............................................................................................
135
Controlling Data with Properties.......................................................................................
143
Source Your Data With Data Pages...................................................................................
151
User Experience...............................................................................................
164
Introduction to User Experience.......................................................................................
165
Introduction to UI Architecture.........................................................................................
175
Building the User Interface................................................................................................
188
Building Responsive User Interfaces................................................................................
202
Styling Applications.............................................................................................................
212
Understanding Available Controls....................................................................................
215
Dynamic User Interface......................................................................................................
226
Automating Business Policies.........................................................................
242
Data Transforms.................................................................................................................
243
Activities...............................................................................................................................
254
Pega Pulse............................................................................................................................
262
Case Attachments...............................................................................................................
265
Routing.................................................................................................................................
274
Get Next Work.....................................................................................................................
284
Correspondence..................................................................................................................
289
Tickets...................................................................................................................................
300
Declarative Processing.......................................................................................................
306
Declarative Rules.................................................................................................................
315
Delegating Rules to the Business User.............................................................................
326
Automating Decisioning.....................................................................................................
335
Validation.............................................................................................................................
348
Reporting..........................................................................................................
357
Creating Business User Reports........................................................................................
358
Configuring Reports............................................................................................................
369
Data Modeling in Reports..................................................................................................
383
Data Visualization using Charts.........................................................................................
392
Integration........................................................................................................
396
Introduction to Integration................................................................................................
397
Error Handling and Debugging..........................................................................................
406
Configuring a SOAP Connector.........................................................................................
417
Setup a SOAP Service..........................................................................................................
429
Setup a File Service and Listener.......................................................................................
444
Interacting with an External Database.............................................................................
462
Architecture......................................................................................................
471
Controlling Access to an Application................................................................................
477
Authentication Using LDAP................................................................................................
472
Administration..................................................................................................
489
System Debugging..............................................................................................................
490
Designing for Performance................................................................................................
511
System Tuning and Maintenance......................................................................................
529
Migrating an Application....................................................................................................
534
Module 01: Orientation
Thislessongroupincludesthefollowinglessons:
Welcome
CompletingtheExercises
Completing the Exercises

To learn software, we must use the software. Most lessons include a hands-on exercise that allows us to
practice what we just learned. By completing the guided exercises in this course we create an application
in PRPC.
The lessons include an exercise that provides a scenario which describes the business problem that
needs to be solved. To help you complete the exercises, three varying degrees of additional support is
provided beyond the business scenario and are listed below.
Scenario - describes the business problem we need to solve
Approach- specifies the high level steps you need to perform to solve the business problem
Hints - additional information as needed to assist with completing the exercise
Download Solution Link - Each exercise has a link to download a zip file. The zip file typically contains a
solution ruleset and an exercise design approach file. The solution ruleset is attached for your
reference so that you can compare your solution with the solution created by the lesson developer. The
Design Approach walks you through the solution for the exercise problem. It identifies what rules need to
be created and alternative design approaches if applicable for the exercise that might be considered. Be
sure to unzip the file before importing the solution ruleset into your PRPC application.
It is our goal that you can complete the exercises using the scenario and approach and relying on the
hints as needed. Use the solution only to cross check your work and not to complete the exercise.
Use the following log in credentials to complete every exercise in this course.
Username: admin@sae
Password: rules
The exercise application is called HRServices and has the Candidate selection and Onboarding
processes for new employees. Use the Case Designer as a starting point to familiarize yourself with the
processes.
The purpose of this application is to serve as the basis for the exercises. The application is incomplete
and contains components in draft mode. It was not built according to best practices and intentionally
contains design flaws that you will correct as you complete the exercises.
The exercise system has an open ruleset version for you to enter your rules. This is the default choice
when you save rules, and the name is HRServices: 01-01-05.
When you require modifying an existing rule, save a copy into HRServices: 01-01-05, this can be done by
using the Save As menu and then clicking Specialize by class or ruleset.
When working on the case designer, you will notice a message at the top to create a copy, click the copy
button to copy it into 01-01-05.
Loading the Exercise Solution

To load a solution:
1. Download the solution zip file.
2. Import the solution branch zip (Designer Studio > Application > Distribution > Import).
3. Add the solution branch to the application record using the Add Branch button. The name of the
branch is the same as the name of the solution file. For example, if the name of the solution file is
CaseLifeCycle.zip the name of the branch is CaseLifeCycle.
Module 02: Application Design
This lesson group includes the following lessons:
Starting a Pega 7 Application
Introduction to RuleSets
Working with Branches
Rule Resolution
Enterprise Class Structure
Circumstancing
Reusability and Specialization
Starting a Pega 7 Application

At the end of this lesson, you should be able to:
Describe the purpose of the Application Express
Decide on an appropriate Application Structure
Create an application
Extend an application
Use the Advanced Configuration
Add Case Types and Data Definitions
Describe the Purpose of the Application Express

Prior to Pega 7 there were two wizards available to create an application. There was the Application
Accelerator, which was used to create enterprise class applications, and the Application Express that was
used to quickly create a prototype application.
In Pega 7, the Application Accelerator has been retired and the Application Express has been enhanced
to support creation of enterprise class applications structures.
Some of you might ask yourself what happened to the Application Profiler. It has also been retired.
In Pega 7, DCO (Directly Capture Objectives) is available throughout the application lifecycle. Well learn
more about DCO in a separate lesson.
Lets have a look at the new Application Express. It can be found in the Application menu under New
Application.
It is a four step wizard used to create or extend an application or framework. The idea in Pega 7 is to
provide a simple wizard so that few decisions have to be made upfront, together with tools in the
Designer Studio, making it easy to extend the application structure once it has been generated.
Next well have a look at the application structure options.
Decide on Appropriate Application Structure

Before running Application Express it is important to understand the nature of the application to be
created to make sure an appropriate application structure gets generated.
We always need to specify an application on which to build. If we dont want to extend a specific
application or framework we select PegaRULES to build on the base PRPC.
All applications available on the system are shown in the dropdown, unless they have been configured
not to appear in the list.
This can be done on the Documentation tab on the application record by selecting Do not show this
application as a built-on choice in the Application Express.
The Implementation Only option was added in Pega 7 and gets used if we know from the very start that
there will be no need for reuse at the application level, in other words no need for several
implementations. We should always create a framework if we are not sure if our application will require
reuse at the application level.
We use the Framework Only option when we want to start off by creating a framework and later add
implementations using the Implementation Only options.
Or we can use the Framework and Implementation option if we want to create both the framework and
an implementation straight away. Additional implementations can be added later using the
Implementation Only option.
If we have a framework, start by configuring it. Make sure the framework runs on its own. If we have only
one implementation then build out the application in the framework and create an implementation that
contains no application logic but simply calls the framework.
If we have more than one implementation, then build out a default application in the framework and
customize it as required in the implementations.
Create an Application
Lets start by looking at how an application can be created using Application Express. As an example,
well show how the exercise application was created.
In the first step of Application Express essential application settings, such as application structure and
organization, are entered.
We recommend that the application name be fairly short. If the name is longer than 10 characters it
truncated to 8 characters.
If the name is truncated it is possible to change it. But the maximum length is limited to 14 characters.
The name of the exercise application is HRMS.
We dont want to build on a framework so we select PegaRULES for base PRPC. The exercise
application is not meant to be extended and will not require reuse at the application layer so we select
Implementation Only.
It is a best practice to keep the organization short. The organization gets truncated to four characters if it
is longer.
The truncated name can be updated, but is limited to 6 characters.
For the exercise application we want to create an organization called LP7.Were ready to move to step
two now.
The business objective for the exercise application is to provide a platform for the exercises.
In the third step we add the case types.
The case design is setup after the application structure has been created.
In step four we can add data types. A data type can either be created in the implementation or the
enterprise layer.
In the exercise application we want to add data types for employee and address to the enterprise reuse
layer.
Lets have a look at the rules and data instances to be generated using the preview.
The organization reuse layer contains the top level class and the base data class and the data types
added for the enterprise reuse layer as well as the organization integration class. Note that the trailing
dash for the Data and Int classes has been dropped in Pega 7.
6
The implementation layer looks almost the same but contains the application
and cases in addition. The Other section contains organizational data instances created to support the
application structure.
An organization with division and unit will be created and sample operators with access groups and roles
as well as a default work group and workbasket. Lets close the preview and create the application.
Extend an Application
In this section well look at how we can extend a framework or application. Use the Application Overview
landing page to explore and better understand the framework or application we want to extend. Examine
the case types and DCO assets, such as requirements and specifications. Also, run through the case
types to use in the implementation.
We want to extend the Purchase Application framework with implementations for each geographical
region.
We start off by creating an implementation for North America.
The built on application is the Purchase Application.
We only want to create an implementation so we select Implementation Only.
The organization is Pco.com
The business objectives from the built on application are shown. We can edit these to fit our
implementation.
Select case types to include in the implementation layer. New case types can easily be added when the
application structure has been created. Only top level case types and case types that can are available
for manual creation are shown in the list.
If we are extending an old framework with work types that inherits from Work- the Application Express
adds a case type rule. This provides partial case support with the main limitation being that the case cant
have subcases.
Select the data types we want to use in the implementation layer. Data types can easily be included after
the application structure has been created.
Lets have a look at the preview.
The Organization Reuse Layer is inherited from the built on application.
We can see that the case types were added to the implementation layer.
Click create to create the application.
Weve now seen how we can use Application Express to extend an existing application. Lets have a look
at the advanced configuration options.
Use the Advanced Configuration Options

The advanced configuration options provide us with more control of the rules created by the Application
Express.
It allows us to specify the name and version of the application record. By default the application name is
used for the record name and the version is set to 01.01.01.
We can specify the project methodology to use. This setting can easily be updated in the application
record after the application has been generated.
It is also possible to provide a framework name and version. By default the framework name is the
application name followed by FW and the version is 01.01.01.
In the class structure we can provide a name for the class group in addition to the application layer.
In the organizational settings we can specify a division and unit in addition to the organization.
Selecting Generate Reusable Division Records creates a division layer in the class structure.
If a reusable division layer is used a reusable unit layer can be introduced by selecting Generate
Reusable Unit Records.
The length of the class name is limited to four characters and is concatenated if its longer.
We select Generate Test Operators if we want sample operators. This option is selected by default.
Lets have a look at the preview.
We can see the division and unit layers.
Note that there are separate RuleSets for the division and unit layers.
Add Case Types and Data Definitions to an Application

Lets have a look at how we can add case types and data definitions to an existing application in Pega 7.
We start by looking at how a case type can be added.
Open the case explorer and select add a case type to add a new case type.
We want to create a case type called Payroll.
If the case type already exists we can Use Existing and select it.
The parent is the Onboarding case.
The advanced settings allow us to specify where the class derives from and the RuleSet and version in
which to create it.
It is also possible to specify if it is a remote case type and create a starting process for the case type.
The Payroll case was added as a subcase to Onboarding.
Lets have a look at how a data object can be added.
Select Add/Remove Data Objects. Deselecting a data type removes it from the data explorer.
Select View All to see all data types available.
Click Create New to add a data type.
We want to create a new data type that represents a dependent. The data type should be in the
enterprise layer so we make the ID LP7-Data-Dependent and the RuleSet LP7.
In the next screen we add the properties and select how we want them to appear. Review the properties
and click Finish to create the data type. We can see that the data type was added in the data explorer.
Wrap-Up
Thanks for attending the lesson on Starting a Pega 7 Application. I hope this lesson provided you with a
good understanding of the Application Express, which has been enhanced and replaces the Application
Accelerator in Pega 7.
The idea in Pega 7 was to provide a simple wizard that requires few decisions upfront in combination with
tools that makes it easy to manage the application once it has been created.
Inttroduction to R
Rulesets
A ruleset defines a majjor subset of rules, becaus
se all rules be
elong to a rule
eset. A rulese
et is a major a
aspect
ated rules, ma
anaging rules,, and moving applications. The term ruleset
in access control, grouping interrela
es informally refers
r
to the content
c
of the ruleset.
sometime
This lesso
on covers the fundamentals of rulesets and the main
n features and
d best practice
es.
At the end
d of this lesso
on, you should
d be able to:
Describe
D
a Ruleset
Utilize
U
the Che
eck-out feature
Explain Rulese
et prerequisite
es
Explain Rulese
et lists
Describe
D
Best Practices
Manage
M
Rules
sets
Describe a Rule
eset
A ruleset is a containerr or an organiizational cons
struct that is u
used to identiffy, store, and manage a se
et of
on. Every insttance of everyy rule type be
elongs
rules that define an application or a major part off an applicatio
et. A rulesets
s primary func
ction is to group rules toge
ether for deplo
oyment.
to a rulese
h references the applicatio
Operators
s receive acce
ess to an app
plication through an accesss group, which
on.
An applica
ation is comp
prised of a list of rulesets. The
T applicatio
on rulesets arre typically cre
eated by the N
New
Applicatio
on Wizard (als
so known as Application
A
Ex
xpress).
10
The purchasing application displayed here has an integration ruleset (SupplierIntegration) in addition to
the implementation and organizational rulesets.
Rulesets have versions. The version has a three-part key. For example 01-02-03, where:
01 is the major version number
02 is the minor version number
03 is the patch number
References to version numbers sometimes omit the patch number. A reference to version 03-07, for
example, means that all the versions between 03-07-01 and 03-07-99 are included.
A few rule types belong to a ruleset but not a ruleset version:
Application
Class
Ruleset and Ruleset Version
Access of Role to Object
Access Deny
Library
Utilize the Check-out and Private Edit Feature

Applications are typically developed by a team. The optional rule check-out facility supports an application
development team by allowing multiple members of the team to work on the same application in a
coordinated way.
Enable Check-out
Select Use check-out? on the Security tab on the ruleset to enable the check-out facility.
11
Operators need to have the Allow Rule Check out selected on the Security tab to be able to update
rules in rulesets that require check out.
Check-out
The check-out button appears when the ruleset the rule belongs to is unlocked, uses check-out and the
operator is allowed to check out rules.
If a developer checks out a rule no one else can check-out that rule and make changes to it until the
developer checks it in.
The check out button does not display if the rule is checked out by someone else. We can click the lock
icon to see who has checked out the rule.
If a rule is not available for check-out because it is checked out by someone else or because it is in a
locked ruleset version the private edit button appears instead of the check out button.
Private edit is a special case of the standard check out. It allows a developer to prototype or test changes
to a rule that is not available for standard check out.
To be able to do a private edit a developer needs to have the pxAllowPrivateCheckout privilege. The
standard access role PegaRULES:SysAdm4 provides this privilege.
When we check out a rule, we are making a private copy of the rule in our personal ruleset. Same is true
for private edits.
We can view our checkouts and private edits in the Private Explorer or by using the checkmark icon in the
header.
12
Use the Development

D
landing page (DesignerStu
udio > Applica
ation > Development > Checked Out Ru
ules)
to view all rules checke
ed-out in the application.
a
Private
P
edits a
are not shown
n in this list.
Check-in
Checking in a checked
d out rule repla
aces the original base rule
e. A commentt describing th
he changes to
o the
quired. The ch
heck-in comm
ments can be viewed
v
on the
e rules Historry tab. checkiin-comment.p
png
rule is req
Private ed
dits can also be
b checked in
n. We need to
o select an un
nlocked rulese
et version in w
which we wan
nt to
check-in the
t private ed
dit.
13
If we want to delete a check

c
out or private
p
edit we
e can use the
e discard buttton. The disca
ard button delletes
n our private ruleset.
r
the rule in
We can use the bulk ac
ction feature found in the Private
P
Explo rer menu or u
under the che
eckmark icon in the
en, or delete several checked out rules at the same time.
header to check-in, ope
hecked-in in bulk.
b
Note that Private edits cannot be ch
14
Explain Ruleset Prerequisites

A ruleset always requires at least one ruleset as a prerequisite. For example, an application ruleset might
have a division or organizational ruleset as a prerequisite. Here in our case the Purchasing application
ruleset depends on the ADV organizational ruleset.
Enforcing prerequisites during development helps ensure that rule references across rulesets are correct
during rule resolution at runtime. For example, assume that during development we create and test a rule
in ruleset Alpha:01-01-01 that depends upon a rule in ruleset Beta:01-01-01. If, at runtime in a production
system, a user executes the rule in Alpha:01-01-01 that references the rule in ruleset Beta:01-01-01, but
ruleset Beta:01-01-01 is not present on the production system (or is not in the users ruleset list), the
Alpha rule could fail or possibly run and produce an incorrect result.
Rule validation is performed against the prerequisites. When we save a rule, the system assembles a
complete required ruleset version list from:
All ruleset versions on this list
All ruleset versions listed as prerequisites for those ruleset versions
All lower-numbered ruleset versions of this ruleset and the rulesets included in the same major
version
Therefore, if you save a rule into Delta:01-01-01 which depends on Alpha:02-01-01, and Alpha:02-01-01
depends on Beta:02-01-01, only list Alpha:02-01-01 as a required ruleset for Delta:01-01-01. There's no
need to list Beta:02-01-01 because it is already listed in Alpha:02-01-01.
Note that rules in versions below the major version are not visible to rule resolution. For example, if you
list Alpha:02-01-01 that depends on Beta:02-01-01, Alpha:02-01-01 wont see rules in Beta:01-XX-XX.
If your ruleset only depends on the PRPC product enter the Pega-ProcessCommander ruleset as a
prerequisite.
There is a 99 patch version available of the Pega-ProcessCommander ruleset in the product. Use that
ruleset version as a prerequisite in your ruleset to avoid having to update the ruleset after product
updates.
15
The Pega-ProcessCommander ruleset lists all product rulesets so we dont need to list any product
rulesets below Pega-ProcessCommander.
The prerequisite information is also validated when importing rulesets. A ruleset can only be imported to a
target system that already contains the ruleset and versions that are listed in its prerequisites or if the
prerequisite rulesets are also contained in the import file.
Explain Ruleset Lists

While ruleset prerequisites govern rule development and import, the ruleset list governs rule execution at
runtime. Because ruleset prerequisites are enforced during development, the system does not need to
validate them during runtime processing
The ruleset list is the list of rulesets that are in play for a given operators session. The ruleset list is
available in the operator profile (Operator menu > Profile).
The order of the rulesets is important as it is used by the rule resolution algorithm. We generally refer to
the rulesets with higher precedence as being on top of those with lower precedence.
The list is assembled during login. The process starts by finding the versioned application rule referenced
on the access group of the operator. Note that in rare configurations the access group can actually come
from the requestor definition, organization or division record.
For most applications, the ruleset list is primarily comprised of rulesets referenced on the application form.
The built-on applications are recursively processed until the PegaRULES application is found.
The applications are then processed bottom up adding each applications ruleset list on top of the
previously added rulesets. As an example, if application A has two rulesets and is built on top of
application B which has two rulesets and which is built on top of PegaRULES ruleset. We will end up with
a ruleset stack with the rulesets of application A on top of those of application B on top of the Pega
rulesets.
There are a few situation when rulesets are added on top of the standard ruleset stack. If the application
has branches the corresponding rulesets will be added on top of the stack. Next, if there are production
rulesets defined on the application and the operators access group they will be added on top of the
16
stack.Finally, if the operator is allowed to check-out rules a personal ruleset is added at the very top of the
list. The personal ruleset has the name of the operator ID.
Explore Best Practices

A ruleset version can be locked preventing changes to rules in that ruleset. A ruleset is typically locked
when development is finished and the application is moved to the test environment.
It is best practice to never unlock a locked ruleset. If changes are required to a locked ruleset, create a
new patch version of the ruleset. That way consistency is ensured across environments.
Development should occur only in the highest version of a ruleset and only that version should be
unlocked. A ruleset version cannot be locked if any rules in that version are checked out.
The RuleSet Stack tab on the Application Structure landing page (DesignerStudio > Application >
Structure > RuleSet Stack) helps in following the best practices of ruleset locking and versioning.
We can use the Lock and Roll feature to lock and roll (increment) versions in a single step. Before using
the Lock and Roll we need to make sure that there arent any rules checked out.
17
If the last release built was promoted to testing or production it might be worth considering skipping a few
patch numbers reserving those for emergency fixes.
For example, consider the following situation. Ruleset version 01-02-04 was promoted to QA and then
production. The next release with a few new features is planned to go into production in two weeks. The
development of the next release is done in 01-02-10, reserving 01-02-05 to 01-02-09 for emergency fixes.
After the release went into production two defects were found. The decision was made to push the fix for
one defect immediately, but for the other some additional testing was required. The first defect was fixed
in 01-02-05 and the second one in 01-02-06. This is a snapshot of the environments after the first fix was
promoted to production and the second fix still being tested on QA.ruleset-version-diagram.png (needs to
be improved by production)
Manage Rulesets
There are several tools to help us manage rulesets and ruleset versions. The ruleset refactoring tools are
found under DesignerStudio > System > Tools > Refactor RuleSets.
Use the Copy/Merge Ruleset tool to copy rulesets and ruleset versions into new versions or to merge
several ruleset versions into one version.
The Delete a Ruleset tool allows us to delete an entire ruleset or a specific version of a ruleset. Consider
the effect before of deleting rulesets that has been promoted to production.
The Skim a Ruleset tool collects the highest version of every rule in the ruleset and copies them to a
new major or minor version of that ruleset on the same system, with patch version 01. Consider a skim for
each major application release.
Use the Rulebase Compare tool to identify differences in the rules on two different systems.
Conclusion
In this lesson, we looked at rulesets. A ruleset is a fundamental building block of an application. We
looked at their purpose and impact on the application as well as some features and best practices.
Now, you should understand what a ruleset is and how rulesets are configured. You should also know
how rulesets are used during development vs runtime. Finally, you should be able to enable and use the
checkout feature and utilize ruleset best practices.
18
Working with Branches

Welcome to the lesson on Working with Branches. For all but the smallest projects, development efforts
by multiple teams need to be managed. As teams achieve development milestones and are ready to add
their improvements to the main application rulesets, there is a chance that some of their changes to
existing rules may conflict with the changes other teams are making.
In this lesson well learn about the branch ability available to support parallel development efforts by
multiple development teams.
Identify when Branches are needed
Setup a Team
Create a Branch
Develop Rules with Branched Rulesets
Merge Branches
Explain Common Issues
Identify when Branches Are Needed

When a development organization has two or more teams working on rules in the same application
rulesets, changes performed by one team might result in conflicts with changes performed by another
team. By using branches, rule development can take place within an isolated space (the branch) without
affecting functionality in the source rules.
The branching ability is especially useful when teams need to work simultaneously on the same rules,
and all members on one team need to see each others work, while also isolating their development
changes from other teams. In this way, one teams rule changes do not affect the other teams until the
changes are stable, conflicts resolved, and approval is granted to make the new functions available to the
entire development organization.
For example, Team Alpha wants to work on an inventory selection feature and at the same time Team
Beta wants to work on a purchase order feature in the Purchasing application and both features involve
adding and editing rules in the same application rulesets. The teams day-to-day development activity is
largely independent. We do not know ahead of time which feature will go into production first.
With the features of branches and branch rulesets, each team creates their own branch in which to do the
work to implement their feature. When the work is done, the team resolves any conflicts that the system
detects between their branchs rules and other instances of the rules, and then merges their branchs
rules into the base application.
So lets see what we need to do in Pega 7 to make this work.
19
Setup a Team
First we need to create the team application which are built on the main application. The team application
is typically named in a way that reflects the base application, team name, or focus of the team.
For example, we could call the application Purchasing_TeamAlpha or Purchasing_InventorySelection.
The built on application and version needs to be updated to reference the main base application. The
include parent checkbox should be selected. We do not configure any application rulesets at this stage.
Create an access group that references the team application. The typical name of the access group uses
the application name plus the standard user type, in our case
Purchasing_InventorySelection:Administrators.
Update each team members operator ID to include the access group.
Create a Branch
The development branches are created using the Add Branch button on the Definition tab of the
application rule.
A branch name must start with a letter and contain only alphanumeric and dash characters, up to a
maximum of 16 characters. Best practice naming convention is to relate the branch name to the planned
development to be done in that branch. In this case well call it InventorySel.
20
The orderr of the branches listed mu

ust match the order in whicch the rules sh
hould be reso
olved for the
developerrs on the team
m. When a de
eveloper logs into this appl ication, the syystem assem
mbles the
developerrs ruleset list and adds the
e branch rules
sets on top off the ruleset sstack accordin
ng to the
sequence
e in which the branches are
e listed in this
s list.
Save the application re
ecords and cliick the Create
e Branch Rule
eset button to
o create a bra
anch ruleset. A
ched from a ru
uleset in the base
b
applicat ion, or any off its built-on applications. T
The
branch ruleset is branc
ds to determine which rule
esets contain the rules theyy expect to m
modify for a pla
anned
team need
enhancem
ment and crea
ate the branch
h rulesets bas
sed off those rulesets. In o
our case we w
want to branch
h the
Purchasin
ng ruleset.
Branch ru
ulesets are no
ot versioned. There
T
is only one ruleset vversion 01-01-01 and the ruleset it branches
from is listed as prereq
quisite.
The check
k out feature (on the Security tab) is ena
abled by defa
ault for branch
h rulesets since it is a bestt
practice to
o use check-o
out when doin
ng team deve
elopment.
We can use the Actions menu to de
elete a branch
h from the sysstem or removve it from the application.
om the system
m will delete all
a the rulesetss and rules be
elonging to th
he branch.
Deleting the branch fro
21
Develop Rules with Branched Rulesets

Team members can implement the planned features by performing rule development in the branches
using the branch rulesets. To update an existing rule, we do a save as of the base rule into the
associated branch ruleset and work on that copy.
As a team works with rules from the base ruleset in its branches, other teams are working on rules from
the base rulesets in their branches. If a rule has been changed in the base ruleset since it was copied to
the branch a conflict message appears as shown below.
If the rule is copied into two different branches a merge warning message appears since the rules will
need to be merged later.
To create a new rule that is needed to implement the enhancement, save it directly in the branch ruleset
that is branched from the base ruleset that will contain the new rules when development is complete.
22
Merge Branches
The branchs contents are usually merged into the base rulesets when the development in the branch is
complete and stable. Start the merge process by selecting merge from the Actions menu.
All rules in the branch rulesets need to be checked-in to complete the merge. It is a best practice to lock
the branch rulesets before merging the branch. Use the lock option in the actions menu to lock the branch
ruleset. We can use the package option if we want to move the branch to another environment.
Select Create New Version to create a new version of the base ruleset for the branch. Alternatively select
the ruleset version you want to merge into.
23
Click on th
he conflicts and warnings to
t open the notices window
w that displayys each rule that the wizard
d has
identified as having a conflict
c
or warrning.
If a rule in
n the branch ruleset
r
has be
een updated in the base ru
uleset a merge conflict is shown. It is no
ot
possible to complete a merge if such conflicts ex
xist. The brancch and base vversions of th
he rules need to be
m
before proceeding
g.
merged manually
More than
n one team might
m
have bra
anched the sa
ame rulesets a
and introduce
ed changes to
o rules that co
onflict
with each other. These
e types of con
nflicts show up
p as warningss, but do not p
prevent a merge. The team
m
p
sincce the base ru
hanged. How
wever,
merging their branch first can do so without any problems
ule has not ch
f
team has merged theirr changes the
e second team
m will get a co
onflict that mu
ust be resolve
ed
after the first
since the base rule was updated by the first team
m.
Click the compare
c
button to view the
e differences between the branch copy of the rule an
nd the one in the
base Rule
eSet. If the ch
hanges are minor open the
e branch rule a
e same chang
ges to it so that it
and apply the
matches the
t base rule.. If the change
es are more complex,
c
or iff they conflict with the logicc in the brancch
rule, conta
act the individ
dual who mod
dified the base
e rule and ne gotiate what the final set o
of changes sh
hould
be and the
e procedure for
f testing the
em.
When the
e changes to the
t branch rule are comple
eted and teste
ed, select con
nflict resolved
d merge this ru
ule.
Click OK when
w
all confflicts reported in the notices window are
e marked reso
olved and retu
urn to the Merge
Branch Rulesets wizard to continue with the merge process.
24
We have the option to keep all source and rules and rulesets after the merge. It is a best practice to
provide a password to lock the target ruleset after the merge. By default the branch and branch rulesets
are deleted after a successful merge.
Explain Common Issues

To reduce the chance of losing bug fixes, developers working on fixes need to check whether rules they
need to work on have already been modified in branches. As each service pack becomes available, the
service pack team should coordinate with the teams that are affected to resolve inconsistencies and
preserve bug fixes.
Data instances are not contained in rulesets, and cannot be versioned or filtered with ruleset lists. Teams
must communicate regularly to avoid creating conflicting data instances, in particular with the release of
Service Packages for new versions of services. Limiting create/update access for data instances
(organizations, work groups, workbaskets, access groups, and so on) to a single developer on each team
simplifies coordination between teams.
If branches share rulesets on the enterprise and divisional reuse layers any changes to those rulesets
need to be closely coordinated to ensure that it doesnt cause any issues with other applications using the
rules.
Conclusion
In this lesson, we looked at the branching feature that supports parallel development in a shared rule
base. This is a powerful feature that is often used for medium and large sized projects with several
development teams.
Now, you should understand how to setup applications and access groups for development teams. You
should also know how to develop with and merge branches. Finally, you should understand common
issues in parallel development and how to address them.
25
Rule Resolution
Welcome to the lesson on Rule Resolution. This lesson covers the Rule Resolution process, which is the
backbone of how the system ensures the correct rules are executed at the correct time.
Define Rule Resolution
State the Rule Resolution Process
Define Rule Resolution

So weve just seen what kinds of challenges face businesses today and some ways to address those
challenges. PRPCs best tool for addressing those challenges is its ability to use Rule Resolution. Rule
Resolution lets the system remain dynamic and flexible. Applications that have been designed using
Rule Resolution eliminate the need for developers to worry about building every possible scenario. By
leveraging Rule Resolution, these applications can adapt to the immediate scenario and determine the
next best action without any human intervention.
So what is Rule Resolution?

Rule Resolution is the process PRPC uses to determine the most appropriate rule to execute. Theres
two parts to Rule Resolution. First, it needs to eliminate all the rules that are just not applicable to the
current scenario. Next, it ranks the rules to determine which one is the most applicable.
Lets take a look under the hood of the Rule Resolution process.
State the Rule Resolution Process

Rule resolution follows 10 basic steps when determining which rule to use:
1. Check the rule cache. If the rule is present in the cache, go to Step 8.
2. Choose all instances with the correct purpose.
3. Discard rules where Availability is set to No/Draft.
4. Discard inapplicable rulesets and versions.
5. Discard all candidates not defined on a class in the ancestor tree.
6. Rank remaining candidates by:
a. Class
b. Ruleset
c.
Circumstance
d. Circumstance Date
e. Date/Time
Remove all candidates that are withdrawn or hidden by other withdrawn candidates. Select the first
default rule encountered and discard the candidates in the remainder of the list.
26
1. Set the cache.

2. Find the best instance (and check to make sure there is not a duplicate rule).
3. Check that the Availability is not set to BLOCKED.
4. Security Verify that the user is authorized to see the rule.
Lets take a closer look at each of these steps.
Step 1: Check the Rule Cache

During this step, the system checks to see if Rule Resolution has already been run for this rule. If it has,
the cache will have a list of all possible candidates for this rule. By using this list, the system can avoid
the need to query the database for rules every time they are executed.
It is not necessary to cover exactly how caches work at this time. There will be separate lessons that
describe the various caches in the system. However, it is important to note that that cache exists and is
used for this step. The keys for this cache are covered when we examine step 7.
If a list is found in the cache, the system uses the candidates from the list and proceeds to step 8, where
the list is evaluated. If it is not found, the system proceeds to build the list.
Example:
Lets walk through how the system finds the section CreateRequest shown below while performing a
PurchaseRequest:
[CreateRequestSection.png]
First the system checks the cache for a previous Rule Resolution of the Section rule CreateRequest that
used the same parameters as this current request. Since this is our first time running this rule, the rule is
not found in the cache so the system proceeds to the next step.
Step 2: Choose all instances with the correct purpose.

During this step, the system gathers a list of all rules that match the purpose. Though often used
interchangeably, the purpose is more than just the rule name. It is the combination of all keys to a rule,
except the class on which the rule is defined (known as the AppliesTo class). At a minimum, this will be
the Rule Type and the Rule Name, with additional keys as needed depending on the rule type.
Example:
The system needs to find all instances of a Rule-HTML-Section called CreateRequest. It doesnt do
any other filtering at this time, which still provides us a pretty lengthy list:
27
Class
Ruleset
Version
Availability
Qualifier
ADV-Purchasing-Work-PurchaseRequest
Purchasing
02-02-10
No
Purchasing
02-02-01
Yes
Purchasing
02-01-10
Withdrawn
Purchasing
02-01-05
Yes
Purchasing
02-01-01
Yes
Purchasing
01-01-01
Blocked
ADV-Purchasing-Work-PurchaseOrder
Purchasing
02-01-01
Yes
Purchasing
01-01-01
Yes
ADV-Purchasing-Work
Purchasing
02-01-07
No
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Circumstance)
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Date)
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
ADV-Purchasing-Work
Purchasing
02-01-01
Yes
ADV
Purchasing
01-01-01
Yes
ADV
ADV
03-01-01
Yes
ADV
ADV
02-10-01
Yes
Yes (Date)
ADV
ADV
02-10-01
Yes
ADV
ADV
02-01-01
Yes
ADV
ADV
01-01-01
Yes
XYZ-Quoting-Work-EnterQuote
Quoting
01-01-06
Yes
Quoting
01-01-01
No
XYZ-Quoting-Work
Quoting
01-01-01
Yes
XYZ
XYZ
01-01-01
Yes
Step 3: Discard rules where Availability = No/Draft.

During this step, the system filters the list of candidates and removes any rules where the Availability is
set to either No or Draft.
Availability is defined on a rule to control how this rule should be treated during Rule Resolution. An
availability of No or Draft indicates that this rule is not able to be executed and should not be
considered for Rule Resolution.
Example:
Continuing with our example above, there are only three candidates that have their Availability set to No
as indicated by the shaded lines below.
Class
RuleSet
Version
Availability
Qualifier
Purchasing
02-02-10
No
Purchasing
02-02-01
Yes
Purchasing
02-01-10
Withdrawn
Purchasing
02-01-05
Yes
Purchasing
02-01-01
Yes
Purchasing
01-01-01
Blocked
Purchasing
02-01-01
Yes
Purchasing
01-01-01
Yes
ADV-Purchasing-Work
Purchasing
02-01-07
No
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Circumstance)
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Date)
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
28
Class
RuleSet
Version
Availability
Qualifier
ADV-Purchasing-Work
Purchasing
02-01-01
Yes
ADV
Purchasing
01-01-01
Yes
ADV
ADV
03-01-01
Yes
ADV
ADV
02-10-01
Yes
Yes (Date)
ADV
ADV
02-10-01
Yes
ADV
ADV
02-01-01
Yes
ADV
ADV
01-01-01
Yes
Quoting
01-01-06
Yes
Quoting
01-01-01
No
XYZ-Quoting-Work
Quoting
01-01-01
Yes
XYZ
XYZ
01-01-01
Yes
These rules are removed from the list of candidates.
Step 4: Discard inapplicable Rulesets and Versions.

During this step, the system looks at the operators ruleset list (known as the Ruleset Stack). The Ruleset
Stack is covered in a different lesson. For this lesson, it is only important to know that the Ruleset Stack
defines the list of available rulesets for this operator and that the rules in those rulesets must have the
same Major version number and must be lower than or equal to the specified Minor version number.
Example:
In our example, our operators list is defined as:
Purchasing:02-01
ADV:03-01
This removes eleven candidates from our list:
Class
Ruleset
Version
Availability
Qualifier
Purchasing
02-02-01
Yes
Purchasing
02-01-10
Withdrawn
Purchasing
02-01-05
Yes
Purchasing
02-01-01
Yes
Purchasing
01-01-01
Blocked
Purchasing
02-01-01
Yes
Purchasing
01-01-01
Yes
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Circumstance)
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Date)
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
ADV-Purchasing-Work
Purchasing
02-01-01
Yes
ADV-Purchasing-Work
Purchasing
01-01-01
Yes
ADV
ADV
03-01-01
Yes
ADV
ADV
02-10-01
Yes
Yes (Date)
ADV
ADV
02-10-01
Yes
ADV
ADV
02-01-01
Yes
ADV
ADV
01-01-01
Yes
Quoting
02-01-06
Yes
XYZ-Quoting-Work
Quoting
02-01-01
Yes
XYZ
XYZ
02-01-01
Yes
29
The three candidates from XYZ and Quoting are removed because their rulesets are not defined in our
Ruleset Stack. This makes sense because they belong to a completely different application.
Within Purchasing, the three candidates from the 01-01-01 versions have been removed because they
dont match our current Major version of 02. The candidate from 02-02-01 matches the current Major
version, but is still removed since its Minor version of 02 is higher than our current Minor version of 01.
Within ADV, only one candidate matched our current Major version of 03. All the others have been
discarded.
Step 5: Discard all candidates not defined on a class in the ancestor tree.
The ancestor tree refers to a rules inheritance. Inheritance is defined in more detail in another lesson.
For this lesson, it is only important to remember that a class can inherit from other classes, which allows
for the reuse of rules.
This step is the first time that the system examines the AppliesTo class of the candidates. If the
AppliesTo class does not match the current class, or one of the current classes parents, then those
candidates are discarded.
Example:
In our example, we were currently executing a Purchase Request. There is only candidate that is not in
the ancestor tree of the Purchase Request:
Class
Ruleset
Version
Availability
Qualifier
Purchasing
02-01-10
Withdrawn
Purchasing
02-01-05
Yes
Purchasing
02-01-01
Yes
Purchasing
02-01-01
Yes
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Circumstance)
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Date)
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
ADV-Purchasing-Work
Purchasing
02-01-01
Yes
ADV
ADV
03-01-01
Yes
Therefore, the candidate defined on ADV-Purchasing-Work-PurchaseOrder gets removed from the list.
Step 6: Rank remaining candidates.

At this point, the system is trying to determine the order in which the candidates are the most correct. A
lot happens during the ranking step, three different sub steps actually occur.
1. First, the system sorts the candidates according to:
a. Class
b. Ruleset
c.
Circumstance
d. Circumstance Date
e. Date/Time Range
f.
Version
30
The first two ranks Class and Ruleset provide the basics of Rule Resolution. The closer the
candidate is to the class where it executes and the higher it is in the ruleset stack determine
which is the default rule.
The next three ranks Circumstance, Circumstance Date, and Date/Time Range are qualifiers
to those basics. They allow us to specialize even further to address all the possible outlier
cases. The exact details of these qualifiers and an in depth look at this portion of Rule
Resolution is covered in the Circumstancing lesson in this course.
Finally, the last rank Version ranks the candidates by the ruleset version that contains them.
This ensures that circumstanced rules are not automatically overridden if the base rule is
updated in a more recent ruleset version.
2. During the ranking process, the system evaluates any of the candidates that have their
Availability set to Withdrawn. Withdrawn is a special Availability that lets us skip over some
candidates. When a rule is marked as Withdrawn, it is removed from the list of candidates as
well as any additional candidates that match all of the following:
The same AppliesTo Class
The same Ruleset Name
The same Ruleset Major version
The same Purpose
The same Qualifiers
This is the definition of how to match a Withdrawn rule. However, during Rule Resolution, the
incompatible Major versions and Purposes have already been discarded in the preceding steps.
At this point, were only concerned with the rule being in the same class, in the same RuleSet and
having the same qualifiers.
3. The last thing the system does is determine the default candidate. A default candidate is the
first candidate (highest ranked) that has no qualifiers. This default candidate is the last possible
rule to be executed as it will always be a match to any additional requests for this rule. Additional
candidates ranked below this one are discarded.
Once these three steps of ranking are complete, the only candidates remaining will either have some kind
of qualifier and there will be a single non-qualified candidate.
Example:
Continuing our example, well first rank the results. Conveniently, our list is already in the correct order
that in which it was ranked.
Class
RuleSet
Version
Availability
Qualifier
Purchasing
02-01-10
Withdrawn
Purchasing
02-01-05
Yes
Purchasing
02-01-01
Yes
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Circumstance)
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Date)
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
ADV-Purchasing-Work
Purchasing
02-01-01
Yes
ADV
ADV
03-01-01
Yes
31
Next, we see that there is a Withdrawn candidate defined on ADV-Purchasing-Work-PurchaseRequest in

the Purchasing ruleset and there are no qualifiers. Well remove all candidates on that same Class and
ruleset that also have no qualifiers.
Class
RuleSet
Version
Availability
Qualifier
Purchasing
02-01-10
Withdrawn
Purchasing
02-01-05
Yes
Purchasing
02-01-01
Yes
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Circumstance)
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Date)
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
ADV-Purchasing-Work
Purchasing
02-01-01
Yes
ADV
ADV
03-01-01
Yes
Once those have been removed, we look for the first candidate that does not have any qualifiers. We find
that ADV-Purchasing-Work in the Purchasing ruleset, Version 02-01-05 meets this criteria, so the
remainder of the list is removed.
Class
RuleSet
Version
Availability
Qualifier
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Circumstance)
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Date)
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
ADV-Purchasing-Work
Purchasing
02-01-01
Yes
ADV
ADV
03-01-01
Yes
This leaves us with only three candidates, two that have a qualifier and the default candidate.
Step 7: Set the cache.

This list is then stored in the cache for future Rule Resolution requests to leverage (in Step 1). The
system caches all the possible qualified combinations in a single list in order to improve its reuse. If it
only stored the exact match, there would have to be a new cache for every possible scenario. This cache
is keyed by the Ruleset Stack and the class that was being executed.
Example:
In our example, the result is that all the candidates are from ADV-Purchasing-Work.
Class
RuleSet
Version
Availability
Qualifier
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Circumstance)
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Date)
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
However, since we were executing a Purchase Request, the key used when putting this list in the cache
is ADV-Purchasing-Work-PurchaseRequest.
Step 8: Find the best instance.

This is the final step that determines which candidate is the most likely one to be executed. Each of the
qualifiers is examined to see if there is a match. The system stops on the first match thats available or
the default if none of the qualifiers match. This allows us to use the qualifiers, such as Circumstance, to
specify the outlier processes while still maintaining a base default rule for the majority of cases.
32
Example:
In our example, we have three possible candidates that are evaluated.
Class
RuleSet
Version
Availability
Qualifier
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Circumstance)
First PRPC
evaluates if the
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
Yes (Date)
condition for the
Circumstance
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
was met. Lets
say the Circumstance was Supplier=Restricted. If the value of Supplier equals Restricted then the
system uses the first candidate. Our Supplier is set to Open so we dont match and the system moves
to the next evaluation.
Now it evaluates a DateTime range. If the range on the candidate is specified as Before June 1st, 2000
and were executing this rule now, we dont match the date range, so the system moves to the next
evaluation.
The candidate does not have any qualifiers, so the system automatically chooses this candidate. We
now know which rule to execute.
Step 9: Check that Availability does not show Blocked.

Even though the systems narrowed down the selection to a single rule, Rule Resolution doesnt stop
there. There are still a couple more things to do. The system is going to check to see if the Availability is
set to Blocked. Like the other Availability settings, Blocked is used to instruct the Rule Resolution
process. In this case, a candidate that is Blocked tells the system that the rule cannot be run. This is
different than the No Availability. Where No says Dont pick me, pick another rule, Blocked says
You have the right rule but I dont want you to run.
To summarize the Availability settings:
Yes = Im OK to be executed.
No = Im not OK to be executed, pick someone else.
Withdrawn = Im not OK to be executed and neither are any of my earlier versions. Pick
someone else.
Blocked = Im not OK to be executed, but do not pick anyone else. Just dont execute.
Example:
In our example, the chosen candidate has Availability set to Yes, so this rule is not blocked and is
available to run.
Class
Ruleset
Version
Availability
Qualifier
ADV-Purchasing-Work
Purchasing
02-01-05
Yes
If you remember, we did have a blocked rule in the original list of candidates, but that candidate was
discarded in Step 4.
Step 10: Security Verify that the user is authorized to see the rule.
The final piece of Rule Resolution is to check that the user has the correct authorization to execute the
rule. If the user does not have the correct authorization they are prevented from executing. The features
of security and how to configure them are covered in a different lesson in this course.
Example:
In our example, the user has the correct authorization, so the section displays.
33
Conclusion
The Rule Resolution process is backbone of the entire PRPC application. This process defines how the
system ensures the correct rules are being run at the correct time.
34
Enterprise Class Structure
Introduction
Welcome to the Enterprise Class Structure (ECS) lesson. In this lesson well learn how to plan our class
structure with designs for future growth and some best practices for achieving maximum reuse.
Define the Enterprise Class Structure
Describe Inheritance What makes the Enterprise Class Structure Work
Define the Enterprise Class Structure

So what is an ECS and why do I need one? This is one of the most important pieces of developing a
robust PRPC application. The Enterprise Class Structure is the backbone of reuse in our application.
The Recommended Enterprise Class Structure

PRPC generates an Enterprise Class Structure for us when we run the Application Express. Depending
on the settings we select, we might not have all of these layers shown below in our application.
The most common of these settings generates four layers in our ECS and they are the:
Organization Layer
Division Layer
Framework Layer
Implementation Layer
The Organization Layer

The organization layer exists at the very top of our enterprise class structure. This layer is intended to
hold all rules that apply corporate wide.
35
The kinds of rules most often encountered here are:
Security (for example, LDAP access, how users are granted rights, etc)
Corporate Logos and Skins
Corporate wide data models (for example, Customer, Insured, etc)
Some Integration Points (Note that these should only be placed here if they are used organization
wide. Access to a customer database is a good example of a potential organization wide
integration. However a list of automotive repair centers would not be a good idea as it is most
likely only applicable to a single line of business and would not be used organization wide.)
The Division Layer

The division layer exists to hold all the rules for a logical grouping within that business. Most often, this is
based on the line of business, but it is not restricted to that and instead could be regions, brands, or
departments. The key is to identify if these rules span across different processes within the business.
For example, an insurance company has several processes, Quoting, Underwriting, Claims, etc Each of
these processes would be handled by different departments, but across all of them, the definition of a
vehicle is the same. By placing this definition at the division layer for the Automotive Line of Business,
were providing for reuse across all the different applications that deal with vehicles.
Division wide data models (like the vehicle example)
Division wide letterheads, signature lines, office locations, telephone numbers, etc
The Framework Layer

The framework layer is all about the process. This is what empowers an organization to achieve the
majority of their reuse. Processes within an organization are often very similar between the different
divisions. By placing this common process in a framework, we just have to build it once for all the
different applications within that organization.
For example, if we look at an insurance company again, the claims process is generally the same no
matter which line of business.
Automotive, Home, Life, Health, etc It doesnt matter which kind of insurance, a claim still needs to
follow these same basic steps. This is what a framework provides. Frameworks should not be tied to a
single line of business, as this limits their reuse, but instead should always look at the broad picture
across the whole organization.
Case types
Flows
Flow actions
Sections
The Implementation Layer

The implementation layer is where it all comes together. This layer is the application that a user
leverages to perform their tasks. You can think of it as the glue that holds together the rules from the
framework, organization and division layers. The rules that are the most specific would exist here.
36
Class groups
SLAs
Routers
One key aspect to the implementation layer is that this is where any of our work classes should be
instantiated. This allows the class to be the most specific and can then ensure its leveraging the
appropriate rule in all instances. It also keeps the work for a particular division tied to that one division
and avoids possible cross division contamination of work.
The Benefits to a Good Enterprise Class Structure

Well, weve covered the basics of how to organize a class structure, but we still havent covered why we
may want one. This is one area that is often missed when explaining to a business the benefits of the
ECS. An ECS provides minimal yield in the very first application. The major yields come as the
organization grows and additional applications are built.
Take a look at the following diagram.
This is an example of typical organization that has been building and using PRPC applications for a little
while. Now is when this organization is reaping the benefits of their ECS. By forward thinking they were
able to plan frameworks and divisions that enabled them to build 5 different applications with relative ease
and reuse.
Does this create more work?

No, it shouldnt. A well designed Enterprise Class Structure should never contain 100% of the rules in
any one layer. Instead, the same number of rules that would have been used in a single application are
just spread around throughout the layers. Building an ECS should not take any more effort than asking
yourself What does this rule represent?
37
Theres no magic number to the balance of rules in any one of these layers. Each and every application
is going to have its own unique balance. The key to planning is keeping the purpose of the rule in mind
when building it. If the rule is related to the process, it goes in the Framework. If its a business standard,
it goes in the division or organization layers, as appropriate. If its specific to this one application, it goes
in the Implementation.
Describe Inheritance What makes the Enterprise Class Structure

Work
So how does it all work? How can rules existing in different classes be used with each other?
Inheritance!
Inheritance is what allows a class to use rules from its parent as if they were its own. For example, if we
have Classes A and B. If Class A (the child) inherits from Class B (the parent), then A can use any rule
defined on A or B. The opposite is not true. Parents cannot access rules from their children, so Class B
can only use the rules defined on B.
Inheritance is an Object Orientated Programing concept. Inheritance is defined as being a kind of. In
most Object Orientated Languages, we can only define one thing as being a kind of one other thing.
Like a desk is a kind of furniture, or a poodle is a kind of dog.
But not everything in life can be described as only being of one kind. For example, lets look at a swallow.
A swallow is a living creature that flies. We couldnt describe this with a single inheritance path because
not all things that fly are living creatures, and not all things that are living creatures fly.
For example, lets assume the follow properties exist for each of these classes:
Class
Things That Fly
Properties
Height from ground
Airspeed
Living Creatures
Number of Offspring
Swallow
Length of tail feathers
If the Swallow could inherit from both Things That Fly and Living Creatures, it would be able to use all 4 of
the listed properties. Thankfully, in PRPC we can do that. PRPC has the ability to define two kinds of
inheritance, Pattern and Directed. By providing two paths of inheritance, we can achieve multiple reuse
patterns.
Pattern Inheritance
Pattern inheritance is defined by the name of the class. For example, lets look at the class:
Anything before the last - is considered the classes parent. Patten inheritance continues to chain all the
way up to the very first class referenced in the chain. So for our class, the chain of parents is:
ADV-Purchasing-Work
ADV-Purchasing
38
ADV
Our class can use any of the rules defined on any of these three parents.
Directed Inheritance
Directed inheritance is how we explicitly specify an alternative parent for a class. We specify the directed
inheritance on the classs rule form.
For our example, the directed parent is Work-Cover-. Directed parents also chain so if we were to open
each of the class definitions well find that this classes parents are:
Work-CoverWork@baseclass
So our class is also able to use any of the rules in these classes.
How can I see all the parents of my class?

In order to see all the parents a class has, we just need to right click on the class and select Inheritance,
as shown below.
39
This opens the Inheritance Viewer. The Inheritance Viewer allows us to see all the parents of the class
as shown here:
The parents are ranked according to the order theyre checked during rule resolution. When a rule is
requested, the system first looks in the child class, then works its way through the parents starting from 1.
Example:
Weve requested to execute Rule A. Looking at the all the available Rule As in the system, we find it
on:
1. ADV
2. Work3. ADV-Purchasing-Work
4. @baseclass
When the system ranks these it selects the copy of the rule in #3, since it follows the order shown in the
Inheritance Viewer.
40
Conclusion
Intodaysapplications,theenterpriseclassstructureiswhatdrivesthereusemodel.Awellplanned
classstructureshouldincorporatetheneedsforreuse,bothprocessorientatedandbusinessorientated.
41
Circumstancing
Introduction
Welcome to the lesson on Circumstancing. In this lesson, well discuss how we can use circumstancing
to provide flexibility to a PRPC system to address the complex demands of outlier business rules.
Define circumstancing
Identify different kinds of circumstancing
Describe circumstancing in rule resolution
Define Circumstancing
Circumstancing is a way we can create specialized copies of rules to use based on the evaluation of a
condition. This helps us handle the outlier cases that go beyond the basic process. For example, we
might need the system to apply a different tax calculation if a person is retired. This is an easy case, and
potentially could have been handled directly in the tax calculation. But, what if we have a more complex
situation? Lets say we need to apply a different tax calculation if a person is retired, they retired after Jan
1st, 2000 and they have no next of kin. Now what do we do?
These are the kinds of outlier situations that exist in businesses today. Complex business rules vary from
state to state; by time, by demographic groups, and any and all possible combinations. Trying to account
for all of these possible combinations in different decisions and paths in the flows leads to a complex nest
of possibilities that become harder and harder to maintain.
By using circumstancing, we can keep the processes streamlined, and allow the system to determine
when to do things differently based on the information available at the time the rule executes. There are
four types of circumstancing, but they can be summed up as being either based on their data and/or
based on time.
The Base Rule

One of the important concepts in Circumstancing is the base rule. The base rule is the un-circumstanced
version of the rule that acts as the default for the basic process. In fact, since a circumstance is a
variation of this base rule, the circumstanced version cant even exist unless the base rule has been
created first.
Creating a circumstance
So, how do we create a circumstanced rule? Easy, first we select our base rule, then we select
Specialize by circumstance to a new rule.
42
In this lesson we are discussing the options for Specialize by circumstance. The other option to
Specialize by class or ruleset is described in the Reuse and Specialization lesson.
Which rules can be circumstanced?
Sothismeanswecancircumstanceanyandeveryruleright?Notsofast.Onlycertainruletypescanbe
circumstanced.Inorderforaruletobecircumstanced,thattypeofrulemusthaveatleastonethese
twooptionsenabled.
Allow selection of rules based on property values?

We use this option for circumstancing on the data available. In some cases, this data might be time
related, such as the creation date. However this is still static data and should not be confused with the
second option.
Allow rules that are only valid for a certain period of time?
We use this option for circumstancing based on the time the rule executes.
Identify different kinds of circumstancing

So far weve discussed the different basic ways that rules can be circumstanced.
But, lets say we need to specialize a rule based on if:
The customer is retired
The customer retired after Jan 1st, 2000
The customer is retired and has no next of kin
Were currently in tax season, turnaround the request in 2 days instead of 3.
Belowarethetypesofcircumstancingwecanuse.Letstakealookateachoftheminmoredetailandin
eachone,wellevaluateadifferentpartofouroriginalexample.
Single Property
As of Date Processing
Multivariate
Time-Qualified
43
Single Property
We use single property circumstancing when we look at the data available.
When we use single property circumstancing, the property needs to be a single value. Lists and Groups
are not compatible with Single Property circumstancing. The value of the property entered on the left is
compared to the entered value on the right. This comparison looks for an exact match and is case
sensitive. For this reason, Single Property Circumstancing is not recommended for customer entered
data.
Example
A single property circumstance is perfect for evaluating the first of our conditions. We can create a
circumstanced rule based on an IsRetired property. If the value of IsRetired equals Yes than this rule
is chosen. If the value is No then the rule is not chosen. Since the comparison is case sensitive, if the
value was yes then this rule is not chosen. This is why it is very important to always have control over
the values that are being compared.
As of Date
As of Date is very similar to Single Property, except that it:
1. Can only be used with date/time type properties.
2. Looks for circumstances where the rule is past the specified date instead of an exact match.
44
As of Date first looks for all circumstances where the value in the property is past the specified date or
time. It then chooses the circumstance that is closest to the value in the property. To illustrate, lets say
we had three circumstances with the following dates defined:
Rule A.1:
September 1st, 2012
Rule A.2:
June 1st, 2012
Rule A.3:
July 1st, 2012
If the system needs to pick one of these, and the property value is August 15th, 2012 then the system
would discard Rule A.1 because August 15th, 2012 is not past September 1st, 2012. It would keep the
other circumstances Rule A.2 and Rule A.3 because our date is past the dates of the circumstance.
Between A.2 and A.3, it would look for whichever circumstance is closer to the value in the property. This
is A.3 since July 1st, 2012 is later than June 1st, 2012, which makes it closest to our value of August
15th, 2012.
Well cover the exact process rule resolution uses to make these determinations a little later in this lesson.
Example
This kind of circumstancing is perfect for the second of our conditions. In this case we would create a
circumstance based on a RetiredDate property and specify Jan 1st, 2000 as the Date Value. This rule
is chosen anytime the RetiredDate is after Jan 1st, 2000. If the RetiredDate is previous to this date, for
instance Dec 31st, 1999 then the system drops to the default rule that has no circumstances defined.
Multivariate
But what if we need to evaluate more than one property? This is where multivariate circumstancing is
used. Multivariate requires the use of two additional rules, Circumstance Templates and Circumstance
Definitions. Using these two rules, we can define a circumstance that spans multiple properties and
multiple values.
45

In PRPC, Circumstanc
ce Definition and
a Circumsta
ance Templatte rules are part of the Tecchnical catego
ory
nstances of th
he Rule-Circu
umstance-Definition and Rule-Circumsstance-Temp
plate rule type
e
and are in
respective
ely.
The Circu
umstance Tem
mplate defines
s which prope
erties take pa
art in determin
ning if the circcumstance is valid.
What we define
d
here becomes the list of properties that a Circcumstance De
efinition can leverage.
TheCircumstanceDefinitionusesth
heCircumstanceTemplateetosetupthecolumnsoffvalidvaluesin
thisDefinition.Thede
efinitioncanb
beanynumbe
erofrowsan dcancontain
nanyvalue,o
orarangeof
values,foreachpropertyinthatrow
w.
46
Bringing this all together, with a Circumstance Template we can state that we want to evaluate multiple
properties. A Circumstance Definition then extends that Template to let us evaluate multiple values for
those multiple properties. A Circumstance Definition cannot be created without its corresponding
Circumstance Template and a Circumstance Template cannot be leveraged without at least one
Circumstance Definition being defined.
Once the Template and at least one Definition have been created, we can create a multivariate
circumstance by choosing to specialize by Template. On the new form, we can then specify the already
created Template and Definition to use for this rule.
Example
This kind of circumstancing is used for our third condition, since we will need to check if the person is
retired and if they have no next of kin. So, first we create a Circumstance Template to define that were
circumstancing on the IsRetired and NextOfKin properties. Once weve created the Circumstance
Template, we can create the Circumstance Definition that says were looking for someone who is retired
(IsRetired = True) and has no next of kin (NextOfKin = None). Finally, we specialize by Template and
select the template and definition we just created.
47
So that gives us four rules in the system to handle this special circumstance:
1. The Base rule
2. A Circumstanced Template
3. A Circumstance Definition
4. The Circumstanced Rule
Whenever this rule needs to be executed the system uses the Circumstance Definition and Template to
determine if the Circumstance is valid. If yes, it runs the Circumstanced version of the rule. If no, it runs
the Base rule.
Time-Qualified (Date Range)

Time qualified rules are a little different than the other circumstances. These rules arent based on
values. Instead these rules depend on when they are executed. Time qualified rules are used for
temporary purposes. For example, we might need to adjust our business based on a particular season,
such as providing end-of-year discounts, or maybe providing a longer turnaround time for grade requests
outside of the school year. This is different than circumstancing by a date property and care should be
taken to ensure the proper type of specialization is used to produce the desired outcomes.
When specializing by date, only two additional values can be specified. The Start Date and the End Date.
Only one of these is required, though both can be, and often are, specified. The system executes this
version of the rule if the current time is after the start date, but before the end date. If either the Start
Date or End Date is missing, then this becomes an open ended circumstance, which applies to all after a
specified start date or before a specified end date.
Example
This kind of circumstance satisfies our fourth condition, determining whether or not were in tax season.
To create this circumstance, we start with the SLA rule that specifies the turnaround time. We save this
rule to a new copy, provide a StartDate of Jan 1st and an end date of Apr 15th. The system now chooses
this circumstance whenever were between those dates.
48
Describe circumstancing in rule resolution

The Rule Resolution lesson introduces the concept of Ranking. Aside from its other functions, as
covered in that lesson, Ranking also impacts Circumstanced Rules. During the ranking process, all valid
circumstance variants are sorted according to their circumstance values.
Therankingprocessesordersby:
1. Override
2. Class
3. Ruleset
4. Circumstance Value in alphabetical order. (Multivariate circumstances rank by the order in which
the properties are listed in the Template
5. Circumstance Date in descending order.
6. Time Qualified by end date, in ascending order.
7. Time Qualified by start date, in descending order.
8. Non-Qualified
9. Version
Each of these sort orders is within the previous one. Override, Class, Ruleset and Versions are covered
as part of the Rule Resolution lesson, so well just focus on how the Circumstanced rules are ranked.
Using our previous examples, if we were to take a look at every possible circumstance combination of:
If the customer is retired
If the customer retired after Jan 1st, 2000
If the customer is retired and has no next of kin
If were currently in tax season, turnaround the request in 2 days instead of 3.
If we were to account for every one of these possible combinations, wed have a large number of rules to
maintain as shown in the table below.
Rank Order
Circumstance Value 1
Circumstance Date
(IsRetired)
(NextOfKin)
(RetiredDate)
True
None
Jan 1st, 2000
True
None
Jan 1st, 2000
True
None
True
None
True
Jan 1st, 2000
True
Jan 1 , 2000
True
True
End Date
Start Date
Apr 15th, 2014
Jan 1st, 2014
Apr 15th, 2014
Jan 1st, 2014
Apr 15th, 2014
Jan 1st, 2014
Apr 15th, 2014
Jan 1st, 2014
Apr 15th, 2014
Jan 1st, 2014
st
9
10 (Default)
49
In most cases though, the business doesnt need to account for every possible combination. Often one or
more of these rules supersedes another. Clarify with your Business Architect (BA) or Subject Matter
Expert (SME) the intent of these specializations to ensure the correct number of rules is being created. If
we were to create exactly the specializations requested, wed only have 5 variations as shown in the table
below.
Rank Order
Circumstance Date
(IsRetired)
(NextOfKin)
(RetiredDate)
True
None
True
True
End Date
Start Date
Apr 15th, 2014
Jan 1st, 2014
Jan 1st, 2000
4
5 (Default)
This looks much easier to maintain, and the system can now be relied upon to choose the correct rule to
execute based on the ranking order.
This table is written to the cache and evaluated as a part of every rule resolution request. This allows the
cache the maximum amount of reuse by using a single cache for every circumstance variation. Every
execution then confirms against this table the exact circumstanced version that needs to be executed for
the exact values held at runtime.
The Base Rule Flag

It is important to note that the version of a rule is less important than the circumstance. This is relevant
when an update is required to one of the variations of the rule, or to the base rule itself. Lets take a look
at the last circumstance.
If were currently in tax season, turnaround the request in 2 days instead of 3.
What if the base changes from 3 days to 4 days? This should be relatively easy; we just save the rule
into a new version and update it. But what about the circumstanced versions of the rules? Do we need
to save those too? No, because the system ranks version as less important than the circumstance. So it
is possible to have a circumstanced rule in version 01-01-01 and the base rule in 01-01-15. At run time, if
it matches the circumstance then it executes the rule from 01-01-01. Otherwise it will execute the one
from 01-01-15.
So how do we get rid of a circumstance? If the system always allows the old rules is there no way to
remove circumstances? Thankfully, there is a way. Any version of any rule that can be circumstanced
can also be designated as a base rule. This is done by checking the Base Rule flag while setting the
rules availability.
Checking this flag designates that this version of the rule is now considered this rules base and any
previous circumstances no longer apply. Lets take a look at the following list of all variations of a rule:
50
Version
Circumstance
01-01-01
None
01-01-01
.Dept = Accounting
01-01-01
.Dept = Engineering
01-01-15
None
01-01-20
.Dept = Engineering
01-01-25
None, Base rule Checked
01-01-30
.Dept = Accounting
01-01-35
None
Given this list, if we were to execute this rule when .Dept= Accounting, we get the 7th rule (ver. 01-01-30).
If we were to execute this rule when .Dept = Engineering, we get the 8th rule (ver. 01-01-35).
This is because the 6th rule (ver. 01-01-25) has the base rule checked. So, all the rules that were
previous to this version (rules 1 through 5) are no longer applicable to our ranking. When we look at only
those rules that are available for ranking, we can see that Engineering is not an applicable circumstance,
so it chooses the highest version of the rule with no circumstances defined.
Version
Circumstance
01-01-25
None, Base rule Checked
01-01-30
.Dept = Accounting
01-01-35
None
Conclusion
Circumstancing helps to empower the rule resolution process, allowing the system to determine the best
rule, for every possible outlier, all while providing the ease of reuse and maintenance.
51
Reuse and Specialization

At the end of this lesson, you will be able to:
Understand the goals of Reusability and Specialization
Understand the importance of rule naming and documentation in reuse
Understand the importance of rule modularity in reuse
Understand the use of parameterization in reuse and specialization
Assess the appropriate specialization technique for a given use case
Choose the right layer in the enterprise class structure for a given use case
Understand the Goals of Reusability and Specialization

Welcome to the lesson on Achieving Reusability and Specialization. This lesson will help us choose the
best design in order to promote reuse in a specialized application. We will cover:
Goals of Reusability and Specialization
Naming and Documentation-Rule Modularity
Parameterization
Choosing between specialization techniques
Choosing the Layer in the Enterprise Class Structure
When we first start building an application, its important to take a step back and broadly identify what
components are generic versus and which are highly specialized.
In an insurance application, for example, the ability to record customer information, coverage, and the
concepts of claims and deductibles are generic: they should apply to any part of an insurance
organization.
On the other hand, the functionality specific to location, or the particular insurance product would be
considered more specialized.We should plan ahead. With this in mind, assume that businesses will grow,
and the application will someday be used beyond the current use case. Dont box it in: assume, and build
for, change.
Also, assume that other people will be managing and extending the application. These folks may be
completely new to the project, and perhaps we will be on a different project, or out of town, or on that
dream vacation across the world. Regardless of where we are, it is imperative that someone else, given
appropriate access, can understand how the rules work.The goal here is to achieve specialization without
sacrificing reusability.
These two concepts are often pitted against each other: many applications that are specialized for one
purpose cannot be reused for another.
However, with the powerful layering technology of PRPC, coupled with proper design and planning, we
can achieve both quite handily.
52
Understand the Importance of Rule Naming and Documentation in

Reuse
Give rules meaningful names. We may consider this to be obvious, but nonetheless, in the heat of the
moment of fast-paced PRPC design, we may be tempted to let slip the occasional BobsReport rule. Or
deploy the all-new and hotly anticipated IsApproved_2 rule. Or name a rule InsurancePolicySection,
which could actually describe ANY section in our insurance policy application.
The rule name should indicate what the rule does, like OpenPurchaseRequests,
IsApprovedOverBudget, or CoverageList. This is our primary way to communicate with someone who
may wish to extend the application or support it in the future. Only rules with meaningful names will be
reused.
Secondly, complete the fields on the History tab. This is where people will look when they need more
descriptive information as to what a rule does.
Other description fields, such as those in the Parameters table, should also be completed with
thoughtful information.
Understand the Importance of Rule Modularity in Reuse

Make sure that rules are just the right size: big enough to be useful, but small enough to be reusable. If a
rule is packed with so much functionality that it can only be used for a particular use case, then consider
breaking it down into smaller components. Most rules types are designed so that they can be broken up
into smaller rules. For example, Flows can call smaller, reusable flows, Sections can embed smaller,
reusable sections, and, Data transforms can call data transforms.
Understand the Use of Parameterization in Reuse and Specialization

Lets discuss the use of parameters in order to achieve specialization and reusability. Parameters are
values passed into a rule to make it more reusable.
Consider, for example, a data transform rule that sets a CustomerType property.
Without the use of parameters, we may have to create three copies of this rule for each customer type:
Gold, Silver and Bronze.
If, instead, we create a CustomerType IN parameter, we can use a single rule and pass the desired
value into it based on the situation. Parameters help us by providing a way to separate functional control
from the specific business scenario. In doing so, it is possible to control a rule for different business
scenarios.
For example, consider a Life Insurance Application that has a section with three components: basic
information, such as Name and date of birth, a list of beneficiaries, and a list of prior conditions. This last
table should not always be visible, but the criteria for this visibility are fundamentally unrelated. It may
depend on the flow that is being executed, or the customers privacy settings, or the privacy laws dictated
by the customers home State, or the coverage, or perhaps the security level of the operator using the
application. To introduce this flexibility, create a parameter, and set the visibility to be dependent on that
parameter. That way, we introduce the flexibility now, and then later, we can decide how to set it.
Only certain rule types can be parameterized They are:
Sections
Flows
Data Transforms
Activities
53
Functions
Messages
Collections
Lets take a look at a typical parameter table. This is a parameter table for data transforms; it looks
similar for other rule types.
First, there is the name of the parameter. This is, well, the name of the parameter.
Next is the description. Please always fill this out, as it is the best way to communicate with
someone else who would like to use our parameterized rule.
The data type can be a string (which is the default), Boolean, integer, or page name.
In/Out specifies if the parameter is going in or out; the default is in.
Required? indicates if the parameter must be passed in.
Prompt Default Value allows us to set a default.
The last two columns, Type for SmartPrompt and Validate As, are advanced and are used
more for internal PRPC purposes. They are typically used for referencing rules
Lets take a look at how parameters are referenced.

To reference a parameter in the same rule in which the parameter is defined, prefix Param. in front of
the parameter name, as in Param.CustomerType.
To fill in parameters when calling a rule, open the edit parameters form with the magnifying glass button
to the right of the rule name. This will retrieve the parameters for the referenced rules, allowing us to fill in
information for this particular business case.
Assess the Appropriate Specialization Technique for a Given Use

Case
Lets spend some time discussing what specialization technique (Class, RuleSet, or Circumstance), is
most appropriate given different business scenarios. This is not an exact science: there may not be one
right answer for a given situation. Nonetheless, there are some guidelines, or questions we ask
ourselves to help with our decision.
The first question is if the specialization is aligned with a small set of major business components, like
Case Types or Products. Are there just a FEW, high level variants, and a LARGE portion of rules are
specialized for them? If so, Class specialization is well suited, whereas RuleSet and Circumstancing is
not. RuleSet Specialization for Products would not allow a user to work on multiple Products in the same
application. Circumstancing would also not work, as too many rules would be specialized for the same
business reason; it would not scale.
Contrast this with Edge Cases. In this case, we ask ourself, Are there MANY variants, and, of them, do
just a FEW require specialization? For example, imagine a scenario in which, of the almost 200
countries in the world, only a few of them have specialized functionality from the rest. In this case,
circumstancing is very well suited. 200 distinct classes and/or RuleSets would just be overkill.
We may now ask, What about in between? What if the system needs to represent all 196 countries,
each with distinct functionality? Again, there is no one right answer, but it is important to consider all
criteria when making the judgment call.
Consider security. Must the variants be separated security-wise? That is, must the system be setup so
that those who can manage the rules of one variant must not be able to modify, or even see, the rules of
another? In this case, Class specialization is best suited. Class specialization is the only technique that
offers control over security.
54
Persistence, like security, can also be controlled only with class-based specialization. If two different
variants of work objects must be stored in different tables, they must be in different classes.
The next question to ask is if the rules should be managed or promoted to production differently based on
the specialization. Only RuleSet specialization offers this level of control.
The next question to ask is if the set of features we are developing, while designed for a particular
purpose, are reusable for almost any application. For example, lets say we are developing a customer
complaint component for our insurance application. This is likely to be reusable in other applications as
well, throughout our organization. For this situation, RuleSet specialization is ideal, as a RuleSet can be
plugged into any application by including it in the RuleSet stack.
We should also ask if an operator should be able to call more than one variant in a given session. For
example, if a European institution must process requests differently for each country, must it be possible
for a single operator to handle work for both Germany and France in the same session? Or is each
country fundamentally a different application? RuleSets are associated with the application, which is tied
to the operators session. Therefore, if an operator must handle multiple variants in a session, either
Class or Circumstancing must be used.
The next question is if the specialization depends on customer-specific data, rather than some predefined organizational construct. If insurance premiums depend on a combination of a customers age
and address, it is best to setup circumstanced rules to handle this specific combination of values.
Finally, if the specialization depends on dates, or is in some way temporary, use Circumstancing. These
are the key use cases for which circumstancing was designed.
Now, lets take these questions and put them to the test with a series of examples.
In our first example, lets see how Lines of Business should be represented in PRPC. MyCo is an
Insurance Company with two lines of business: Life, and Home.
There is a significant amount of functionality (around 30%) that needs to be specialized along these two
products. We also need to separate these Lines of Business by security.
Its also likely that some case managers are able to handle both home and life transactions in the same
application. Therefore, considering these three factors, MyCos Business Line needs are most likely met
through Class specialization.
In our next example, YourCo is an insurance brokerage firm that wishes to specialize functionality
across brokers.
Each broker must be separate from the other; seeing one anothers rules is NOT allowed.
Further, because of this security requirement, it is critical that work objects for each broker be stored in
dedicated tables. Class-based specialization is the only technique that can meet the security and
persistence requirements of YourCo.
Our next example is an Insurance company called HerCo. HerCos application must be specialized
across locales, in this case, States.
Most locales have the same requirements, only a couple of states deviate; these are considered edgecases.
It is also imperative that a single operator can run workflows for different Locales in the same application.
As such, HerCos requirements are met through the use of Circumstance specialization.
Our final example is HisCo, an Insurance company that has different requirements across European
Countries, each of which represents a different business unit.
55
Each business unit must manage their rules separately; for example, the German business unit will
deploy their rules to production at a different time than the French business unit.
As such, designers are tempted to implement specialization with RuleSets only.
However, despite the fact that these business units are currently separate, it is believed that HisCo will
grow to a point where some operators will have to handle work for multiple business units in the same
application. It is very important to design the application not just for the current need, but for the future as
well.
There is no one specialization technique that can handle all of these requirements. RuleSet
specialization must be used to handle the deployment requirements, but what else? Class, or
Circumstance?
This is where it helps to consider how rule resolution works. Lets say we use a combination of RuleSet
and Circumstance specialization. We have four rules: a base rule and circumstance pair, in each
RuleSet.
The RuleSet stack is a fixed hierarchy: in a given application, the stack does not change. Lets say that
the France RuleSet is highest in the stack.
Lets say the value of the country property is France. RuleSet is considered before circumstancing; as
such the rules in the France RuleSet will be found first, and then the circumstanced rule will be chosen.
If, instead, the value of the country property is Germany, the rules in the France RuleSet will still be
found first, since RuleSet is considered before circumstancing.
Then, in this case, the base rule is selected.
Therefore, the combination of RuleSet and Circumstancing specialization will not work for HisCos
requirements.
If, instead, we use the combination of RuleSet and Class specialization, again we may have four rules,
but this time, the business unit specific rules are in dedicated classes.
If the country is Germany, even when the France RuleSet is higher in the stack, the appropriate rule will
be found immediately, because class is considered first during rule resolution.
Therefore, HisCos requirements would be met through a combination of RuleSet and Class
specialization.
The HisCo example illustrates an important point: RuleSets are really meant to facilitate
deployment. They are not meant for specialization within a given application.
They do help specialize, but the specialization is very broad, to differentiate one application from another.
To specialize within an application, use either class or circumstancing.
Finally, it is important to remember that Class-based specialization provides the most options, and should
likely be considered first when assessing a particular requirement.
Choose the Right Layer in the Enterprise Class Structure for a Given
Use Case
The enterprise class structure is an out-of-box structure to help facilitate reuse and specialization along
class lines.
There are four layers, each dedicated to a particular kind of reuse. The Organizational layer is for rules
that are to be used across the organization or company.
56
The division layer is for rules specific to a division.

The framework layer is for most of the rules in an application, whereas the implementation layer is for
application rules that are specific to a division.
Lets look at some example rules and identify where they should go.
Lets say we have a connector rule for Facebook.
Connector rules should be in one of the Integration Classes, and since we are likely to want to reuse
this rule for multiple divisions and frameworks, it should go in the organizational layer. In fact, it is best
practice to put connector rules in this class for exactly this reason.
Now, instead of a connector, what if we have a service rule, called CreateInsuranceRequest?
Service rules are NOT stored in integration classes. Integration classes are only for Connectors. Service
rules are really considered part of the application; in this case, an Insurance application. A
CreateInsuranceRequest Service rule would likely be in the same class as the very Process rule that
creates the work object. This would be in a class inheriting from the Framework workpool class.
What about a MaxCoverage rule?
This rule is also specific to the application. We have no reason to believe that it is specialized by
division. As such, it should go in the workpool class of the framework. Unless there is a specific reason
to do otherwise, all of our work processing rules should go in this class, or a class inheriting from it.
Finally, what if we have a ClaimAccepted Rule for the division EU?
This rule is definitely division specific, and it is also specific to the framework. Therefore, it should go in
the workpool class in the implementation layer, or a class inheriting from it.
57
Module 03: Case Design
Case Management - Under the Hood
Case Lifecycle Management (Stages)
Case Hierarchy
Creating and Editing Flows
Advanced Flow Processing
Screen Flows
Work Status
Work Parties
58
Case Management Under the Hood

When we use Case Designer to create our application and then move our application into production, the
case, stage, and step rules are locked. As the business changes we usually have to update the rules
associated with our cases and stages.
This lesson describes the rules we need to unlock or save into an unlocked ruleset version, so that we
can modify them for the business change. Editing these rules can be done through the Case Designer, as
well as the Process View. How to make the modifications in the designer and the view is covered in other
lessons.
Understand the Case Designer, and the Process View of the Case Designer
Understand which rules are associated with cases and how to open those rules from the Case
Designer
Understand Case Designer, and Process View

As an architect we need to understand the Case Management terminology, so that we can communicate
effectively with our peers on the development team.
We access Case Designer by going to the Case Explorer and clicking on the case under Case Type that
we want to work on. The area on the right is called the Case Designer. Below is the Case Designer view
of the Purchase Request case.
Now lets look at each tab in more detail. The Stages & Processes tab shows the stages of a case.
Under each stage, we can click on Configure Process Detail link to open the Process view of the Case
Designer, or simply the Process View.
59
The whole
e section is Process View. We can click
k on the Bacck to Stages button to get back to the
stages & processes tab
b of the case designer. In the
t process vview, all the stteps of the sttage appear o
on left
m of a tree like
e view.
in the form
We use th
he Case Designer Details
s tab to config
gure the case
e. Shown belo
ow is the case
e designer
details tab
b for a top mo
ost parent cas
se, for a subcase which ha
as its own sub
bcases, and a subcase which
does not have
h
any sub
bcases, as sho
own in 1, 2 an
nd 3 respectivvely. As we ccan see, the m
main differencces
are that th
he top most parent
p
case on
nly has Email Instantiation configuration
n, any case th
hat has subca
ases
has the Data Propagattion configura
ation item, which is used to
o propagate th
he data declaratively from it a
case to its
s subcases. All
A subcases also
a
have Insttantiation con
nfiguration.
60
The Case
e Designer Sp
pecifications ta
ab is used to document the
e business re
equirements rrelated to the case.
Understand the
e rules be
ehind the
e Case De
esigner, a
and Proccess View
w
Understan
nding the rule
es being used
d is essential for
f the Seniorr System Arch
hitect, so thatt we can ensu
ure
the correc
ct rules are in an unlocked ruleset versio
on, before we
e make any ch
hanges.
We can open the rule behind
b
the ca
ase designer configuration
c
from the Casse Explorer itsself, by rightn the case an
nd selecting th
he Open men
nu option.
clicking on
This open
ns the Case Type
T
rule, pyD
Default. Lets look
l
at this in
n detail, so tha
at we can und
derstand where
the Case Designer con
nfigurations are stored in th
his rule. This rule is also ussed to configu
ure some item
ms
se Designer. Here, we see
e that the rule is not locked
d, as there is n
no lock icon o
or
that are not part of Cas
S
button is there to sav
ve the change
es. We can m
make the Case
e Designer
check outt button. The Save
changes in this rule. We
W recommend that you ma
ake the config
guration chan
nges in the De
esigner instea
ad of
e.
in the rule
61
The Proce
esses tab of the
t Case Type rule stores the configura
ation information we saw on the detail ta
ab of
the case designer.
d
This
s includes the
e work parties
s, data propag
gation, case w
wide supporting processess,
case wide
e local action and case match which is for
f duplicate ssearch. For now, just unde
erstand the ru
ule
type and name
n
of the rule
r
where the
ese configura
ations settingss are stored a
and how to op
pen that rule. In
this tab, we
w also see th
he list of subc
cases that are
e part of this ccase, under co
overable work types and th
he
starting prrocesses. The
e starting process is the firrst process th
hat runs when
n users click o
on create fro
om
the Create
e menu in the
e portal.
Lets open
n the starting process by clicking
c
on the
e magnifying g
glass next to the starting p
process rule n
name.
The starting flow usually consists off only one utility shape ( p zInitializeStag
ge) if the casse utilizes sta
ages.
In the process tab of th

he Case Type
e rule, we can
n have multipl e starting pro
ocesses. For e
each starting
process, there
t
is an en
ntry in the Cre
eate menu fo
or the end use
ers.
In previou
us versions off PRPC, the starting
s
proces
sses could on
nly be the pro
ocesses belon
nging to the cclass
of the cas
se. We were unable
u
to reus
se the flow fro
om the framew
work class in the implementation layer class
for the sta
arting flow in the
t case type
e rule. One wa
ay to reuse th
he rule was to
o copy the rule
e from the
Framework layer to imp
plementation layer or create a new flow
w rule in the im
mplementation layer and in
nvoke
ework flow rule as sub-process. Redund
dant rules we
ere getting cre
eated in this ccase. This
the Frame
limitation has been add
dressed in Pe
ega 7. Now, we
w can add flo
ows from the current layer and flow from
m any
he whole direc
ct inheritance
e tree as show
wn below in th
he picture.
class in th
62
The Stage
es tab of this rule stores th
he stages & processes tab information o
of the case de
esigner. We ccan
see the prrimary stages
s, configuratio
on of each sta
age and config
guration of ea
ach step as shown below. This
tab also stores
s
the info
ormation relate
ed to alternatte stages, verry similar to primary stagess information as
shown be
elow.
The Calcu
ulation tab sto
ores the calcu
ulations that are
a configured
d in the details tab of the C
Case Designe
er. We
can use th
he Attachmen
nt Categories tab in the Ca
ase Type rule to add new ccategories asssociated with the
case on which
w
we are working.
w
This
s tab does nott store any infformation from
m the Case D
Designer.
an use the
The Adva
anced tab doe
es not store an
ny information
n from the ca se designer a
as well. We ca
Advanced tab to publlish as a remo
ote case type
e, which is req
quired for Fed
derated Case
e Managemen
nt.
ng configuration in the Cas
se Designer and
a the lockin
ng configuratio
on here in the
e advanced ta
ab of
The lockin
the case type
t
rule are different.
d
Cas
se Designer lo
ocking configu
uration is valid for cases th
hat are
instantiate
ed under a ca
ase hierarchy.. The locking configuration
n here is valid for cases tha
at are instantiiated
as stand-a
alone case instances.
63
So far, we
e have seen the pyDefault Case Type ru
ule, which sto
ores the Case
e Designer an
nd Stage Designer
configurattion details.
Now, lets
s look at the ru
ule associated with any ste
ep in any stag
ge. We can open the flow rule associate
ed
with each step from the
e Open men
nu item of the Step Optionss menu.
When we click Open, the rule opens

s in a separatte tab, where we can see tthe name of the rule, which
h
class and the ruleset version it belongs to, and whether
w
the ru
ule is unlocked
d.
Any rule that we open from the case

e designer, if it is in a locke
ed mode, we will see the lo
ock icon next to
ns, as shown below. If the ruleset versio
on is unlocked
d, we can use
e the checkou
ut button. If th
he
the button
ruleset ve
ersion is locke
ed, we can co
opy or do a sa
ave as to copyy the rule into
o an unlocked
d ruleset version
for us to edit.
e
64
Conclu
usion
Now, you should understand what the Case Designer, and Prrocess View o
offer us. Case
e Designer
he pyDefault Case
C
Type ru
ule. Each step
p under a stag
ge is a flow ru
ule,
configurattion details arre stored in th
which can
n be configure
ed in the Proc
cess View.
These rule
es should be unlocked beffore making th
he changes in
n these desig
gners and the process view
w.
These rule
es can also be
b opened from the Case Designer.
D
The
ere can be mu
ultiple starting
g processes ffor a
case, and
d the starting process
p
can be
b any flow frrom any classs in the whole
e direct inherittance tree.
Remembe
er that the pyDefault Case Type rule do
oes contain m
more configura
ation details o
other the Case
e
Designer configuration details.
65
66
Case Lifecycle Management

The stages of a case identify different phases a case instance goes through. A stage identifies where a
case instance is, at a specific time. For example, a sales case may have these stages: Request for
Quote, Create Quotation, Negotiation, Review Quote, Approval, and Closure.
At design time, business users can see the complete life cycle for a case, as well as, the steps needed to
complete the case. At run time, business users can see what stage a case instance is in, at any point
during the process.
Configure stages and steps for a case
Understand the runtime user interface of stages
Stage Configuration
Remember that a case defines the work we want to complete. A case is then broken up into a set of
stages; stages are logical milestones that work will transition through. Stages comprise a set of actions
that can either be a single step, multiple steps or launch another case. PRPC handles moving the work
from one step to the next, then one stage to the next. How does PRPC know to when to start a stage?
You configure stage behavior in the Case Explorer.
We configure the stage behavior with the Configure Stage Behavior menu option.
Click the Configure Stage Behavior, to open the Stage configuration dialog box.
67
Stage Name We can change the name of the stage here also, if we want to.
Stage service level agreement Applies a service level rule to the stage. The service level starts when
the case enters the stage, and ends when the case leaves the stage or the process otherwise stops.
Skip stage when Use this option to skip a stage if a when rule resolves to true. For example, suppose
a customer is prequalified for a home loan, therefore a background check is no longer needed. A stage
used to conduct a background check can then be skipped.
Is this a resolution stage? By checking the box we identify the current stage as a resolution stage. A
resolution stage indicates a stage where you expect to resolve a case. When selected the stage name is
underlined in red, in the Case Explorer. When a stage is marked as a resolution stage, a case is not
automatically resolved upon completion of that stage. Resolving the case needs to be done from within
the application. The benefit of marking a stage as a resolution stage is that it gives business users a
visual indication of which stages are expected to complete a case.
When all stage processes are completed or skipped
Transition to the next stage - when all the steps are processed, the case instance transitions
automatically to the next stage in the primary stages.
Stay in the current stage - tools such as the Change Stage smart shape or the Change Stage
flow action allows the system or the end user to move to another stage.
OPTIONAL PROCESSES We can specify optional processes, which are implemented as flow rules.
These optional processes appear to end users in the Perform Harness, under the Other actions menu.
Users can run optional processes as needed. For example, suppose we select stay in the current stage,
and provide users different processes which they can select to move to a more appropriate stage. We are
allowing users to decide which stage to go to, in this scenario. We are enabling the users to make a
manual decision as needed. One concrete example is, when a shipped item is received, the users can
select to go to pay invoice stage or return the shipment stage.
68
In addition to stage level optional processes we have configured here, we can also have case wide
supporting processes which we configure on the Case Designer Details tab. Both configurations
appear in the processes section under the action menu for the end users. The difference is that case
designer supporting processes appear throughout the case processing and the stage level optional
processes only appear when the case instance is in that specific stage. If both are configured, both
processes appear without any duplicates.
OPTIONAL ACTIONS We can have optional actions, which are implemented as local flow actions.
These optional actions appear to end users in the perform harness, under the Other actions menu.
Local action when processed does not make the case instance to move from the assignment shape.
Flow action when processed makes the case instance to move to the next shape in the flow. AttachFile is
a standard local action, which the end users can use optionally to attach a file.
Local Actions can be:
Specific to
Configured on
Available to End Users
Assignment
Assignment Shape
Only in that specific assignment
Flow wide
Flow rule
In all the assignments of a specific step
Stage wide
Stage Configuration as shown above
In all the assignments of a specific stage
Case Wide
Case Designer Details Tab
In any assignment throughout the case
We can also use a validate rule to determine whether the case enters the stage or not, by selecting
Configure entry validation from the menu. This provides us with two validation options:
Stage entry validation a specified validate rule runs against the case.
Attachment validation the case must contain an attachment of the specified type.
If either validation fails, the case returns to the previous stage with the appropriate validation error
message.
Step Configuration
Once the stages and steps are added, the steps can be configured to meet different business needs.
Remember that each step creates a flow rule. We can configure the steps intended purpose, and
whether the steps run in sequence or in parallel. A step can be reused in any stage.
We can configure the step behavior with the menu option Configure step behaviors.
69
When we click on the Configure
Ste
ep Behaviors
s, Step config
guration dialog box below a
appears.
Step Description Enter

E
a description or a spe
ecification. Sp
pecification an
nd specificatio
on actions are
covered under
u
a differe
ent lesson.
Step Type As a step type, we ca
an choose one
e of the follow
wing:
Single Step As
ssignment creates a flow
w rule with a ssingle assignment shape a
and start and end
sh
hapes.
Case
C
it crea
ates a flow rulle with a single Create Ca
ase(s) smart shape and sttart and end
sh
hapes.
Approval
A
creates a flow rule
r
with a sin
ngle subproce
ess shape. Th
he subprocesss shape callss the
sttandard pzAp
pprovalFlowW
Wrapper flow
w. Approval stteps can be cconfigured forr processing b
by a
siingle operatorr, or a cascad
ding series of operators ba
ased upon eith
her the existin
ng reporting
sttructure or an
n authority ma
atrix configure
ed by a decisi on table. The
e cascading a
approval optio
on
70
behaves similarly to the Cascading Approval smart shape, and can be configured in the same
manner.
Attachment creates a flow rule with a single subprocess shape. The subprocess shape calls
the standard pzAttachFile flow, which itself consists of a single assignment that calls the
pxAttachContent flow action.
Multi Step Process creates a flow rule with two assignment shapes. The flow rule can be
edited to add more shapes or to remove shapes. In essence, any flow that does not qualify as an
Assignment, Case, Approval or Attachment stage is a multi-step process step.
Start Step The Start Step section allows us to determine when if at all in the stage the user is
allowed to perform the step. When the case enters the stage, it automatically attempts to prompt a user to
perform the first step. Subsequent steps can either occur in parallel or in sequence.
Upon stage entry steps are processed concurrently when the case instance enters this specific
stage.
Upon completion or skip of previous step steps are processed sequentially when the case
instance enters this specific stage.
The first step of a stage must always have upon stage entry set to true. For any subsequent steps, we
can choose either concurrent or sequential evaluation. Each step configured to start upon stage entry
begins a new step sequence, and each sequence is indicated with a double line colored blue.
and when We can have a when rule in this field. If the when rule is false, the step is skipped. If the
purchase request contains a hardware or software items, we need to get the approval from an IT
Manager. We can have a when rule IsITApprovalReqd for the IT Manager Approval step.
When a specific step of a stage is processed, subsequent step in that stage will be automatically kicked
off, if that is marked to start upon completion or skip or previous step. In the previous step, if we change
to a previous stage using the Change Stage smart shape, another step in the previous stage also
started. If this effect of two steps across two stages getting kicked off is not desired, we can have the
standard when rule pxIsInCurrentStage in the subsequent step.
71
Launch on
o re-entry? Once a sta
age is processed it can be re-entered frrom another sstage by the
change sttage process or manually by
b the end us
ser. Only the ssteps that havve this option
n selected are
e
started au
utomatically when
w
the stage is re-entere
ed.
Runtim
me User Interface of the Sttages
We need to understand
d that how we
e configure th
he stages and
d steps have a
an impact at rruntime.
When a case that is de
esigned with stages
s
is insta
antiated, we ccan see whatt stage the case instance iss in.
All the primary stages show
s
in blue and the stage
e we are in ap
ppears in blacck. Alternate stages appea
ar
t primary sttages where the
t case insta
ance deviatess from the hap
ppy path. Forr example, if tthe
between the
case insta
ance is rejecte
ed right in the
e initiation sta
age itself, Rejjection altern
nate stage shows up in
between the
t initiation and
a review prrimary stages. If it is rejecte
ed during the review stage
e, Rejection
alternate stage
s
shows up in between the review and
a fulfillmen
nt primary stag
ges
ent applicatio
The exam
mple below shows multiple steps configu
ured to run co
oncurrently. T
This is a differe
on to
show a Pu
urchase Requ
uest case.
Each of th
he areas identified in the sc
creen shot arre described a
above.
72
1. Here
H
the appro
oval stage has been config
gured to have
e two steps that run upon sstage entry
ap
pproval to salles manager and approval to purchasin
ng manager. B
Both steps run
n simultaneou
usly
an
nd create two
o assignments
s. Rememberr, not all the ssteps have to create an asssignment though
a step can be a Single Step
p Assignment, or Multi S tep Process or Case. Siingle Step
Assignment
A
ste
eps have alw
ways one assig
gnment. Multiistep processs may have no
one or one orr
more
m
assignme
ents.
2. Under
U
other ac
ctions menu, there
t
are the flow actions ffor the assign
nments. In this example, th
he
op
perator has th
he privileges of both Sales
s Manager an d Purchasing
g Manager roles so we see
e the
flo
ow actions for both the ass
signments. Un
nder the flow actions, loca
al actions appear if they are
e
co
onfigured. Un
nder the main menu of othe
er actions, op
ptional processses appear iff they are
co
onfigured. Jus
st a quick rev
view here. Loc
cal actions ca
an be assignm
ment specific or flow wide ((step)
orr stage wide or
o case wide. Optional processes can b
be stage wide
e or case wide
e. Based on th
he
co
onfigurations,, these will be
e available to the end userss when they a
are at a specific assignment or
sttep or stage or
o case.
Using the summary vie

ew of any stan
ndard portal, end users ca n quickly get an idea of ho
ow many case
es
are in eac
ch stage of the
e case lifecyc
cle. The numb
ber next to the
e stage name
es indicates th
he number off
instances in that stage.
he number pu
ulls a standard
d report as sh
hown below.
Clicking th
In the porrtal, from the drop

d
down, en
nd users can change to diffferent cases to pull the su
ummary for th
hat
case.
73
Conclu
usion
Now, you should understand how to
o configure sta
ages and ste ps. Stages an
nd steps not o
only help brea
ak
kflow into man
nageable task
ks, but also a llow for reuse
e of the proce
esses. Stagess in
the compllex case work
the case designer
d
show
w the overall view of the ca
ase, instead o
of having to o
open the starting flow and ffollow
it through the whole thrread to underrstand the bus
siness processs.
At runtime
e, we can see
e what stage a specific cas
se instance is in, and also a summary o
of all the casess and
the stages
s that they are
e in.
74
Case Hierarchy
During a Case decomposition of smaller tasks, we identify stages and steps. In the process, if we see that
the tasks are individual transactions that have their own lifecycle independent of the parent case, then we
create them as subcases. The parent case and subcases form a case hierarchy. While designing for our
Purchase Request case, we identify two more subcases, Purchase Order and Inventory Selection. The
subcases are initiated at the appropriate step of the parent case and are processed to resolution
eventually with their own lifecycle.
When creating the subcases in the case hierarchy, understanding how to configure the subcases
inheritance helps the architects to maximize reuse of the rules and understand where the rules are pulled
from when rule resolution executes. Understanding how to instantiate the subcases also helps the
architect to instantiate the rule at the right time and only as needed. This lesson covers these, the
advanced settings of the creation of subcases, and the different ways that we can instantiate subcases.
When subcases are instantiated, the subcase might need data from the parent case. And we might need
to aggregate the data from several subcase instances to the parent case. This lesson covers data
propagation to and from the parent case and explains how to use the calculation feature to aggregate
properties in the subcases. Architects need to decide whether the cases are to be locked when opening
the cases or only when submitting the cases. We also need to decide whether the parent case is to be
locked when the subcase is being worked on. We will also cover different locking configurations that
impact parent and subcases.
Use the advanced settings to create subcases
Instantiate subcases in the case hierarchy and choose the best way of instantiation
Get the data from the parent case to the subcases
Aggregate data from several subcases to the parent case
Use the different locking configurations related to subcases and parent case
Understand the key properties that related to the parent case and subcases
Using the Advanced Setting to Create Subcases

When creating a parent case, subcases or any stand-alone case, we can change the default settings of
inheritance, and the ruleset version.
To add a case, from the Case Explorer select Manage Case Type > Add a case type. The Create Case
Type dialog box appears. Lets expand the advanced settings tab to review the advanced configurations
options.
75
Derives From
F
(Directe
ed) We use this field to change the d
directed inherritance chain. All the casess are
typically derived
d
from Work-CoverW
or
o one of its descendants,
d
so that we w
want can take advantage off
several sttandard features available in Work-Cove
er- abstract cclass and its ssuper classes.
Derives from
f
(Pattern
n) We use this field to ch
hange the pa ttern inheritan
nce chain. Ch
hoose the
appropriate class from the dropdown maximizes reuse and letts indicate wh
here we wantt the rule
n algorithm to pull the rules
s from. We can choose the
e same workp
pool class as tthat of the parent,
resolution
the class of the parent case, the cla
ass of a sibling
g case or a cllass of any ca
ase in the app
plication on w
which
orking.
we are wo
Ruleset and
a Version Use this fie
eld select the ruleset and vversion where
e the Case Tyype rule for th
he
case is go
oing to be sav
ved.
Remote Case
C
Type Use this field to select the
e Remote Ca
ase type to pu
ublish this casse as a remotte
case for another
a
applic
cation. This is
s only required
d for Federate
ed Case Man
nagement. Federated Case
e
Managem
ment will be co
overed under a different les
sson in an ad
dvanced coursse.
Create Sttarting Proce
ess Use th
his field to create the pySta
artCase flow rrule, with a de
efault short
descriptio
on of Create case
c
name. Allways select this
t
option wh
hen creating ccases becausse this creates a
starting flo
ow pyStartCa
ase which ha
as one utility shape
s
pxInitiializeStagepzzInitializeStag
ge that initializes
the stages
s. This startin
ng flow rule ca
an be edited later to chang
ge the short description forr the create m
menu
and/or to change the flow rule, if nec
cessary.
If we need
d to change any
a of these settings
s
after the
t creation o
of the subcase
e, just update
e the Class Group
and Paren
nt class fields
s in the class definition
d
form
m.
If we need
d to change th
he ruleset or ruleset versio
on, save the p
pyDefault Casse Type rule u
under the
appropriate ruleset and
d/or version. Then
T
we can add more sta
arting flows in
n the Process tab of the
a
select or deselect Pu
ublish as Rem
mote case type
e in the adva
anced
pyDefault Case Type rule. We can also
tab of the same Case Type
T
rule.
76
Instantiation off Subcase

e Instancces
We can co
onfigure subc
cases to be in
nstantiated in different wayys. Each one of the ways m
meets differen
nt
needs. Le
ets explore th
hem in more detail
d
to learn when to use each instantiiation configu
uration option.. The
different in
nstantiation options
o
are:
Subcase Case
e Designer
Step Configura
ation in the Parent
P
Case Designer
D
Create
C
Case Smart
S
Shape in
i any Flow ru
ule
Using th
he Subcase
e Case Dessigner
Using the Subcase Case Designer we
w can instan
ntiate a subca
ase automaticcally or manua
ally. To instan
ntiate
e instance automatically an
nd/or manually by our end users, selectt Case Design
ner> Details T
Table
a subcase
and click the
t Edit link by
b Instantiatio
on.
Lets begin by learning how we conffigure a subca
ase to instanttiate automatiically. We ma
ay want to
e a subcase automatically
a
if we have a dependency condition that has to be m
met..
instantiate
For example, we have a Catalog ma
aintenance su
ubcase that n
needs to be in
nstantiated wh
hen the inventory
s pulling items
s from invento
ory and then w
when the parrent case reacches
selection sibling subcase completes
c
is compllete.
the fulfilled status our case
e can also instantiate the subcase Purc
chase Order a
automaticallyy under Purch
hase Request
Note: We
parent cas
se, by selecting the check box Automa
atically by sysstem when an
nd select the radio button the
parent cas
se starts. Or we can use a When rule and
a when it e
evaluates to trrue, the subca
ase gets
instantiate
ed.
Instead off instantiating the subcase automatically

y when the pa
arent case sta
arts, we can iinstantiate the
e
subcases based on de
ependencies. The depende
ency is called an instantiatiion dependen
ncy. We can
e when any or
o all depende
encies are me
et. For a subccase to be
configure the subcase to instantiate
ed, a depende
ency can be a parent case
e and/or any o
other sibling ssubcase(s). T
The dependen
ncy
instantiate
conditions
s are Has Sta
arted or Has
s Work Status
s or Has Co
ompleted. We
e can have m
more than one
dependen
ncy.
If the depe
endency is th
he parent case
e for a subcas
se to be insta
antiated, the d
dependency ccondition can only
be Has work
w
status. A specific worrk status can be selected ffrom the drop
p down box ne
ext to Has W
Work
status.
If the depe
endency is an
nother sibling subcase, a subcase
s
can b
be instantiate
ed automatica
ally when the
sibling subcase has sta
arted, has a specific
s
work status
s
or has completed.
77
The follow
wing screen shot shows the
e instantiation
n of Purchase
e Order subca
ase when the Purchase
Request parent
p
case has
h a status of
o Pending-Fulfillment and tthe Inventoryy Selection sib
bling case ha
as
started.
We can se
elect Manually by user wh
hen we want to use a Whe
en rule and th
hen when the
e rule evaluate
es to
true, our users
u
can create a subcase manually.
For example, our custo
omer services
s representatives (CSRs) m
modify the customer addre
ess informatio
on
e there is no need
n
to instan
ntiate the Ad
ddress Chang
ge case all th
he time. It is b
better
infrequenttly. Therefore
to have th
he CSR manu
ually instantiatte the case.
At runtime
e, end users can
c manually create the su
ubcase from tthe parent case context ass shown below
w. If
the subca
ase is configured to be instantiated manually, then ussers can crea
ate the subcasse purchase o
order
from the parent
p
Purcha
ase Request case.
c
From th
he Other actio
ons menu, ussers select Ad
dd Work men
nu
and selec
ct the Create Purchase Orrder Case to create the su
ubcase manua
ally. This lets our users co
ontrol
the instan
ntiation proces
ss and instantiate the subc
case as neede
ed.
78
Using th
he Step Co
onfiguratio
on in the Pa
arent Case
e Designerr
We can use this config
guration option
n whenever we
w want a sub
bcase is to be
e instantiated automaticallyy by
m when a step of a stage is reached in the parent ca
ase,. This metthod gives uss more optionss of
the system
instantiating multiple ca
ase instances
s or a top leve
el case.
For example, we create
e a purchase order for a la
aptop and ourr purchase request case iss created in th
he
Purchase Request system.
In the cas
se designer off the parent case, we can add
a a step in an appropria
ate stage and we can configure
it to instan
ntiate a subca
ase instance. We can also use an optio nal When rule
e and the sub
bcase instancce is
instantiate
ed only when that rule evaluates to true
e.
When we select Case as the step ty

ype (shown above), we can
n select creatte a top case,, create a sub
bcase
cases as insta
antiation optio
ons (as shown
n below).
or create multiple subc
Lets look at the configuration for a single
s
subcas
se instantiatio
on. We can s elect a subca
ase from the C
Case
an also selectt a starting pro
ocess, if there
e are multiple
e starting proccesses for the
e
type drop down. We ca
subcase.
79
If we choo
ose the Crea
ate a top case
e option inste
ead the case is to instantia
ated as a top level case, th
hat is,
it is not a subcase of a parent case. Any case ca
an be instantia
ated as stand-alone top levvel case. We can
w
.AP
Purchase Req
quest parent ccase can crea
ate
also creatte another parent case, if the situation warrants
another Purchase
P
Request parent case
c
instance or it can crea
ate a Purchasse Order top llevel case, evven
though Pu
urchase Orde
er is a subcase in the case hierarchy.
For example, now we want
w
to add another
a
item to
o our purchasse request forr a laptop.. W
We found out out
aptop it doesn
nt come with bag, so we create anotherr purchase re
equest case fo
or the bag. Th
he
that our la
laptop bag
g can be adde
ed as another line item in the
t same req
quest or it can
n be added ass another purcchase
request ca
ase in a spec
cific step. How
w the flow gets
s designed de
epends on the business re
equirements. Here
we see that we can ins
stantiate the parent
p
or any of the subcasses as top levvel case.
80
If we select the Create

e multiple su
ubcases option multiple ssubcases are instantiated ffrom a page liist.
r
that we
w also need a new monito
mes from a
For example, we just realized
or for out lapttop and it com
v
we ne
eed to create multiple purchase orders,
different vendor,
81
We can view the instan

ntiation of sub
bcases in a sttep by review
wing the case designer of th
he parent casse.
Using th
he Create Case Smarrt Shape in
n any Flow
w rule
We can use this config
guration option
n whenever a subcase is tto be instantia
ated from a flo
ow rule of anyy
ardless of pare
ent or sibling or the case ittself. This me
ethod gives uss more option
ns when
case rega
instantiating multiple ca
ase instances
s or a top leve
el case.
For example, a healthc
care insurance company gets a file from
m their provide
ers and they w
want to create
e
ses, after certain steps are
e done and ce
ertain conditio
ons are met. A flow, as parrt of a case, ssuch
claims cas
as the file
e processor ca
ase, parses th
he file record and at the en
nd of the file rrecord, a deciision is made to
whether or
o not to creatte a claim cas
se.
82
A subcase
e can be insta
antiated in an
ny flow rule by
y adding the C
Create Case(s) smart shap
pe. To add the
Create Ca
ases smart sh
hape to the flo
ow rule, selec
ct the Shapess menu > Sma
art Shapes. O
Once the shap
pe is
added to the
t flow rule, the shape ca
an be configurred just like a step in the C
Case step type configuratio
on.
Getting
g Data frrom the Parent
P
Ca
ase to the
e Subcase
e(s)
When a subcase is ins
stantiated as part
p of the parent case, we
e might requirre some data that is alread
dy
e parent case
e.
part of the
In the Cas
se Designer of
o the parent case,
c
we can use the Data
a Propagation
n option to sett the values in
n the
subcase(s
s). The Data Propagation
P
option
o
can be
e found on the
e Details tab o
of the Case D
Designer. To
propagate
e data from th
he parent case
e to the subca
ase, we click the edit link n
next to Data P
Propagation, to
open Cas
se Designer: Data Propaga
ation dialog box.
We can propagate the data from the
e parent case
e Purchase Re
equest into th
he subcases, Purchase Orrder
ntory Selection. If we are simply taking the
t data witho
out making an
ny changes, w
we can use th
he
and Inven
data propagation option. We do not have to selec
ct Also applyy Data Transfform. If we arre using the d
data
ally or looping
g through a pa
age list or if we
w need to reu
use propagatting data from
m parent to the
e
conditiona
subcase, we can use the Also apply Data Trans
sform, option as well. We w
will learn abo
out using data
a
transform rules in another lesson.
83
For example, we would

d use the Data Propagation option only if we wanted our subcase
e (Purchase O
Order)
e same urgency, needed by date and cu
urrency as tha
at of the parent case (Purcchase Requesst). In
to use the
the Data Propagation
P
table
t
below we
w see the leftt column repre
ata of the sub
bcase (Purcha
ase
esents the da
Order) and the right co
olumn represe
ents the data of the parent case (Purcha
ase Request)). Data
on configuration informatio
on is stored in
n the Processses tab of the Case Type ru
ule of the parrent
propagatio
case.
m rule, we can
n propagate data from pare
ent case to the subcase in the step
Using a data transform
ase designer of
o the parent case.
configurattion, in the ca
84
If the data
a from the parrent case cha
anges after the
e data has be
een propagate
ed to the subcase during tthe
instantiation of the sub
bcase, the datta change is not
n reflected i n the subcase. If the latesst value of a
o the parent case
c
is neede
ed, then we use a data tran
nsform rule to
o get the valu
ue just before the
property of
processing of step/flow
w/shape of the
e subcase.
Calcula
ating a Pa
arent Casse Property from Subcase
e Properties
If we want to track the total cost of something,
s
we
e would need
d to aggregate
e the calculation in the parrent
m the propertie
es of all the subcases that have been in
nstantiated within the paren
nt case. For
case from
example, when Purcha
ase Requests
s subcases arre created outt of a Program
m Fund paren
nt case, we want to
k of the total cost
c
of the pu
urchase reque
ests made, so
o that we don t go over the
e funds allocatted in
keep track
the Progra
am Fund pare
ent case. So, we aggregate the total co st of purchasse request sub
bcases using a
calculation in the Progrram Fund parrent case
In the Cas
se Designer of
o the parent case,
c
we can use the Calcculations optio
on to set the vvalues in the
subcase(s
s). The Calculations option
n can be found on the Deta
ails tab of the Case Design
ner.
To see ho
ow the Calcula
ations option works, lets calculate
c
the T
Total Actual C
Cost of the Pu
urchase Requ
uest
parent cas
se. We will ne
eed to find the
e sum of the Invoice Amou
unt propertiess of all the Purchase Orderr
subcase instances and
d the Inventorry Cost of all Inventory
I
Sele
ection subcasse instances. Calculation
on is stored in
n the Process
ses tab of the Case Type rrule of the parrent case.
configurattion informatio
85
Once the calculation is

s configured in
n the parent case,
c
the systtem creates d
declare triggers in the
n see pyCase
eTypeAggrega
ate declare trrigger rule for both subcase
es.
appropriate subcases. Here, we can
ggers a stand
dard activity to
o do the calcu
ulations.
When we modify the property of a subcase, it trig
Lockin
ng of the Parent Case and the
t Subca
ases
Case insta
ances and wo
ork object locking has been enhanced i n Pega 7. Ussers can now select one off two
configurattion options Default lock
king or Optimistic locking. The businesss can make a decision on
whether to
o lock the cas
ses when ope
ening the case
es or only wh
hen submitting
g the cases.
Default lo
ocking locks the case whe
en an operato
or opens the ccase. If a seco
ond operator tries to open the
same cas
se, they get a message tha
at the case is locked by the
e first operato
or. The second
d operator is able
to open th
he case in rev
view mode on
nly. The lock is
s acquired wh
hen the case was opened by the first
operator. No actions ca
an be taken.
Optimistiic locking en
nables both th
he operators to open the ca
ase. No lock iis obtained w
when the case is
opened. The
T lock occu
urs when the user
u
clicks Su
ubmit. When ttwo operatorss are working on the same
e
case, the changes to th
he case are made
m
by whoe
ever submits the case firstt. The second
d operator recceives
ge with the firs
st operators name
n
and the
e time of the cchange. Also there is a reffresh button th
hat
a messag
allows the
e second operator to get th
he new chang
ges made by tthe first opera
ator. The seco
ond operators
changes are
a not applie
ed until they click
c
refresh and submit the
eir action afte
er the refresh.
86
In the Cas
se Designer of
o the parent case,
c
we can use the Lockking option to set locking o
on the top most
parent cas
se. If the subc
cases are ins
stantiated as part
p of the pa rent case, the
ey have the ssame locking
settings as
a the parent. The Locking option can be
e found on th e Details tab of the Case D
Designer.
The Defau
ult locking tim
meout is 30 minutes but can
n easily be ch
hanged to a ccustom timeou
ut as shown
below.
If a secon
nd operator tries to open th
he same case
e, they get the
e message tha
at the case iss locked by the first
operator and
a they can only open the
e case in revie
ew mode onlyy, as shown b
below.
Remembe
er if the paren
nt case has de
efault or optim
mistic locking and the subccase is instan
ntiated under tthe
parent cas
se hierarchy, then the subcase also has
s default or o ptimistic lockiing respective
ely. But, we ccan
change th
he custom tim
meout for the subcase,
s
irres
spective of the
e timeout setttings in the pa
arent case, fo
or
default loc
cking configuration.
We can also set parent case locking
g in the subca
ase locking co
onfiguration. T
The default option is to locck the
se when the subcase
s
is be
eing worked on.
o We can ch
hange this bu
ut the recomm
mended appro
oach
parent cas
for most use
u cases is to lock the parrent when the
e subcase is b
being worked
d on. If the Do
o not lock op
ption
is selected
d, the parent case is not lo
ocked when th
he subcase iss being worke
ed on. The ad
dvantage of ussing
the Do no
ot lock option
n, both the pa
arent and sub
bcases can be
e processed ssimultaneouslly. The main
disadvanttage of using the Do not lo
ock option is
s that since tthe parent case is not lockked, any prope
erties
related to the subcases
s, such as count of open subcases
s
is no
ot updated in the parent ca
ase. If this is not
neous process
sing is preferrred, then sele
ect the Do no
ot lock checkk box.
important and simultan
87
Using the Case Design

ner, we can ch
hange from default
d
locking
g to optimisticc locking for th
he top most p
parent
e lock is obtained when the
e case is sub
bmitted.
case. The
If the first operator has
s processed his/her assignment and whe
en the second operator su
ubmits his/herr
e/she gets the
e message an
nd a prompt to
o refresh as sshown below. The second operator needs to
action, he
refresh an
nd get the cha
anges done by
b the first use
er before sub mitting the acction again.
Any time we
w change to
o optimistic loc
cking or chan
nge the lock tiimeout in defa
ault locking, w
we are using
custom lo
ock settings. These
T
locking
g settings are persisted on
n the Case Tyype record in tthe following
properties
s, pyLockingM
Mode, and pyL
LockTimeout.. If the locking
g mode is deffault locking w
without a custtom
timeout sp
pecified, then the lock time
eout is obtaine
ed by the Datta-SystemAdm
min setting.
Locking
g Standalon
ne Cases
The lockin
ng process fo
or a standalon
ne case is a litttle different. A
Any subcase can be creatted as a
standalon
ne case. That is, we can create an inven
ntory selection
n case as a sstandalone ca
ase, not as a
subcase of
o the purchas
se request pa
arent case.
If a subca
ase is instantia
ated as a stan
ndalone case
e, the locking configuration is done on th
he Advanced tab
of the Cas
se Type rule for
f that speciffic subcase. We
W can selecct Default lockking and can sset a custom
timeout. Or
O we can also select Optim
mistic locking.
88
Key prroperties for Parent Case and

a
Subccase Relattionshipss
During the
e processing of parent cas
se, we may be
e interested in
n how many ssubcases are part of this p
parent
case, how
w many of tho
ose are still no
ot resolved an
nd what are th
he handles to
o those subcases. If we wa
ant to
know how
w many purchase requests have been created out of a Program F
Fund parent ca
ase, we can g
get
that inform
mation from one
o of these properties.
p
Letts look at the
e properties th
hat get this infformation.
o the
pxCovere
edInskeys This property
y holds the ha
andles or pzIn
nskeys of the subcases tha
at are linked to
parent cas
se. If needed, we can reference this value list properrty in our app
plication. This might be use
eful if
there is a need to list or
o identify all the subcases instances of a specific parrent case.
pxCovere
edCount Th
his property in
ndicates the number
n
of sub
bcases linked
d to the paren
nt. Anytime, a
subcase is added or re
emoved from the parent, th
he system auttomatically up
pdates the value of this
t indicate wh
hether a paren
nt case conta
ains subcase instances and
d
property. PRPC uses this property to
a
behaves accordingly.
pxCovere
edCountOpe
en A standard property th
hat holds the number of su
ubcase instances within a
parent tha
at are not reso
olved yet. As the subcases
s are being re
esolved, PRP
PC keeps this count update
ed
automatic
cally. This pro
operty value is
s used to ensure that there
e are no open
n subcases wiithin the parent
case.
All these properties
p
are
e referenced in the parent case instance
e. The child ccase also hass these properrties,
since both
h the cases are derived fro
om Work-Cover- abstract cclass and thesse properties are inherited from
that abstra
act class. Butt these are off no use for th
he child case, unless the ch
hild case is a parent for so
ome
other gran
nd-children ca
ases.
Conclu
usion
We learne
ed how to create subcases
s, and how su
ubcases beco
ome instantiatted. Instantiattion can be do
one in
a variety of
o ways and we
w should kno
ow which con
nfiguration opttion is best su
uited for the d
different situattions.
We also le
earned that we
w can propag
gate data from
m the parent tto subcases. This is useful when we ne
eed
the parent case data in
n the subcase
es. We should
d know how tto aggregate the values off the subcasess
e parent case
e. This is need
ded if we wan
nt roll up the d
data from the
e instances off the subcasess to
data to the
the parent case.
We can have optimistic
c locking or default locking
g in the case h
hierarchy and
d in stand-alon
ne cases.
c locking allow
ws multiple us
sers to open the
t same cas e instance. D
Default locking
g locks the ca
ase
Optimistic
when the case instance
e is used. The
ere are beneffits in both loccking mechan
nisms. We can lock the parent
essed. Finally
y, we should kknow the keyy properties th
hat are used ffor
case when a subcase is being proce
onship.
parent subcases relatio
89
Creating and Editing Flows

During Case Management Design, we add steps to stages, to break the stage into a set of manageable
tasks. Each step represents a task, a process, or a case. It is important to know what the step is going
to represent, but we do not have to decide how we are going to implement these steps at the time of step
creation. Each step creates a flow rule. This lesson teaches us how we can modify the flows to meet the
business needs.
We will also learn about creating flow rules but not as steps in the case designer when the flow has to be
created for technical internal processing or as part of data class.
At the end of this lesson, you should be able to understand how to:
Create flows
Edit flows
Call flows(s) from a flow
Use a wait shape
Creation of Flows
When a step is added in a stage in the Case Designer, a flow rule is created for that step. This is the
recommended and easiest way to create a flow.
A step can represent a simple task, such as review and approve a purchase request. It can also
represent a complex process that involves multiple parties, coordinated with some processing logic, such
as requesting a quote from a vendor. It can even represent another case one that can be processed in
parallel, such as creating a purchase order case, from the purchase request case. These are achieved
using the following types of steps, Single Step Assignment, Multi Step Process or Case.
Sometimes we have to create a flow rule first before it can be added to a step. For example, a screen
flow, which captures data entry, has to be created first and then it can be added later as a step in any
stage. We will learn about creating screen flows in another lesson. If the flow belongs to a data class,
then we need to create the flow but not as a step in a case. For example, in a purchase request, we want
to get the quote for each of the line items to be purchased from a preferred vendor. The line item may be
a data class for the purchase request case and the Request Quote may be a flow in that class. This flow
is not represented as a step in the Purchase Request case. Instead, we call this flow as a subflow from
another flow associated with a step in the Purchase Request case.
If a flow needs to be created as an internal process for technical reasons, such as parsing a temporary
file and do some logic behind the scenes, we create the flow, not as a step in a case. The business users
may not be interested in knowing the details of these flows. These flows may not have to be listed as
steps in the Case Designer.
We can create a flow rule from the Case, Data and App explorers using the Create menu as shown
below.
90
We can also create a flow

f
by right clicking
c
on the
e class in the app explorer and selecting
g New. The
enu choices ca
an be narrow
wed down if we
e right click o n the specificc rule type.
New me
Editing
g Flows
Once the flows are created, we can edit the flows
s to meet the business nee
eds by adding
g more shape
es or
pes.
removing existing shap
If the flow
w is listed as a step in the Case
C
Designe
er, we click the
e Configure process detail link under a
specific sttage in the Ca
ase Designerr to bring the Process
P
Mode
process view.. We can add a
eler into the p
basic shape or a Smarrt Shape or an
n Advanced Shape
S
from th
he shapes me
enu as shown
n below. To de
elete
k on the shap
pe and click th
he delete buttton or right click on the sha
ape and selecct
an existing shape, click
o
delete from the menu option.
91
We can also add or rem

move shapes from the tree
e like view in tthe process vview. Right cliick on a shap
pe
ct Add or Rem
move. Adding a shape in the tree view iss has its adva
antages becau
use the new sshape
and selec
is automa
atically added with the conn
nectors betwe
een the shape
e we right cliccked on and tthe next shape.
Similarly removing
r
the shape in the tree view rem
moves the sha
ape and the a
appropriate co
onnectors and
d the
existing shapes are rec
connected.
In the process modelerr of the proce

ess view, if the
e step type is a Case or a Single Step A
Assignment, w
we
gram. Instead we see the properties
p
pan
nel of the sing
gle shape, assignment or tthe
wont see the flow diag
C
smart shape. In this scenario, th
he only way tto add anothe
er shape is through the tree
e
Create Case(s)
view, whe
en the flow is opened in the
e process view
w. Note that w
whenever mo
ore shapes arre added to th
hese
two step types,
t
the step type automatically chang
ges to Multi P
Process Step
p step type.
In the diag
gram below, the
t Review step of the initiation stage is a Single S
Step Assignm
ment step type. In
the proces
ss modeler, we
w see the pro
operties of the assignmentt shape. We ccan right clickk on the single
e
shape in the
t tree view and use the Expand
and Add options to add more shapes.
92
We can open the flow in the App Ex

xplorer or from
m Search optiions, when flo
ow rule was ccreated not ass a
e Case Desig
gner. Once the
e flow rule is open, we see
e the process modeler and
d under the
step in the
Diagram tab,
t
we can access the sha
apes menu to
o edit the flow
w rule. We can
n use other ta
abs in this rule
e to
parameterize the flow, set the securrity, and configure the proccess. Even if tthe flow is cre
eated as a ste
ep,
t open the flo
ow rule to con
nfigure these settings unde
er different tabs. In the Casse Designer vview,
we have to
an easy way
w to open th
he flow rule of a step, is to right click on
n the step and
d select the op
pen menu opttion.
Calling
g Flow(s) From a Flow
F
When we are editing a flow, we can add a host of
o basic, Smarrt and advancced shapes. B
Below we see
e the
hat can be use
ed to call othe
er flows from a flow. Later we will learn the business reasons abo
out
shapes th
why and when
w
we wou
uld use a spec
cific shape to call other flow
ws.
We can ca
all other flows
s by using one of these thrree shapes
SubProcess sh
hape in the ba
asic shapes
Split For Each
Split Join.
93
We can use the subpro

ocess shape to
t call a subflow on a curre
ent page or o
on an embedd
ded page or
w
object. We
W can select one of these options in the
e Define Flow
w drop down
n, as shown b
below.
another work
If there a flow has man
ny steps it bec
comes hard to
o read and diffficult to main
ntain. So, bre
eak the processs
ple smaller flo
ows. But, with
h the stages and
a the steps in the Case D
Designer, we
e can call the flow
into multip
as a step and the flow can be proce
essed in sequence or paralllel making th
he process ea
asy to maintain.
g another flow
w from a flow on the curren
nt page may n
not add any vvalue.
So, calling
We can have a value to

o call a flow on
o an embedd
ded page. Th is lets us call a flow that be
elongs to ano
other
ch as a data class.
c
In the example
e
below
w, Shipping A
Address is an embedded page for the
class, suc
Purchase Request cas
se and the datta class is AD
DV-Purchasin g-Data-Addre
ess. Based on
n the addresss
w can have a flow in that class to chec
ck whether a S
Saturday delivery is possib
ble. That flow
w may
location, we
have a se
eries of shape
es and busine
ess logic to de
etermine whetther or not it i s possible to have a Saturrday
delivery and
a returns the
e result Yes or No. If the
t spinoff flow
ed, the main fflow
w check box is not checke
waits for the
t subproces
ss flow to finis
sh and return the result. So
o the flows ru
un in sequencce.
If the spin
noff flow check box is checked, the main
n flow does no
ot wait for the
e subprocess flow to execu
ute.
This lets us
u use the subprocess flow
w in a later ste
ep of the currrent flow. In th
his situation, tthe flows are
executed in parallel.
Similarly, if we select o
on specific wo
ork item, we can run the fflow on another case, whicch could be a
subcase or
o a top level case. For exa
ample, when a home loan case is proce
essed after th
he initial scree
ening,
we can kic
ck off another flow that doe
es a title searrch and home
e appraisal. T
This could be a
another case or a
subcase such
s
as a hom
me valuation case.
c
94
Using the Split-Join fun

nctionality is similar
s
to usin
ng a sub-proccess without th
he spin-off op
ption selected
d. The
erences are, that we can ca
all more than one flow, tha
at is, any num
mber of different flows on th
he
main diffe
current pa
age or embed
dded page or a specific wo
ork item. We ccan configure the join cond
dition as well. The
calling flow
w execution is halted until one or all or some of the ssubflows are completed. F
For example, tthe
purchase request is in waiting mode
e until the app
provals are co
omplete. Each
h approval prrocess is a
f
We hold
d the executio
on of the purchase requestt until one or ssome or all th
he approval
separate flow.
processes
s are complette.
More flow
ws can be add
ded with the add item optio
on as shown b
below in the S
Split Join prop
perties
configurattion panel.
The join condition

c
can be All Any or Some. The flow joinss back to the main flow wh
hen all or any of
the subflo
ows are comp
plete. For som
me, the flow joins
j
back ba
ased on the ite
eration condittion. Iteration
conditions
s can be base
ed on a conditional When rule
r
or it can b
be based on a count. In th
he example off
Purchase Request kick
king off multip
ple approval flows, we can continue with
h the main flo
ow, if the three
e
pprovals are received
r
with the On Coun
nt exit iteratio
on configuration.
(majority) of the five ap
95
With the Split
For Eac
ch shape, we can re-run th
he same flow for a set of re
ecords, as sto
ored in a page
e list
or page group. With the
e items in the
e LineItems pa
age list, we ca
an request a quote from th
he vendor for each
line item.
c
are
e All Any S
Some or Iterrate. The ma
ain flow can co
ontinue only w
when the quo
ote
The join conditions
request frrom any or all or some of th
he vendors arre complete. If we use the Some join condition, the
e exit
iteration can
c be based on a when co
ondition or ba
ased on a cou
unt. If we use the Iterate jjoin setting, th
hen
also the exit
e iteration can be based on a when co
ondition or ba
ased on a cou
unt. We config
gure the
conditions
s of when to process
p
the subflows unde
er the Page G
Group Iteratio
on Settings T
Tab. This tab is
only visiblle if the Iterate join condittion is selecte
ed. For examp
ple, lets say radon testing
g is only required
as part of home inspec
ction for the sttate of Califorrnia. Then, in the home insspection flow,, we can call tthe
o Radon Tes
sting with CA
A for Californ
nia listed in th
he subscript o
order as show
wn below. If w
we
sub flow of
want to us
se this flow fo
or multiple sta
ates, we can just enter C without the E
EXACT MATC
CH option sele
ected
and we ge
et California, Connecticut and
a Colorado
o, or we can a
add more item
ms to the list b
by clicking Ad
dd
Item link..
96
Config
guration of
o Wait sh
hape
There ma
ay be times wh
hen we want a flow to waitt before proce
essing continu
ues. For exam
mple, we mayy want
a purchas
se request to be put on hold until more funds
f
are ava
ailable. So, we
e need to che
eck to see if
enough fu
unds are available to purch
hase the requested items. If not, instead
d of rejecting the case, we
make the case instance wait using the
t wait shape and send a notification tto appropriate
e manager
e is in a wait status
s
becaus
se there are n
not enough funds available
e. In another
indicating that the case
w
to sprea
ad the work more
m
evenly a mongst our o
operators. So
o, when an
example, suppose we want
r
a cerrtain quota pro
ocessing scheduled tasks,, the next taskk assigned to
o that operato
or can
operator reaches
be put into
o a wait stattus until Mond
day of the following week.
The Wait shape can be
e configured for
f Timer Waiit Type and th
he waiting perriod can be a future date/tiime.
ys have a pro
ocess that is meant
m
for aud
diting in the be
eginning of th
he year. We ccan
Lets say that we alway
a we can also set the tim
me, if needed.. The other op
ption is Time
e
select 1/1/yyyy for the future date, and
a shown belo
ow. This can be any combination of min
nutes, hours, days and so o
on. We mightt use
Interval as
this option
n whenever a peer review is requested. We can say that the waiting period is o
one week, so that
the Manag
ger can make
e the necessa
ary business adjustments
a
w
within a weekk and the peer review can b
be
scheduled
d after the wa
aiting period. We
W can enterr one week orr seven days
97
The Wait shape can be

e configured for
f Case Dep
pendency Wa
e current case
e is made to w
wait in
ait Type. The
h a Wait shap
pe and for an
ny or all wait for conditionss. This waiting
g for a case d
dependency is
a flow with
called Mid Process De
ependency.
For example, in the Pu
urchase Request applicatio
on, the invoice
es received frrom the vendo
ors can be pa
aid
only after the requestor confirms rec
ceipt of the pu
urchased item
ms. So, the invvoice processs of the Purch
hase
se is made to wait, until the
e Purchase Request
R
case has the status of Deliveryy Confirmed o
Order cas
or a
similar sta
atus.
98
Conclusion
We should now know how to create and edit flows. Most of the time, we create a flow is by adding a step
in the Case Designer. But, in some instances when a screen flow is required, and the flow belongs to a
data class, or the flow should not be a step, we create the flows using the create menu in any one of the
explorers or the new menu in the app explorer.
Editing the flows can be done using the embedded process modeler in the process view of the Case
Designer. If the flow is not listed as a step, editing can be done using the embedded process modeler of
the flow rule. In either case, security, design and other configurations are done through different tabs of
the flow rule.
SubProcess shapes can be used to call any other flow, a subflow. We can use the Spin Off configuration,
if the main flow and the subflow can run in parallel. Note that we may not need to use this shape at all,
since we can create the configuration using the Case Designer.
We use the Split-Join shape to call any number of different sub flows on any class, Case or data class.
The main flow is configured to wait for the results of any or all or some flows to complete.
We use the Split-For-Each shape to call the same sub flow for each object in a list or a group. The main
flow can be configured to wait for the results of any or all or some or specific iteration flows to be
complete.
And we use the Wait shape to configure the current flow of a case to wait for certain time, such as
beginning of the quarter or for a future date or for a dependency on another case such as reaching of a
specific status, such as item is shipped from the inventory and the catalog needs to be maintained to
correct the items in the inventory.
99
Adv
vanced Flow Pro
ocessing
g
During Ca
ase Managem
ment Design, we
w can create
e and edit flow
ws to add diffferent shapess based on
business requirements
s. In this lesso
on we will see
e some smart shapes that are useful forr advanced
s such as getting multiple levels
l
of apprrovals for a pu
urchase request. Another requirement m
might
processes
require a duplicate sea
arch, to check
k whether the case instancce already exists before a n
new instance is
L
see how
w we can meet these two re
equirements w
with the help of smart shap
pes.
created. Lets
This lesso
on covers the usage of thre
ee smart shap
pes, cascadin
ng approval, d
duplicate search, and perssisting
a tempora
ary case. Alon
ng with the us
se of smart sh
hape, Case D
Designer confiiguration is re
equired for
Duplicate search.
At the end
d of this lesso
on, you should
d be able to understand
u
ho
ow to use:
Cascading
C
App
proval Smart Shape
Duplicate
D
Searrch Smart Shape
Persist Case Smart

S
Shape
Use the Cascad

ding Apprroval Sma
art Shape
e
We want to
t get multiple
e approvals based
b
on the requirementss. The Cascad
ding Approval smart shape
e
simplifies the developm
ment required, when the re
equirement is to get multiplle levels of ap
pprovals.
enario, if the purchase

p
requ
uest value is $110,000, we
e need to get the approval from the Cosst
In this sce
Center Ma
anager, the Department
D
VP and the VP
P of Finance. IIn releases off PRPC prior to Pega 7, we
would hav
ve needed mu
ultiple When rules
r
to check
k for the value
e of the purch
hase request and have the
e
appropriate assignmen
nts assigned to
t different op
perators in the
e flow. This has been simp
plified in Pega
a 7.
In the flow
w that we nee
ed to get multiple approvals
s, we add the Cascading A
Approval Sma
art shape from
m the
Smart Sha
apes menu in
n the process modeler.
100
We then configure
c
the Cascading Approval,
A
so th
hat we can ge
et multiple approvals, by rig
ght clicking on the
shape and
d selecting V
View Propertie
es. Lets look
k at approvalss based on the Authority M
Matrix.
First, we need
n
to create
e a decision table
t
to captu
ure the require
ement. This ta
able evaluate
es multiple row
ws
based on the cost of th
he purchase request
r
and re
eturns one orr more valuess. This table d
differs from the
e
ecision table configuration,
c
which only re
eturns the ressult for the firsst condition sa
atisfied. More
e
default de
informatio
on about this configuration
c
can be found
d in the Autom
mating Decisio
ons lesson.
101
The value
e(s) returned by
b the decisio
on table needs to be stored
d in a propertty in a page list. Here the
property is
s ApproverID on the Appro
overList page
e list. At runtim
me, when the case instancce reaches this
step in the
e stage, multiple assignme
ents are creatted one by on
ne to get the a
approval from
m each one of the
approvers
s.
Instead off an authority matrix, we ca

an approvals based on the
e reporting strructure. The rreporting struccture
can be ba
ased on Repo
ortsTo Manager or WorkGrroup Managerr.
102
In the Autthority Matrix option, the ap

pprovals are based
b
on a de
ecision table.. In the Reporrting Structure
e
option, ap
pprovals are based
b
on the reporting man
nager structu re or workgro
oup manager structure. If the
first when condition is true,
t
based on the levels of
o approval, asssignments a
are sent and a
approvals are
e
e can add mo
ore when cond
ditions by clic
cking Add Ite
em. If the firsst when condition is true, tw
wo
made. We
levels of approvals
a
are required. If th
he second wh
hen condition
n is true, three
e levels of app
provals are
required. Both the repo
orting and work group man
nager configu ration works tthe same wayy. When the ccase
r
this step
s
in the sta
age, the appro
oval assignme
ent is sent to one operatorr. In this exam
mple,
instance reaches
if the first when conditio
on is true, two
o more appro
ovals are requ
uired, his/her manager and
d managers
ates all the wh
hen conditions and stops a
at the
manager approval assignments are sent. The systems evalua
he approval assignments
a
are
a then sent to the numbe
er of levels co
onfigured usin
ng the
last when condition. Th
he Reports to
o and Work group are se
et for an operrator in the op
perator data
when condition. Both th
instance work tab.
103
Search
h for Dup
plicate Cases
Duplicate search is a useful
u
function
nality that pre
events the cre
eation of redun
ndant case in
nstances.
e and the Casse designer
Duplicate search functionality can be configured with use of a smart shape
ase instances
s with similar characteristic
c
cs are created
d, one of them
m gets resolve
ed
configurattion. When ca
with the status resolved
d-duplicate. We
W can be pro
oactive and p
prompt the end-users of po
otential dupliccates
arch functiona
ality.
using the duplicate sea
When two
o Quality Analysts find a bu
ug almost at the
t same time
e, two bugs w
with different b
bug IDs are
created. Later,
L
when th
he duplicate is
s found, one of
o the bugs iss closed with a status of re
esolved-dupliccate.
We can avoid this situa
ation using the duplicate se
earch function
nality. When the duplicate search is use
ed,
nd quality analyst is promptted with a me
essage saying
g that there w
was another bug created with
the secon
similar characteristics. The analyst can
c then mak
ke a decision to continue a
and open a bu
ug or resolve the
t status of resolved-dup
plicate.
bug with the
From the Case Designer Details ta
ab, we can co
onfigure dupliicate search. Configuring tthis creates a
different case
e
Case Mattch rule with a default name pyDefaultCaseMatch. If we want we ccan create a d
match rule
e by editing Case
C
Match fie
eld in the processes tab off the Case Tyype rule. If duplicate search
h has
been conffigured before
e in Case Des
signer, this ru
ule should be unlocked to e
edit the dupliccate search
configurattion in Case Designer.
D
1. Here
H
is the sam
mple for identtifying duplica
ate bug casess. Must Match conditions, as the name
e
su
uggests mustt match betwe
een the curren
nt case instan
nces that we are creating w
with past
in
nstances. Leftt side column is for the exis
sting case insstances and tthe right side column is forr the
cu
urrent case. In the example shown abov
ve, BugArea
a, the area off the applicatio
on where the bug
is
s found of the potential dup
plicates should be same ass the current ccase. pyStattusWork, the
sttatus of the po
otential duplic
cates does no
ot contain Re
esolved, thatt is, the statuss of the dupliccates
is
s not resolved
d. And the description of th
he duplicate ccases contain
ns the descrip
ption of the cu
urrent
ca
ase.
2. Weighted
W
Matc
ch Conditions
s are used nex
xt, if the cond
ditions are ma
atching, then weights are
as
ssigned for ea
ach of the ma
atching condittion as config
gured. Note, th
he current case and existin
ng
ca
ase instances
s can be in eitther column. Current case properties ha
ave to be refe
erenced with tthe
ke
eyword Primary as mentiioned in the configuration
c
d
dialog box itsself.
104
3. Potential duplic
cates are iden
ntified based on the sum o
of the weighte
ed conditions.. In this exam
mple, if
an
ny of the two values of new
w bugs prope
erties, Severitty, Priority, an
nd Type matcches with the
ex
xisting cases, they are identified as pote
ential duplica
ates.
Next, we need to check for the duplicates in an appropriate
a
sttep of a speciffic stage of th
he case. Typiccally,
es after the initial screen off gathering ba
asic data. It ca
an be anywhe
ere in the casse
we check the duplicate
ough. Here is a sample forr a Program Fund
F
case. Th
he checking iss being done after the initia
al
stages tho
screen.
e flow is assoc
ciated with a step,
s
we can edit the flow tto include the
e Duplicate Se
earch smart
When the
shape. Inc
clusion of smart shape gives users the ability to conttinue or resolvved-duplicate
e. In the situattion
of cases identified as not
n duplicate, any other sha
apes can be a
added after th
he duplicate ssearch smart
t
flow, for more
m
functionality.
shape in this
At runtime
e, if the poten
ntial duplicates
s are found, users
u
are pro mpted. If we know that the
e new case is not a
duplicate, we dont nee
ed to select any from the lis
st of the pote ntial duplicate
es and can cllick continue. The
ves to the nex
xt step in the current
c
stage or in the subssequent stage. Or we can select one ca
ase
case mov
from the list and click Resolve as Duplicate
D
to resolve the cu
urrent case ass Resolved-D
Duplicate.
dard flow action, pyDuplica

ateSearchCas
ses, displays few propertie
es, including C
Case Status. This
This stand
flow action can be custtomized in ou
ur application, as needed, tto display mo
ore property va
alues for the end
dentify the co
orrect duplicatte.
users to id
105
Persistt a Case
We can create tempora
ary case insta
ances and the
en make it pe
ermanent after we know tha
at the case
his case instan
nce acts as a placeholder.. Lets say tha
at a customerr calls on the
instance is needed. Th
d inquires abo
out a productt that they are
e interested in
n purchasing. When we cre
eate a sale ca
ase,
phone and
we can crreate it as a te
emporary cas
se with the details of the cu
ustomer, prod
duct and product purchase
quoted. When
W
the actu
ual sale happe
ens, the temp
porary case ca
an be convertted to a perm
manent case.
In our exa
ample of duplicate bugs, without
w
the dup
plicate search
h configuratio
on, we are req
quiring the end
users to close
c
the duplicate bug ma
anually. With the
t duplicate search config
guration, we p
prompt the ussers
to identify
y whether the new bug could be a duplic
cate. In eitherr case, the ne
ew bug is crea
ated with a bu
ug ID
and is res
solved with a status
s
of reso
olved-duplicatte. We can im
mprove this prrocess with th
he creation of the
temporary
y case, when the new bug is created. No bug ID is id
dentified and n
nothing is savved in the
database.. All the data is transient. Once
O
the userr identifies tha
at the bug is iindeed not a d
duplicate, the
e
temporary
y bug case ca
an be made a permanent case.
c
This involves two steps
s. First we ma
ark the case instance crea tion as a temporary objectt. Then we pe
ersist
t make it perrmanent.
the case to
In the starrting flow of th
he case, we can
c select the
e Temporary object under the processs tab. The casse is
not actuallly created in the database
e if this option is selected.
In an appropriate step, we can have

e the flow with
h the Persist Case smart shape, which
h makes the
y case a perm
manent case. Now, it is stored in the dattabase.
temporary
Conclu
usion
As we saw
w, we can use
e Cascading Approval,
A
Duplicate Searcch and Persistt Case smart shapes to ma
ake
the proces
ss of getting multiple
m
appro
ovals, identify
ying potential duplicates an
nd converting
g temporary cases
into perma
anent case in
nstances, muc
ch easier with
h some simple
e configuratio
ons.
106
For the duplicate search, we need to configure a Case Match rule through the Case Designer as well.
Cascading approval can be based on an authority matrix which can be captured in a Decision Table rule
or it can be based on the reports to or group manager structure.
Whenever there is no need for a permanent case in the beginning of the case flow, we can create it as a
temporary object and once it is confirmed we can make it a permanent object by persisting the case
107
Screen Flows
A screen flow is a type of flow rule that is specifically used to break up data entry so that related fields
appear on a form and in a sequence of forms. For example, a credit card application form can be broken
into a set of forms one for personal information, one for financial information, one for employment
information, one for contact and security information, and one for any additional information.
We can configure how we want the forms of the screen flow rules to be presented to our users; tree
navigation, tabbed navigation or in the form of bread crumbs.
We can decide if we want our users to go through each form of the screen flow rules in sequence or if we
want them to be able to jump around from one step or screen to another screen either forwards or
backwards..
We can decide if we want the data to be saved on each form or only on the last form. Since the data
being captured is usually for a single person, the whole screen flow is routed to one operator.
Explain the purpose of the screen flows and how to create them
Configure different user interface options
Set sequencing and post action options
Describe persistence and routing configurations
Differentiate screen flows and regular flows and how some configurations are set differently or not
needed at all.
Purpose and Creation of Screen Flows

We use screen flows to capture data entry in a form, such as insurance claim information or a credit card
dispute.
Screen flows are often used to spread the gathering of related data across multiple forms within the same
screen. If we dont break the information being gathered into multiple forms, the data entry form can
become very long and then requires the user to do a lot of scrolling. To avoid this we divide the
information into multiple forms putting all related information on a single form. So we might have personal
information on one form and vehicle information on another form, etc.
Screen flows tend to be short in length and easy to complete in one sitting. All the information for a claim
is typically provided during a phone call or entered in a web application in one session.
A screen flow is run by a single operator, and drives a single, serial process. If there is a need for
multiple assignments then, we would create a regular flow instead of a screen flow.
We cannot create a screen flow as a step from the Case Designer. Instead, we create a flow rule first
using the Screen Flow template, as shown below. Once the flow is created, then the flow can be added
as a step in the Case Designer.
For example, in a Purchase Request application, we can have Enter Purchase Request as a screen
flow, since this is a data entry form, and can usually be completed by one operator, the requestor himself
or another person on behalf of the operator. We can create the flow rule using any of the explorers from
the New menu in app explorer or from the Create menu in data explorer or case explorer. We enter a
short description for the screen flow in the label field and then use the additional configuration options to
select Standard template for screenflow. We can change this template when we configure the flow. By
108
default, th
he rule name is the concate
enation of the
e short descri ption. If we w
want, we can cchange this default
rule name
e using the E
Edit link in the
e Identifier field.
We click the
t Create an
nd Open button to create and open the
e screen flow rule. In the D
Design tab of the
flow rule, we can see that the Categ
gory is Scree
enFlow.. Reg
gular flow rule
es have the ccategory as
s tab.
FlowStandard in this
f
to create have three d
distinct forms to capture the
e data we nee
ed;
We know that we wantt this screen flow
evant data, L ine Items w
what items are
e needed for tthis
Personal Information who it is for and other rele
a Address Information
I
where we ne
eed to verify th
he shipping a
address and e
edit it if a chan
nge
request, and
in the add
dress is neede
ed.
As we can
n see, each fo
orm is an ass
signment shap
pe in the flow rule. But, com
mpared to the
e regular flow
w
rules, thes
se are not truly assignmen
nts. The whole
e screen flow
w is an assignm
ment and is a
assigned to on
ne
user.
In regularr flows, we configure where
e the assignm
ment will be ro
outed and on the connecto
ors, we configure
flow actions we want users to perforrm on the ass
signment.
109
In screen flows, we con

nfigure the flo
ow action on the
t assignme
ent shape itse
elf and the flow
w actions
ed. Only one connector sta
arts at each sshape, and sin
nce
represent different partts of the data to be capture
that path is always follo
owed, no add
ditional information is need ed on the con
nnectors.
Config
guration of
o User In
nterface Options
We use th
he harness ru
ule to define th
he appearanc
ce and processsing of the fo
orms we are g
going to prese
ent to
the user. In a regular flow, for each assignment, we
w can have a different ha
arness rule fo
or different user
d
Sinc
ce the screen flow is an as
ssignment as a whole and is routed to o
only one user,, the
interface displays.
harness rule setting is configured on
n the start sha
ape for the w hole flow.
ness rule is se
et to TreeNavigation7, the user interfa
ace shows the
e steps of the screen flow a
as a
If the harn
tree navig
gation. This us
ser interface shows
s
the current step of tthe screen flo
ow highlighted
d in blue and
shows all the steps in the
t navigation
n tree. Users can navigate using the ba
ack and next b
buttons or by
n the menu ite
em in the tree
e navigation. When clicking
g on the tree navigation, users can jump
clicking on
multiple steps backwarrds or forward
ds.
110
If the harn
ness rule is se
et to TabbedScreenFlow7
7, the user in terface shows the steps off the screen fflow
as tabbed
d navigation. This
T
user inte
erface shows the current sttep of the scre
een flow high
hlighted in blue and
shows all the steps in the
t tab naviga
ation. The use
er can naviga
ate using the b
back and nexxt buttons or b
by
n a tab in the tab navigatio
on. Users can jump multiple
e steps forwa
ard or backwa
ard by clicking
g on a
clicking on
tab in the tab navigatio
on
ness rule is se
et to Perform
mScreenFlow, the user inte
erface showss the steps of the screen flo
ow as
If the harn
bread crumbs. This use
er interface shows the currrent step of th
he screen flow
w and the pre
evious steps in the
b display. This
s harness opttion of the UI display does not show the
e future steps.
horizontall bread crumb
Users can
n navigate using the back and
a next butto
ons to go bacck and forth. W
With the brea
ad crumbs, the
ey
can only go
g back, not forward.
f
So, clicking
c
on a bread
b
crumb in the navigattion, users ca
an only jump
multiple steps backwarrds.
111
The busin
ness can decide which use
er interface op
ption they wan
nt to present tto their userss. There is no
difference
e between the
ese three, as far
f as functionality, exceptt in the Perfo
orm Screen Fllow, where u
users
cannot jum
mp multiple steps forward. The default sequencing
s
o
options can also be configu
ured to behavve
differently
y, as well see
e in the next section.
Config
guration of
o Sequen
ncing and
d Post-Prrocessing
g Optionss
We can co
onfigure a screen flow so that
t
steps are
e run in a stricctly enforced sequence; that is, step 2 iss
executed after step 1, and
a step 3 ex
xecutes after step 2, and s o on. On the other hand, tthe screen flo
ow
etup so that stteps are run in any order, enabling
e
userrs to jump ahe
ead from step
p 1 to step 5. Its
can be se
also possible to custom
mize the sequ
uence so that the behavior is somewherre in between
n.
One of the
e simplest wa
ays to enforce
e a strict sequ
uence is to usse the Perform
mScreenFlow
w harness, ass
explained above. This user interface
e option show
ws a breadcru
umb trail that d
does not inclu
ude future ste
eps,
s simply nothing to click to
o jump to a futture step; insttead, the Nexxt button mu
ust be used. F
For
so there is
example, we cannot co
ollect credit ca
ard informatio
on, unless the
e shipping add
dress informa
ation step is
d.
processed
The Tabb
bed and Tree Navigation sc
creen flow sho
ows a represe
entation of the entire flow, and users ca
an
click the future steps to
o jump to them
m. This gives flexibility to u
users to fill in any step. Thiis is handy for an
e operator is entering
e
data
a provided by a customer o
on the phone. The custom
mer
application in which the
mation in an un
nsystematic way,
w
requiring
g the operatorr to jump arou
und and enter data
may proviide the inform
as provide
ed.
We can customize the Tabbed and Tree Navigattion screen flo
ows for the se
equence on a per-step bassis,
dcrumb trail checkbox.
c
Th is configures the step as a
an entry point, and
using the Enable link ifi using bread
es whether or not the step appears on th
he flow viewe
er. By default,, this option iss enabled for each
determine
assignme
ent; this option
n must be ena
abled for at le
east one assig
gnment in the
e screen flow. Lets unchecck it
for the Ad
dd Line Items
s step in the screen
s
flow to
o observe the
e effect on flow
w processing
g.
112
In this exa
ample, weve disabled the link for the A
Add Line Item
ms step, and a
as such, it do
oes not appea
ar in
the naviga
ation view. Th
he only way to
o get to the sttep is by clickking the next button on th
he previous sttep,
Enter Purchase Reque
est, as show
wn below.
s an entry poin
nt, and the ste
ep is represe
ented in the na
avigation view
w, we
When we select configure a step as
gure whether end users ca
an jump forwa
ard to it or nott. This is done
e by selecting
g the Only go
oing
can config
back che
eckbox. When
n this is set, th
he step is disa
abled, when tthe user is on
n a previous sstep. Users m
must
progress naturally to th
he step using the Next bu
utton.
113
In this exa
ample, weve enabled both
h the Enable link if using b
breadcrumb trrail and Onlyy going back
options fo
or the Add Lin
ne Items step
p. Now it appears in the na
avigation view
w; but it is gra
ayed out. The only
way to ge
et to the step is by clicking the Next button on the prrevious step, Enter Purch
hase Request, as
shown be
elow.
Without th
he purchase request
r
inform
mation such as
a when it is n
needed, and o
other relevantt information, we
cannot ad
dd line items to
t this purchase request. However,
H
if the
e user is on a subsequentt step, he or sshe is
allowed to
o go back to
o this step, fro
om the naviga
ation tree.
Lets revie
ew the key po
oints regarding use of the Enable
link iff using breadccrumb trail and Only goin

ng
back optiions.
When
W
Enable link if using breadcrumb
b
trrail is not sellected, the ste
ep does not sshow up in the
e
na
avigation flow
w listing, whetther we go forrward or backkward in the fllow. Hence, w
we cannot jum
mp to
th
his specific ste
ep. The only way
w is to use the back and
d next buttonss. This is true
e for all three
sttandard harne
ess configurations.
If only Enable link if using breadcrumb

b
trail is enable
ed for the step
p, the step sh
hows up in the
e
avigation flow
w listing wheth
her we go forw
ward or backw
ward in the flo
ow. Hence, w
we can jump to
o this
na
sp
pecific step, from
f
any prev
vious or forwa
ard steps. Forr maximum usser flexibility, we can use this
co
onfiguration, ifi our flow acc
cepts inputs in
n any order. IIn the case off PerformScrreenFlow, we
e
ca
annot go forw
ward through the
t bread crumb navigatio n.
114
If we enable bo
oth Enable link if using bre
eadcrumb tra
ail and Only going back, the step show
ws up
n the navigatio
on flow listing
g. The step is initially greye
ed out from a previous step
p and the onlyy way
in
we
w can go to th
he step is using the next button. Once the step is prrocessed and we have moved
be
eyond, we ca
an jump back to this specifiic step from a
any forward stteps.
In regularr flows, the ac

ctions are pos
sted when use
ers submit the
e flow action. But in screen
n flows, the flo
ow
action is on
o each assig
gnment shape
e and when na
avigating thro
ough differentt steps of the screen flow, the
actions arre not posted.. But, we can force posting
g to the serve r from any ste
ep, by selecting the check box
Perform post-processing when nav
vigating back. When the p rocess moves from the ste
ep, any valida
ation
sing rules liste
ed in the flow action are ru n.
rules and post process
w action AddLineItems, th
he validation rules
r
are liste
ed in the validation tab. Thiis validation m
may
In the flow
validate fo
or the presenc
ce of at least one line item
m and for each
h line item the
e presence off required field
ds.
The valida
ation rules run
n only if Perfform post-processing when
n navigating b
back is seleccted for the
assignme
ent shape of th
he screen flow
w.
We can apply a cost an

nd/or run a da
ata transform rule and/or r un an activityy rule as post processing.
n be listed in the action tab
b of the flow action.
a
These run only if P
Perform post-p
processing w
when
These can
navigating
g back is sele
ected for the assignment shape
s
of the sscreen flow. T
The post-proccessing data
transform can compute
e additional property values and post-prrocessing acttivity can perfo
orm other
processing.
115
Config
guration of
o Persisttence and
d Routing
g Optionss
The start shape has a Save on Las
st Step prope
erty option. W
When selected
d, the screen fflow is not savved
s is often used
d in tandem with
w the Allow
w Errors option, which wh
hen selected d
does
until, the last step. This
g even though
h errors are ra
aised until the
e screen flow is complete. This is handyy for
not prevent processing
ation in which
h the operatorr is entering data provided by a custome
er on the phone. The custo
omer
an applica
may proviide the inform
mation in an un
nsystematic way,
w
requiring
g the operatorr to jump arou
und and enter data
as provide
ed. It is only at
a the end when the system
m prevents th e operator fro
om continuing
g if errors werre
flagged th
hroughout the
e screen flow.
116
As a best practice, sele

ect the Save On last step box in most cases, to red
duce the number of case
C
opera
ations and his
story instance
es.
instance Commit
By defaultt, if save on last step option is not sele
ected, each fo
orm in the scrreen flow is co
ommitted to tthe
database.. Committing to the databa
ase and performing post-prrocessing acttions, which w
we covered in the
previous section
s
in this
s lesson are different.
d
Enab
bling post-pro
ocessing actio
ons run the po
ost actions su
uch
as validation rules, app
ply cost, data transform rules and activitty rules. Both database co
ommits and po
ostprocessing actions can
n be configure
ed independe
ently through Save on the last step boxx in the start
d Perform po
ost-processing
g when navig
gating back ccheckbox in th
he assignmen
nt shape
shape and
respective
ely.
Routing, like harness, persistence and
a error hand
dling, is also sset on the sta
art shape of a screen flow.
t all assignm
ment shapes in the flow; ro uting cannot be set on the
e individual
Setting it here applies to
ent shape, as the whole scrreen flow is considered on
ne assignmen
nt. Routing is ccovered in de
etail in
assignme
another le
esson.
[SF_Router.png]
Differe
ences bettween Sccreen Flow
ws and R
Regular Fllows
We have learned abou
ut some of the
e differences already.
a
Now
w, lets look at all the key differences bettween
ows and regular process flo
ows, so that we
w can undersstand why so
ome configura
ation is done
screen flo
differently
y and why som
me configurattion is not nee
eded at all.
Screen flow us
se assignmen
nt shape for th
he each step of the screen
n flow. But the
ese are not tru
uly
ssignments because
b
we are not assigning different ttasks to be co
ompleted by d
different end u
users
as
as
s we do in a regular
r
flow. We
W can consiider the whole
e screen flow
w as one task to be complete
an
nd hence it is
s routed to one user. So, we
w set the routting on the start shape, wh
here as in reg
gular
flo
ow, we set the routing on each
e
assignm
ment shape.
In
n a regular flow, from each assignment, the end userrs can take different action
ns, such as
ap
pprove or den
ny or hold the
e purchase request. So, in regular flow, flow actions a
are defined o
on the
co
onnectors and
d likelihood is
s configured on
o the connecctor. In a scre
een flow, there
e is no need tto
ta
ake multiple actions;
a
users just need to go between b
back and forth
h between mu
ultiple forms ffor
da
ata entry. Hen
nce the flow action
a
is defin
ned on the as signment sha
ape itself. Onlly one connecctor is
po
ossible from the
t assignme
ent shape and
d so no likeliho
ood can be set.
117
In a regular flow, we can configure harnesses for each assignment shape, as there could be a
need to show different relevant data for end users to make decisions when they get the
assignment. In screen flows, we configure harness on the start shape for the whole screen flow.
In the screen flow, the assignment shape does not have a ticket, an SLA or notify configurations,
as there is no need for any of them.
The screen flow is has limited number of shapes. Since the screen flow is executed by a single
user, external systems cannot be involved. Hence, there are no integrator shapes, and no
assignment service shapes.
Conclusions
We learned the purpose of the screen flow rules and how to create them. Screen flows are meant for data
gathering forms.
Screen flows can have tabbed, or tree or breadcrumbs navigation. We can configure screen flows to
process the steps in sequence, jump around freely or we can have a hybrid. Sequencing options are
configured in the assignment shape of the flow rule, which is a step in a screen flow rule.
The whole flow is considered one assignment for an operator and hence the configuration of the harness,
persistence and routing are set in the start shape of the screen flow, compared to settings in the
assignment shape for a regular flow.
118
Work Status
s a case instance (or work item) is instantiated and as it progress towards resolution, a work status
property tracks its state, whether open or resolved. The standard property for the case instance status is
Work-.pyStatusWork. Its values are restricted and controlled. This is also called work item status. Do not
confuse case instance status with assignment status which is a different property and not in the scope of
this lesson.
List the work status values
Explain how to update work status for case instances
Identify key standard functionality that leverages the work status
Work Status Values

Every case instance must have a status, which changes as the case instance progresses through stages
and flows associated with the steps. PRPC provides several standard work status values. We can also
create our own statuses.
There are four broad categories of work status values:
New (Identified with a green Flag -
Open (Identified with a blue Flag -
Pending (Identified with a red Flag -
Resolved (Identified with a checkered Flag -
) and
)
A New work status indicates that the case instance has just been created and has not been reviewed or
qualified for processing.
The Open status indicates that the case instance is being processed by the organization which is
supposed to process it.
The Pending status indicates that the responsibility of processing the case instance is currently with an
external organization. So the processing of the case instance is suspended until the external organization
or group has done its part.
A Resolved status is generally the final status for a case instance as it indicates the completion of the
work. Usually, a case instance in a resolved status is not modified by any later processing. Resolved
items are stored in the database and no longer appear on a work list or in a workbasket. Users can work
on a resolved work item; but first it must be reopened.
A few standard values are defined in each category. To access them, click Designer Studio > Process &
Rules > Processes > Status Values.
119
We can also define mo

ore status valu
ues through Field
F
Value ru
ules. When do
oing so, we ne
eed to make sure
ew, Open, Pe
ending and Re
esolved (usin
ng the initial
that we sttart each value with one off the words Ne
capital). From
F
any of th
he explorers, create a new
w rule instance
e under Data Model > Field
d Value.
Enter a la
abel and identtifier, which is
s the rule insta
ance name. H
Here we are ccreating an O
Open-Fulfillme
ent
Field Valu
ue rule instanc
ce under the SAE-HRServ
vices-Work cla
ass. Enter or select a value for the Field
d
name. This should be the
t property name.
n
In our case,
c
the pro perty name iss .pyStatusW
Work. Once this
e is created, we
w have a new
w status value to use in ou
ur application. It should now appear in o
our
field value
Status Va
alues list.
120
Use PR
RPC Stand
dards to Update Work
W
Status
Most flow shapes, inclu
uding Start, Assignment,
A
End
E and Smarrt shapes, pro
ovide a mean
ns to set or up
pdate
us. To set or update
u
the prroperty Work--.pyStatusWo rk value, do n
not use the p
property-set
work statu
activity me
ethod or use a data transfo
orm rule to se
et a value for this property,, but instead, use the
Properties
s panel of the
e flow shapes. The Status tab on the p
panel allows u
us to define th
he new work sstatus
value by providing
p
a va
alue in the W
Work Status field. This is th
he preferred w
way.
Here is a sample scree
enshot where we are settin
ng the work sttatus to Open in the assig
gnment shape.
As a best practice, the status for an assignment shape

s
should
d never be se t to Resolved
d because th
he
pdated when the assignme
ent is reached
d. If the statuss is resolved, the user is unable
work items status is up
m any addition
nal work on it..
to perform
When the
e work status is set on a sh
hape, we will see
s the statuss flag indicato
or on the conn
nector leading
g to
that shape
e in the flow rule.
r
121
When the
e case instanc
ce advances to
t a shape tha
at sets the sta
atus, PRPC a
automatically updates the sstatus
of the worrk item to the value defined
d for that shape. The appro
opriate flag in
ndicator appears next to th
he
work statu
us value.
The flow End
shape provides
p
two fields: Flow Result
R
and W
Work Status. Make sure tto use Work
Status fo
or this purpose
e. If the flow belongs to the last step off the resolutio
on stage, wo
ork status is one of
the Reso
olved status field
f
values, such
s
as Reso
olved-Comple
eted, Resolvved-Withdraw
wn, Resolved
dCanceled etc.
ase, PRPC us
ses the stand
dard activity W
Work-.UpdateStatus to upd
date
When we set the work status of a ca
the value of the properrty Work-.pyStatusWork.
vered in more
e detail in the Activities lessson. The brieff discussion tthat follows
Note: Actiivities are cov
explains how
h
PRPC us
ses the Updatte Status activ
vity to update
e the work sta
atus for a case
e.
An activity
y is a sequence of structurred steps, des
signed to auto
omate some a
aspect of casse processing. The
activity Work-.UpdateS
W
Status, which can also be called
c
from a fflow utility shape, changess the propertyy
122
directly an
nd calls some
e standard acttivities such as
a Work-.Res olve if the sta
atus value is o
one that starte
ed
with the word
w
Resolve
ed.
There are
e also a few sttandard rules which call the Work-.Upda
ateStatus acttivity. Activitie
es such as Wo
ork.WorkBas
sket and Work
k-.Worklist wh
hich place an assignment iin a workbaskket or worklistt respectivelyy, also
call Work--UpdateStatus.
Key sta
andard fu
unctionalities which levera
age the W
Work Status
When a case instance//work item sta
atus is first up
pdated to a R
Resolved sta tus, PRPC ca
alls the Resolve
utomatically. This
T
activity activates
a
the Status-Resollved ticket. A
Another particcular standard
d
activity au
ticket is A
AllCoveredRe
esolved. If a subcase
s
statu
us becomes R
Resolved, the
e immediate p
parent case iss
checked. These standa
ard tickets are
e covered in the
t Tickets llesson.
PRPC als
so automatica
ally maintains three standard properties in Work-class. They are
pyElapsed
dStatusNew, pyElapsedStatusOpen and pyElapsedS
StatusPending. These properties contain
cumulative time in seco
onds that a ca
ase instance has had a sta
atus value tha
at started with
h the word New,
espectively.
Open orr Pending re
123
Conclusion
The work status conveys important information about the progress of the work item towards completion,
such as whether the work item is New, Open, Pending or Resolved. The work status can be set on any
shape in a flow. When the case instance reaches that shape at runtime, its pyStatusWork property is
updated with the status value from the shape.
If the status of the case instance needs to be updated outside of the flow rules, we can use the standard
activity Work-.UpdateStatus.
Some standard tickets and properties leverage the work status value.
124
Worrk Partie
es
A Work Party is a person, organizattion, or busine
ess involved o
or interested in some way in the work ittem or
erefore, they are
a kept inforrmed as the ccase instance progresses tto completion. In
in a case instance. The
e use corresp
pondence to in
nform the inte
erested partie
es. Correspon
ndence rules, which include
e
PRPC, we
email, ma
ail or phone te
ext, are ONLY
Y sent to entities identified as work parties.
A case ins
stance may have
h
multiple work
w
parties. As an examp
ple, lets conssider a case in
nstance creatted
because of
o a customerr complaint. The
T customer and her spou
use, the custo
omers lawyerr and the
organizatiions lawyer could
c
all be involved or inte
erested in the
e complaint. In
n that case, th
hey are define
ed as
work partiies for the cus
stomer complaint case instance or workk item.
In PRPC, Work Parties
s are part of th
he Process ca
ategory and a
are instancess of the Rule--Obj-WorkParrties
rule type.
At the end
d of this lesso
on, you should
d be able to:
Explain how to
o configure a Work
W
Party
Describe
D
Work
k Party Data Structure
S
Add
A a Work Pa
arty to a case
e instance
Work Party
P
Con
nfiguratio
on
A work pa
arty representts an entity that needs to be
b notified abo
out the progre
ess or status of work.
When a case is created
d as part of a new applicattion through tthe Applicatio
on Express wizard or added
d to
c
addition menu in the case explorer, the system creates a de
efault
an existing application through the case
he newly crea
ated case. This rule can ea
asily be config
gured from the
e Details tab of the
Work Partties rule for th
Case Des
signer.
125
Clicking on
o the edit link
k displays the
e Parties form
m for us to ed
dit or delete e
existing roles o
or add a new
w role.
By defaultt, PRPC adds
s three roles, Customer, Owner, and Intterested with the appropria
ate default
properties
s values in the
e Work Partie
es rule instanc
ce for the casse on which w
we are working
g. This can be
modified to
t suit our bus
siness needs. Shortly, we will see whatt each field means and how
w these can b
be
modified.
w defined reprresents a pers

son or an entity that can pa
be interested in the case
Each row
articipate or b
instance progress.
p
Eac
ch row concis
sely describes
s a role and th
heir part in the
e process.
A role can be standard

s
roles
s such as Ow
wner, Custome
er etc., or we
e can create m
more specific roles
su
uch as LoanO
Officer.
The Descriptio
on is the uniqu
ue name for each
e
of the ro
oles we see diisplayed in the user interfa
ace.
The Party Type

e field referen
nces the data class that co
ontains the prroperties welll use to store the
work
w
party info
ormation. We will see the details
d
of the P
Party Type la
ater in this lessson.
The Model field

d is optional and
a is a data transform rul e that definess the initial prroperties of ou
ur
work
w
party whe
en adding the
e work party to
o a case insta
ance.. It causses the system
m to set initial
va
alues for som
me properties of the work party. We will llearn more ab
bout this laterr in this lesson.
The Display on
o Creation checkbox
c
can be selected tto if we want the work partty to appear a
at
untime when the
t case insta
ance/work item entry form first appears.
ru
present in every new case

The Required field indicate
es that this pa
arty must be p
e instance/work
em.
ite
The Allow Multiple check box,

b
when selected, allowss for the addittion of multiplle instances o
of a
ply specify the
e role you wan
nt to repeat in
n the field. Th
his, for examp
ple, is
siingle work party role. Simp
us
seful if we wa
ant to add dep
pendents to an
a auto or life insurance po
olicy.
When we open the cas

se type rule, we
w notice thatt it referencess a work parties rule name
ed
ManagementD
Default.
pyCaseM
Opening that
t
Work Parrties Rule, we
e see the follo
owing informa
ation that we h
have configurred in the parrties
form earlie
er:
126
Though we
w can edit, ad
dd or delete role
r
entries in this rule form
m directly, it iss easier to use
e the Case
Designer.
Work Party
P
Datta Structu
ure
The Party
y Type on the configuration
n form of the Case
C
Designe
er, can be one of the follow
wing:
Party/Com
mpany, Party//Government,, Party/Opera
ator, Party/No n-profit, Partyy/Person or itt can be any o
other
custom pa
arty that you create.
c
Party Typ
pes are define
ed in PRPC as
s instances of the Data-Pa
arty class or o
one of its sub--classes. Proccess
Command
der organizes
s the Data-Pa
arty data into meaningful
m
ca
ategories.
Data-Party-Co
D
m for busines
ss organizatio
ons, and the P
Party/Compan
ny Party Type
e roles are
in
nstances of th
his class.
Data-Party-Go
D
ov for Governm
ment organiza
ations, and th
he Party/Gove
ernment Partyy Type roles a
are
in
nstances of th
his class.
Data-Party-Op
D
perator for PR
RPC applicatio
on users with an Operator ID record, an
nd the
Party/Operatorr Party Type roles
r
are insta
ances of this class.
Data-Party-Org
D
g is reserved for the non-p
profit organiza
ations, and the
e Party/Non-p
profit Party Tyype
ro
oles are instan
nces of this class.
c
Data-Party-Pe
D
rson is design
ned for any person who is not however a PRPC app
plication user, and
th
he Party/Person Party Type
e roles are instances of thiis class.
We can create our own

n sub-classes
s (either direct or pattern in
nherited from Data-Party) if we need to
m
categorie
es of work parties for our application,
a
likke Employee, Manager or Dependent as
expand more
shown be
elow.
127
The drop
p down for the
e model shows the data tra
ansform rules.. The data tra
ansform rules defined in the
class related Party Type field or in one of its parent class sho
ow up as entrries in the Mo
odel drop dow
wn.
The stand
dard data tran
nsforms corresponding to the entries in the Model dro
op down appe
ear in the DattaParty clas
ss.
128
A substan
ntial set of Wo
ork party prop
perties are delivered with P
PRPC. A few properties are
e required, su
uch
as:
px
xPartyRole, which
w
identifie
es the role of the
t party.
py
yWorkPartyUri, which uniq
quely identifies the party.
py
yEmail1, whic
ch Pega 7 use
es to send no
otifications to the party. If w
we dont proviide a value fo
or
py
yWorkPartyUri, Pega 7 uses pyEmail1 to
t determine a value when
n validating th
he work party
us
sing the stand
dard activity Data-Party-.V
D
Validate.
Some com
mmonly used though nott required properties inclu
ude pyLastNa
ame, pyFullName, and
pyAddress.
In the CurrrentOperatorr Data Transfo
orm rule, the property pyW
WorkPartyURI is set to the current opera
ator,
using the property pxR
Requestors py
yUserIdentifie
er. Data trans form rules are
e covered in d
detail in a diffferent
lesson.
Add a Work
W
Parrty to a Case
C
Insta
ance
Once a work party rule
e is created an
nd configured
d for a case, w
we have multiiple ways to a
add it to a casse
instance.
In the parrties configura
ation of the Ca
ase Designerr, if we marke d a Party Rolle as Displayy on Creation, (or
Required
d, which auto
omatically marrks Display on
o Creation) the work partty is created w
when the casse
instance is created.
In the exa
ample shown for the Case Designer con
nfiguration, th e Owner Ro
ole is marked as Display o
on
Creation. The model selected
s
for th
his role is the CurrentOpe rator data tra
ansform rule. It sets the
pyWorkP
PartyUri as th
he current ope
erators userID
D. We can ve
erify that in the
e clipboard pa
age on the
pyWorkPa
arty page crea
ated under py
yWorkPage.
129
We can se
ee the Work Parties
P
inform
mation in the standard
s
perfo
form harnesse
es on the righ
ht hand side a
at
runtime off the case ins
stance creatio
on.
Here, own
ner is the Work Party role name.
n
We ca
an click the A
Administrator link to look a
at work party
details.
d more work parties

p
or upd
date existing w
work parties tto the case
We can click the Edit button to add
a runtime.
instance at
130
In the cas
se type rule, starter
s
processes flows are
e listed under the Processe
es tab.
We can open the starte

er flow rule lis
sted here and
d uncheck the
e skip create harness field
d. Creates a new
ect appears and
a indicates to us that this
s flow is the sstarter flow rulle. Work Partties listed here
e in
work obje
the flow ru
ule is the sam
me that is liste
ed in the case
e type rule. Th
he rule listed iin the case tyype rule takess
precedenc
ce if a different rule is referenced in this
s rule.
131
If we unch
heck the Skip
p create harness, then wh
hen the case instance is instantiated, th
he new harnesss be
displays first, before the actual case
e is instantiate
ed.
a new work
k parties in thi s new harnesss as well, such as the perrform
We can edit existing work party or add
harness.
d or some oth
her harness iss used and if we dont have
e the capabiliity to
If the perfform harness is customized
add a worrk party at run
ntime, we can
n either includ
de the Work- pyWorkParrtiesWrapper section rule
wherever we want or we
w can use the AddParty flow action a s local action
n at the assign
nment level,th
he
vel or the cas
se level. Below
w is the config
guration at the assignment level local a
action.
flow level,, the stage lev
At runtime
e, from other actions menu
u, we can click on the Add
d a party link and this bring
gs the same
section to
o edit existing parties or to add new partties just as we
e saw before in the new ha
arness and th
he
perform harness.
132
Once the work parties are added to a case instan

nce, we can ssend correspo
ondence or ro
oute an
ent to the parties. Correspo
ondence and routing are co
overed in othe
er lessons in this course.
assignme
Conclu
usion
The Work
k Parties rule is an instance
e of Rule-Obj-WorkPartiess, while the W
Work Party Role listed in the
e rule
is an insta
ance of Data-Party class or one of it sub
b-classes. Th ere are stand
dard roles ava
ailable that we
e can
add to the
e work party rule. PRPCs flexibility
f
allow
ws us to exten
nd Data-Partyy and create our own workk
party roles
s as needed.
A work pa
arty role can be
b added to any
a case insta
ance by config
guring the parties configurration in the C
Case
Designer, or by using the
t standard perform
p
harne
ess, new harn
ness, or by in
ncluding pyWo
orkPartiesWra
apper
ule or by using
g the AddParrty flow actio
on.
section ru
Work partty is any entity
y that is intere
ested in the progress
p
of th e case. Theyy can be notified and/or the
ey
can be inv
volved in proc
cessing an as
ssignment.
133
Module 04: Data Model
Building a Solid Foundation
Controlling Data with Properties
Source Your Data with Data Pages
134
Building a Solid Foundation

The data model is a critical part of every application. The data model defines how the case data is
persisted. However, it also defines data that is not persisted with the case for instance temporary data
such as flags for hiding UI components and reference data needed to process the case.
Explain the Fundamentals of the Data Model
Explain the Roles of Properties
Explain How Inheritance Works with the Data Model
Discuss Tips and Best Practices for Data Modelling
Construct a New Data Structure
Explain the Fundaments of the Data Model

Welcome to the Data Modeling Lesson. In this lesson we will look at the key concepts involved in the data
model. The data model is a critical part of every PRPC application. It is used by rules, user interface,
processes, reporting and basically all other parts of an application. The data model defines the attributes
and relationships that make up the objects that PRPC uses to process work and manipulate data.
The process of defining the data model is critical to a successful application. A good data model should
define entities that can represent business objects in a way that can be reused by other applications. The
model should be understood by both architects and business users. In the end the model will be the
roadmap for the classes and properties that will be used by the rest of the application.
Classes are the fundamental building blocks of almost everything in PRPC. Classes define the logical
entities or objects that an application will work with. While many rules can apply to a class it is the
property rules that define the attributes of the class and are critical to data modeling.
Properties can be as simple as a single value, for example, FirstName. Properties can also be complex
and represent a list or another class all together.
Here we see that the Person class has single value properties such as First Name and Last Name and a
property Address that itself has multiple properties. Address is a complex property known as a page.
The concept of pages is very closely related to classes. Pages are instances of classes that are stored in
memory on the Clipboard.
The clipboard is a memory based container for pages assigned to each user session. While there are
many other important aspects regarding the clipboard, for this lesson, we will simplify it as a container for
pages.
A page is always defined as being of a specific class type. The class type defines the properties that CAN
be defined on the page.
Pages can be top-level pages or embedded pages. The term top level page refers to pages that have a
name and are not embedded in any other pages. The most common example of a top level page is
pyWorkPage.
Embedded pages are embedded into other pages as properties themselves. We will look at this concept
in more detail shortly. When trying to understand the relationship of a class and a page it is important to
remember that the class is the definition and does not contain values for its properties where as the page
is the actual instance.
135
To illustrate this point, we have a class Person with 3 properties defined FirstName, LastName and
middle Initial. This is the definition of a Person, not an instance of one. The pages, Person1 and Person2
are both instances of the class type person. Each can have different values and set a different subset
of the defined properties.
Since these topics are so important to building PRPC applications lets review the concepts from the top
down. The clipboard is a per user session area of memory containing top level pages. Each page is an
instance of a class. The class defines the properties that can be set on the page. The property can be a
single value, for example FirstName = Joe, a page of a specific class (for example, AddressInfo) or
represent a list of items (for example, LineItems()).
Explain the Role of Properties

While classes are the building blocks for your application, properties are both the glue that connects the
blocks as well as the details that make them complete. Lets look at the different types of properties.
A single value property is the most fundamental type of property; it represents a single value of a specific
type, for example a string, decimal or date. We will go over all of the available types in the Property
lesson.
A page property allows you to embed a group of properties inside of another page. A property of type
page is sometimes referred to as an embedded page. Proper use of pages is critical to building reusable
assets.
A value list is an ordered list of single value properties. The value list is subscripted using numeric values
starting at 1.
The Value Group is an unordered list of single value properties. The value group is subscripted using
strings.
The page-list and group are similar to the value list and group except they represent a list of pages. Since
most applications require complex structures, page lists and page groups are much more common than
value lists and groups.
Finally, PRPC 6.2 SP2 introduced a new concept of Linked Properties. Linked Properties act as pointers
to database persisted entities. The details of linked properties are beyond the scope of the lesson.
Note, there are a few other types that are used for Java integration; we will not focus on them in this
lesson.
One important decision we have to make is choosing between the group or list concept. Lists are
particularly good when we always want to display or process all of the items in a list. Their subscripts do
not carry much context as they are just numbers. However, when displayed they are guaranteed to show
up in the same order. On the other hand, groups have string subscripts which can add context to each
page, making direct lookups easier. However, when looping over a page group the order in which the
group is traversed is not always consistent since it is built on top of a hash table. When deciding between
page group or page list, consider if you will be working on a specific item in the collection, in which case a
group is helpful, versus all items in the collection, in which case a list may be more appropriate.
Another important concept is that even though we often refer to the Data Model and Data classes,
properties are also defined on work classes. Single Value properties can be defined to represent data
about the work (such as status). Pages, Page Lists and Page Groups are used to embed data classes so
that work can be performed on them. Lets look at an example.

Lets say we want to create an Order Information class that is used for different types of orders within our
application. First we define the Data class that will hold our properties. Since we will instantiate but not
136
persist these pages we can define them as concrete and not belonging to a class group. Next we
complete the history tab.
We can see that we now have a new class, but no properties defined on it.
Now we create properties in two different manners. You can create a single property by right clicking and
selecting NEW | Data Model | Property.
Here we can fill out the information to create a new property.However, when creating a new class it is
often faster to use the Define Properties wizard to bulk create properties. Here we can quickly add three
new properties and set their type. We will add 3 new single value properties.
After clicking Finish, PRPC will create the properties for us. Here we can see our new properties in the
Application Explorer.
We now have a new class and properties defined, however our work types have not defined a
relationship to our new class.
What we need to do is create a property to reference our newly created class.
We will call the property OrderInformation. Since we only need one order information page per work
object we choose the page property mode and set the class to our newly created OrderInfo class. Now,
we can see the OrderInformation page and the properties we defined.
In many situations it will be very useful to quickly understand the data model of an application that is in
development or already developed. PRPC has two landing pages that provide a more complete view than
the Application Explorer.
Click on the Pega button, then select data model > classes & properties > property tree. The Property
Tree tab shows the properties defined and their type for a given Applies To class, here our general work
class. We can expand OrderInformation to see the properties of the OrderInfo class as well.
A number of other options also exist in order to help customize the view to show the appropriate
properties for a given application.
The Class Relationship tab shows the relationship of just the page, page list and page group properties.
This can be helpful as a high level relationship model.
Now that we have created the classes and property definitions we also must understand how to actually
create pages of the classes and instantiate properties on those pages. In most cases PRPC will manage
the creation of pages for us. Pages can be created to represent new objects, for example when we create
new work, or to represent an already persisted object, such as opening existing work. PRPC also creates
embedded pages for us whenever the property is referenced.
From a more programmatic standpoint we can explicitly create new pages using Page-New or bring an
already existing instance onto the clipboard as a page using Obj-Open. There are many other ways
pages get created but these are some of the most common ones.
Property instantiation is even easier than pages. PRPC creates properties as they are used or
referenced.
There is no constructor or Property-New.As business rules, UI forms or other rules such as transforms
reference properties PRPC automatically creates them.
Unlike many other programming languages, PRPC does not allocate memory for defined properties until
they are used; this allows us to inherit many properties without the associated cost.
137
Explain How Inheritance Works with the Data Model

Another important aspect of the data model to understand is how the data model differs but is related to
class structure and inheritance.
Inheritances and the class model, whether on work or data classes, represent a form of specialization.
They allow subclasses to inherit the properties or rules the parent class has defined. Inheritance
represents an is a type of relationship. For example, AutoLoan is a type of Loan. All of the properties
defined for a loan are available, through inheritance, to the AutoLoan class.
On the other hand when looking at the data model and the embedded page or page list properties we are
seeing a has a relationship. For example, A loan has a borrower. A borrower is NOT a type of a Loan
but it is an entity that the loan uses or references.
This is a very important, and sometimes a misunderstood concept. Lets reiterate it with an example. We
will use a very simplified description of a general Loan work type that has two specializations, an Auto
loan and Property Loan. All loans have a Credit Evaluation structure used by the underwriting process of
the loan. The Credit Evaluation itself has specializations for Personal and Corporate Evaluations. This
description can help us draw out a possible class structure AND data model.
Starting with the class structure we can use pattern inheritance to specialize for the Property and Auto
classes. Lets define a few properties at the Work-Loan class. The properties will also be available, via
inheritance, to the Property and Auto classes along with any properties defined at those classes. The
same holds true for the data classes as well. Remember in all of these cases, the sub class is a type of
the parent.
The data model defines the relationship BETWEEN the loan and the credit evaluation. Here we can see
that the CreditEvaluation page is embedded inside the loan object as a page of type Data-CreditEval.
A common mistake is to build out the has a relationship in the class structure. For example, Work-LoanCreditEval. A loan has a credit evaluation; a credit evaluation isnt a type of loan.
Discuss Tips and Best Practices for Data Modeling

Keeping the concepts of class structure and the data model clear in your head is critical to completely
mastering PRPC. It is also important to understand how the runtime data structure can differ from the
design time structure since pages can be instantiated as sub classes of their definition. For example the
CreditEvalution page property can be instantiated as either a personal or corporate subclass.
Another tip is that when designing a new application focus initially on the relationships of the classes,
which classes will use inheritance and which will become embedded pages, page lists or groups.
Remember to review inherited properties and out of the box classes to ensure that any already defined
properties are used.
When designing your work and data structures try to group your properties into logical data classes rather
than as direct work properties. This helps promote reuse by allowing entities (such as an account, product
or person) to be reused outside of the specific work being performed.
To maximize reusability it is also important to define the data structures at the right layer of the layer cake.
More generic structures such as account or contact are good candidates for the enterprise layer rather
than the framework or implementation layer.
Last but not least, use page lists and groups over value lists and groups. While they may seem useful at
the time, value lists and groups can only store a single value. As requirements change it is very beneficial
to have page structures that can easily adapt to new requirements without having to change the data
model.
138
In conclusion, the PRPC data model is very powerful at representing the structures that our application
and business will need to interact with. Understanding how to take full advantage of the PRPC data
model is one of the first steps to building a great system.

We can use the Data Explorer to add or remove data types.
Deselecting a data type removes it from the Data Explorer, but the underlying rules are not deleted.
Select view all to display all the data types available.
Select Create New to add a new data type to the application. We want to add a data type address.
139
The wizard creates the class specified in the ID field using the given details.
In the next step we can add properties to the data type.
A property can be defined as single value, value list, or value group in which case the type must be
specified or as a page, page list, or page group in which case we need to specify the page class.
In next step we define how we want to display the properties.
In the final screen an overview of the properties to be created displays. Click Submit to create the
properties.
Properties can also be created directly from the Application Explorer. Use New link to create a single
property or the Create properties link to create several properties in a similar way that we created them
using the Data Explorer.
140
In many situations it is very useful to quickly understand the data model of an application that is in
development or already developed. There are two landing pages (DesignerStudio > Data Model >
Classes & Properties) that provides a more complete view than the Application Explorer.
The Property Tree tab shows the properties defined and their type for a given Applies To class, here we
see our general work class.
The Class Relationship tab shows the relationship of just the page, page list and page group properties.
This can be helpful as a high level relationship model.
141
Now that we have created the classes and property definitions we must also understand how to actually
create pages of the classes and instantiate properties on those pages. In most cases PRPC manages the
creation of pages for us. Pages can be created to represent new objects, for example when we create
new work, or to represent an already persisted object, such as opening existing work. PRPC also creates
embedded pages for us whenever the property is referenced.
From a more programmatic standpoint we can explicitly create new pages using Page-New or bring an
already existing instance onto the clipboard as a page using Obj-Open.
There are many other ways pages get created but these are some of the most common ones.
Property instantiation is even easier than pages. Properties are created as they are used or referenced.
Conclusion
Understanding and taking full advantage of the data model is essential in building an application. Take
business requirements, such as reporting and case persistence but also flexibility and scalability into
account when building the data model.
Now, we understand the fundamentals of data modelling. We understand the role properties have and
how the data model is related to the class structure and inheritance. Finally we know the best practices
and how to effectively construct a new data structure.
142
Controlling Data with Properties

Properties are the fundamental rule type used to define data structures for work objects and the data on
which the work is performed. Properties define the attributes that make up an object. They can be used
to represent simple values such as a name or an amount; or more complex structures like an account.
Properties apply to a specific class and can be inherited by descendant classes.
Compare the Property Type Options
Compare the Data Access Options
Configure Display and Validation Options
Configure Advanced Settings
Compare the Property Type Options

Lets take a look at the property rule form and some of the settings we can define for a property.
The first and most important part of defining a property is to select the appropriate property type.
The most straightforward mode is Single Value, which is used to represent simple, scalar values, for
example, a price.
The value list and value group modes represent collections of single value properties. The value list is an
ordered list subscripted by a number and the group is subscripted by a string term and is unordered.
The page type allows a single property to represent a collection of properties as a page of a specific
class. This is very powerful as it allows us to embed and reuse complex data structures in various parts of
an application. For example an Account structure could be used by multiple work types.
Page List and Page Group are similar to value lists and groups in how they are subscripted but their
instances represent pages rather than single values. Page Lists and Page Groups are generally
preferred over Value Lists and Value Groups because they are more flexible.
143
There are also a number of Java related types; these are used when interfacing with external java
libraries or beans. They are not covered in this lesson.
Each property type has additional options associated with it; lets look at Single Value first. A property of
mode Single Value also has a type. The type represents the kind of data that is valid for that property.
Common types include Text, which can store strings, a variety of numeric types such as Integer, Decimal
and Double as well as temporal properties such as DateTime, Date and TimeOfDay. Each type is well
documented in PRPC help and can be reviewed there.
The Value List and Value Group have the same options as Single Value, which makes sense since Value
Lists and Group are just a collection of single values.
Now lets look at the options for Property Mode. First we see that instead of defining a type, like text or
integer, we instead define a Page class. The class determines what this page will represent.
For example, if we enter our supplier class then our property will be a supplier. We can reference
properties of the line item class, for example SupplierID, using the dot notation. For example
.Supplier.SupplierID.
Like the Page mode, the PageList mode requires a Page Definition. This property now represents a list
of Line Items rather than a single line item. The list can be referenced using the dot notations with a
numeric subscript, for example .LineItems(1).ProductID.
The PageGroup mode is similar to the PageList except that the subscript is a text string and the lists
order is not guaranteed. PageGroups can be referenced using a string subscript, for example .Vendors
(VendorA).VendorID. PageGroups are useful when a specific item in the list needs to be retrieved based
on a key.
Compare the Data Access Options

The options for Data Access differ if the property is of single value or page type.
Single Value
For a single value type property there are two data access options; Manual and Automatic reference to
class instances.
Select Manual if the user adds data to this property through the UI or if data transforms or other rules
may be required to manipulate the value.
144
Select Automatic reference to class instances (linked) to establish a direct relationship to a single
instance of a different concrete class also known as the target.
At runtime an instance of the specified class is retrieved in read-only mode, hence without a lock. In this
example we are showing the standard pxCreateOperator property.
If there is only one key, the value of the source property becomes the key used to open the object at runtime. If there is more than one key, the key properties become input fields where users may enter values
or properties that contain the appropriate values at run time.
We can use the linked property as a Page property in property references. For example, we can
reverence the name of the create operator as .pxCreateOperator.pyFullName in a case type.
Help contains a list of standard linked properties, see Atlas Standard linked properties.
Page
For the page type property there are three data access options: Manual, Refer to a data page, and Copy
data from a data page.
Select Manual if the user adds data to this page property through the UI or if data transforms or other
rules may be required to manipulate the value.
Use Refer to a data page to point to a data page. The data is not persisted with the case, but instead is
always fetched when needed. We use this setting if we want the most up to date information, such as a
customers address.
145
Use Copy data from a data page to copy data from a data page to the property. The data is not be
reloaded unless one of the data page parameters changes. The data is persisted with the case. We use
this setting if we want a snapshot of the data, such as the details of an insurance policy.
How to configure a property to use a Data Page is covered in more detail in one of the Data Modelling
lessons.
Linked Property vs Data Page

The best practice is to use data pages over linked properties whenever possible. Data pages are more
flexible with both reference and copy options. In addition, the data source can easily be changed for
example, from database to SOAP.
Linked properties should only be used if we can guarantee that well only ever need read-only access and
that the objects will always live in a database.
Configure Display and Validation

The Display and Validation options are available when single value property is selected.
The UI Control field is populated with a default control for the specific property type. For example, if we
select Time of Day the control automatically gets set to pxDateTime.
146
The control listed on the property form defines how the property displays in the UI if Inherit from
property is selected.
The Table Type field provides validation against a list of valid values. The list is determined by the table
type. This validation occurs both at runtime and design time when saving business rules.
Local List allows us to define a simple list of strings that define the valid values.
Prompt List uses two values, a standard value, the value stored on the clipboard and database and a
prompt value, the value shown to users.
For example, we can enter Approve for the Standard value and Approve Order for the Prompt Value.
This allows us to use Approve in our rules but have the user see a more descriptive label. This provides
flexibility in separating the display from the rule logic.
Local Lists and Prompt Lists are useful for simple cases however they do not allow for reuse as the list is
associated with a single property.
Class Key Value allows us to specify a class whose instances become the allowed values. The class
key value requires us to enter a validation class, which is the class whose instances are used for
validation.
For example, if our property was to represent a workbasket defined in the system, wed enter DataAdmin-WorkBasket. Clicking preview shows us how this will be rendered. This is the list of defined
workbaskets. The actual field displayed is the Key property for the class specified which is why the table
is called Class Key Value.
147
The Subset Name field is used when the class has a multipart key and we wish to use only a subset of
values. For more details review the help file.
The Display Only (Not For Validation), option allows us not to validate against these values; this is
commonly used with localization.
The last table type we will review is the Field Value. This table type allows us to utilize field value rules
which have the added value of being fully localizable.
Since field values are rule resolved we supply the Class first. Here we are going to use the pyChannel
field values defined at baseclass.
You may have also noticed a table type called Remote List, this table type is deprecated and should not
be used.
All of the table types can be used with the Dropdown control. Select As defined on property as the list
source type.
Another powerful aspect of using table edits is validation in certain business rules that might be
delegated, such as decision tables.
148
Configure Advanced Settings

There are also many advanced features that can be set on a property definition. These options are
dependent on the property mode and type set on the general tab. Here we can see the options for a
Single Value, Text property.
Max Length allows us to set the maximum length, in characters, of the field. Any attempt to set the string
to a longer value results in a validation error.
Expected Length is used by some UI controls to set the width of a text field. No warning or validation
error occurs if more text is entered.
Override Sort Function allows us to specify a custom sort function to be used when sorting a list.
Access When setting is used for encrypted text to determine when the clear text value can be accessed.
Edit Input allows us to set the Rule-Edit-Input rule that applies to this property. Edit Inputs is used to
format a value when it is entered on a user screen. This formatting occurs on the server side.
Use Validate specifies a Rule-Edit-Validate rule that is applied when user input from a screen is sent to
the server. This rule is applied after the edit-input and can add validation messages to the property.
Column Inclusion provides guidance to database administrators (DBAs) as to whether a column should
be exposed for direct reporting. This field does not have direct impact on the runtime behavior of the
system.
If we want the value of this property to be omitted when a page containing the property is committed to
the database we can select Do not save property data. Marking appropriate properties improves
performance by reducing the size of the Storage Stream property value.
149
Select Cannot be Declarative Target to prevent a property from being used as a declarative target. This
is helpful to indicate to other architects that a property should not be used as a declarative target.
Select Cannot be included as Input Field to prevent users from directly entering a value for this
property in an HTML form. This can be useful as an additional security measure for critical properties.
Select Allow use as Reference Property in Activities to make this property a reference property that
can link to a source property.
Select Cannot be localized in UI controls to prevent this property from being localized.
A qualifier is essentially metadata about a property. There are a few standard qualifiers, such as
pyDecimalPrecision.
Page Properties share many of the advanced options with the single value property, but also have a few
additional ones.
Select Validate embedded page to validate this pages data, even though it is embedded. In almost all
cases this should be left checked.
The java page option is specific for working with Java objects.
Conclusion
A property defines and labels a value that is associated with a class. The first and most important part of
defining a property is to select the appropriate property type mode. However, property definitions can also
be used to load data, define consistent presentation, access and validation of data across an application
or even an enterprise.
Now, we understand the fundamentals of data modelling. We understand the role properties have and
how the data model is related to the class structure and inheritance. Finally we know the best practices
and how to effectively construct a new data structure.
150
Source Your Data With Data Pages

Introduction
With just about every application using data in one way or another, data pages play a primary role in
sourcing data.
Data pages offer lots of flexibility. Their on demand source data can originate from virtually anywhere and
can be configurable to be refreshed with every interaction, or cached indefinitely based on the volatile or
static nature of the data.
Consumers of the data page, whether it is a user Interface needing data for a dropdown list or a case
deciding whether an approval is required, we can simply reference the data page without worrying about
how and when the data is loaded.
Before our application can take advantage of data pages, we must define the data page and how it
behaves at run time.
Define Data Pages
Reference Data Pages
Improve performance with asynchronous loading
151
Define Data Pages

Demo: Understanding the key concepts of defining a data page
Lets take a look at the specifics of defining a data page. We display and create data pages using the
Data explorer. Click the data icon to display the Data explorer.
By default, it shows all data pages grouped by data objects in our current application.
A data object determines the structure of its data pages since each data object references a data class
for its definition.
To see the details of the data pages, lets expand the desired data object. This lists each data page and
the number of times its used.
We can also use the data explorer to add new data objects by selecting Add/Remove Data Objects from
the dropdown menu.
Here we see a list of the same data objects as shown in the Data explorer. If we want to add a new data
object, we can either select Create New to create both a new data object and a new class or use the
search option to add a new data object by locating an existing class.
Now lets learn how we define a new data page. At the top of the Data explorer, select the option for
creating a new data page.
Once the new record window appears and after confirming the application layer and branch RuleSet,
enter a short description for the data page. Like other rules, the short description is used to generate the
name but with data pages they are prefixed with D_. Data page names must start with D_ or Declare_ to
support legacy Declare pages.
For this example, lets assume we want to make vendor Product Catalog data available to our purchase
order application. As soon as we tab away or click out of the short description text box, the record
identifier updates and prefixes the name of the data page to D_.
After clicking Create, we see the definition options of the data page.
First we need to determine whether this data page stores a single instance of a class or multiples. Using
our example, we want to return a list of the vendor products so we select list.
Both Page and List structures require a data type which identifies the class of the single instance or of the
multiple instances if the structure is a list. In our case, the data page contains vendor products so we
select the appropriate class.
An additional feature of data pages is they can be configured as read-only or editable. Leaving the
default read-only edit mode value, the data page loads the first time its referenced and refreshes on
subsequent access thereafter as determined by the refresh strategy. The Load Management tab controls
the settings for the refresh strategy which well explore later in this lesson.
An editable page loads only once upon first reference and continues to use the same data upon
subsequent references. This allows us to modify the page without worrying about overwriting the
data. While data pages can be editable they do not automatically persist back to the source. That must
be done explicitly.
Finally, we must decide on the scope. There are three options for the scope setting, Thread, Requestor
and Node.
Thread scope creates a separate instance of the Data Page page per Thread. Since a single requestor
session may have multiple open cases, Thread level scope is useful when the data page should be
context sensitive to a particular case.
If on the other hand, the data can be shared across cases, then a broader scope such as Requestor or
152
Node should be chosen. Requestor scope allows us to share data pages for a given user session and is
often used when the data page contains data associated with the logged in operator. Using Pega
Academy as an example, a Requestor level data page might contain the list of enrolled and completed
courses for a student. A Thread level data page would contain the specifics about a particular
course. The Thread level would allow for multiple courses each being sourced from a separate data page
instance.
The node option makes a single data page instance accessible by all users of the application and other
applications running on a given node. On a multinode system, each Java Virtual Machine instance has
one copy of the node level data page. Node level pages reduce the memory footprint by storing only a
single copy of the data available to all users and are an excellent option for storing common, typically
more static, reference data.
Now we are ready to configure the data source.
Data Pages can load their data using a variety of options to include Connector, Data Transform, Report
Definition, or a Load Activity.
For page structures, the Lookup data source replaces Report Definition as a source.
Lets look at each in more detail. Since most applications rely heavily on integrating with other systems,
data pages can obtain their data from another application using integration connectors.
There are many different connector protocols available including a newly added REST architecture.
Each of these connector types requires a Request Data Transform rule which sets the properties or
parameter values that are used in the connect rules.
If the connector class is the same or inherits from the class of the data page, a Response Data Transform
is optional.
Otherwise, a response data transform is required to map the different properties from one class instance
to another.
Other data sources include a data transform as well such as Lookup, which retrieves an instance of a
class by its key values.
Finally we can also use a load activity although its a best practice to avoid sourcing data pages via an
activity since they are typically more difficult to maintain.
In addition to the variety of data sources available to a data page, its possible to conditionally use a
variety of sources based on a when rule. Once you add a second data source, a when rule appears to
conditionally execute the data source. If multiple sources are present, the data page uses the data
source for the first when rule which evaluates to true. If all return false, the final otherwise data source is
used.
All of these data sources have a simulation option so that we can test our application in the event the
source data does not yet exist or has no data. Selecting this option allows us to select an alternative data
source while persisting our intended one. This way when the real data source becomes available we can
disable the simulation and the data page automatically switches to the non-simulated data source.
At the bottom of the page definition is an option to use a post load processing activity. This is useful if we
want to supplement our data page with additional data or check for errors during the load process.
Even if our data page has been configured to be read only, the post load processing activity is an
opportunity to make necessary data changes before the page is available to the application.
Ok now that we have talked about all the options, lets confirm the configuration to load the Product
Catalog. We expect a list of results of type Pco-FW-PurchaseFW-Data-VendorItems.
Well leave the Edit Mode as read only and the scope at Node since other users can share the vendor
153
product catalog.
Remember that node level pages require an access group so well go to the Load Management tab and
select an Access Group containing the RuleSets to execute this page.
Next we select the source of the data to be a report definition called dataTableListReport which in this
case points to a local data table containing some product information.
In this case the class of the report definition and page structure are the same so we dont require a
Response Data Transform.
In reality, this data would likely come from an external source. Thats it. Now all we need to do is save it
and our data page is ready to go.
Remember that a data page is a declarative rule so it does not load the data until it is referenced. We
can cause that reference to occur by manually running the page from the Actions menu.
We have the option of removing any instances already on the clipboard.
When we click execute, the source data is loaded into the page.
We get an xml confirmation page containing a lot of the pages metadata in addition to the list of results.
Lets check the clipboard for the presence of this page.
Since the pages scope is node, we can find it under Data pages, Node, the name of the data page in this
case is D_ProductCatalog .
There are 10 returned results. Here is the first returned product.
Ok, weve confirmed the page returns the expected data. While this data page is now available to be
used by our purchase order application, lets first understand the lifecycle of data pages.
Demo: Understanding the lifecycle of data pages

After a data page is first referenced, it can remain on the clipboard to serve additional requests without
reloading the data which we can also think of as caching the page. Just how long the page remains
active can be configured on the Load Management tab.
The available refresh options depend on the scope of the page, so lets start with a requestor or thread
level page which have identical options.
For requestor or thread pages, we have the option of reloading the data for each interaction or upon a
when rule evaluating to false. It could also become stale based on an elapsed time interval calculated
from the last load time.
We may combine the Do not reload when and Reload if older than options in which case the data page
refreshes as soon as either condition is met. Despite these settings, remember that data pages are on
demand so even if any of the load management options indicate that a page is eligible to be reloaded, a
page is never reloaded unless it is referenced at run time. To put it another way, if a data page is
configured to reload if older than one hour, it simply means that after one hour the page becomes stale
but is not reloaded until the next request for the page occurs following the one hour mark.
As we mentioned earlier, the options for the refresh strategy are different for a node level page. The
Reload Per Interaction and Do Not Reload When options disappear.
Click on the Definition tab and select Node then return to the Load Management tab. Notice the addition
of the Load Authorization section prompting us for an Access Group.
We are prompted for an Access Group for node level pages to avoid using the individual requestors
context as that could lead to different rule resolution results when executing the supporting data pages
rules.
154
Similarly, the when rule option to reload is also removed as we would not want an individual users
context to determine the result of the when rule. If that is needed, then Thread or Requestor level pages
is the appropriate choice.
If no refresh strategy is selected, we may choose to clear pages after non-use. This causes the system
to remove Node level pages that are unused for a period of 24 hours. Subsequent access after this 24
hour period causes the page to be reloaded. This 24 hour interval can be configured in the prconfig.xml
file or specified using a dynamic system setting.
Define a data page using parameters

Like many other rules types, Data Pages support parameters. The defining and passing of parameters is
similar to other rule types; however, the behavior they have on data pages is unique and extremely
powerful. Lets assume we have added an ItemID parameter to the Product Catalog data page.
Now when various Purchase Order cases reference this page, they also need to supply a value for the
ItemID. This causes a separate instance of the data page to be loaded onto the clipboard for each
unique ItemID value.
Lets take a closer look at what happens at runtime for this data page request. Another Purchase
Request, PR-105, makes a request for the D_ProductCatalog data page for the Product with ItemID: F342.
The system first checks to see if the page is already on the clipboard.
In this case the page does not exist so it goes to the data source to retrieve the product and put its
contents onto a new data page D_ProductCatalog(ItemID:F-342)
Another Purchase Request, PR-106, makes a request looking for Product with ItemID: R-644. This time
the system locates a page with the identical parameter value and thus returns the page already on the
clipboard saving a trip to the original data source. The consumer of the data page does not need to worry
if the page already exists on the clipboard since its all handled by the system
The addition of parameters does not affect the configured lifecycle of the page. Lets say the page
definition dictates the page expire after 30 minutes. The page will reload despite already existing on the
clipboard if more than hour has transpired since it was loaded.
Speaking of lifecycle, the addition of parameters offers an additional option under the load management
tab, the option limit to a single data page
This setting is only available if a page has parameters and it overwrites the existing data page on the
clipboard as soon as the data page is requested again with a different parameter. In other words, rather
than loading multiple instances of a page each with a unique parameter value, only the most recent one is
loaded..
Demo: Define a data page using parameters

Now that weve covered the data page parameters conceptually, lets see how we actually configure it. In
this case, lets assume we now want to have our D_ProductCatalog page return only one product record
based on the products ItemID. So, well add a parameter under the Parameters tab.
Lets call it ItemID which uniquely identifies each Product within the catalog. Well leave the data type as
string and select Yes under required. This will be an incoming parameter . Since the product catalog is
dynamic in nature, the remaining parameter settings dont apply so well leave them blank.
Next we need to configure the page to load only the Product that corresponds to the provided ItemID. We
do that by going to the Definition tab and changing the structure to a page since well only be retrieving
one product.
Since a specific product will likely be requested for a given case, lets also change the scope to thread.
155
Lets use a data source of Lookup and point it to the VendorItems class.
Now we need to use the incoming parameter for this data page as the class lookup criteria. To do that,
we click on the parameters link below the class name and provide a value for the class key which in this
case is ItemID. Since we want to use the parameter value as the criteria we select param.ItemID.
Lets save it so we can test the new addition of a parameter by running our page. Notice that we are now
prompted to provide an ItemID parameter value.
After seeing the xml confirmation of the result, well repeat this a few more times for two other ItemIDs.
We executed this data page with three different parameters, so we should see three distinct instances of
D_ProductCatalog. Lets confirm this by looking at the clipboard. Since our page is a thread level page,
we first need to select the appropriate Thread which is Standard when testing from the Designer Studio.
If we had configured the data page to limit it to a single data page, then only one page instance, the most
recent one, would be on the clipboard and references to a previously called page would be reloaded and
would overwrite the current one.
156
Reference Data Pages

Describe methods of referencing a data page
Data pages dont provide much value until they are referenced, which is done differently based on their
definition and intended use case.
For example, a data page may be defined to populate a dropdown control with a static list of currencies.
Or it could be used to auto populate an entire customer page property from an external system of record
to support creating a new insurance policy case.
Certain cases will require a snapshot or a copy of the customer data to be stored with the case while
others always need to rely on the external system of record to make business decisions. These different
scenarios impact the way we reference a data page.
Pages that contain a list of results can optionally be referenced with a key that would return one or
multiple instances matching that key.
Using this data page as an example to help illustrate this, the page has been defined as a list structure
pointing to a report definition data source that will return the list of a companys roughly 50
products. Notice the page is defined to have keyed access using productID as the key.
Now anytime this page is referenced, we also provide a value for the productID key. The first time the
data page is referenced, all the products are loaded according to the data source configuration and stored
on the page despite providing a key. The key is then used to locate the specific instance on the data
page and returns only the matched result to the caller. When another request to the data page with a
different key value is made, the products are already on the data page; therefore, the system only needs
to locate the correct instance on the page. This saves a trip to the database unless the pages refresh
strategy requires it.
Whether using parameters as shown earlier or using keys, the case ultimately receives the data it
needs. The benefits and drawbacks to either approach typically revolve around memory management
and performance. The use cases and volume of data should be analyzed to determine an optimal
strategy.
One more fact about the keyed access is that the key can consist of one ore more properties and also
does not have to be unique. This means that multiple matches for a given key or keys can occur in which
case a list of results are returned. To ensure the caller is capable of handling multiple results, the data
page must be explicitly defined to do so.
By the way, when a data page uses keys, it can at the same time use parameters. As an example, the
parameter might cause only products from a certain vendor to be loaded onto the data page while the key
is used to select the desired product.
Demo: Referencing a data page for a dropdown list

Ok, lets look at the specifics of referencing a data page. Since the method used varies based on the use
case, lets walk through numerous examples to help illustrate the different options. Well use a purchase
request as the business case.
For our first example, lets say that we want to display the list of available products using a dropdown
control instead of a text box when making a purchase request.
To support this, we need a data page that returns a list of products. Taking a look at the Vendor Items
data object, we have a Product Catalog data page already defined as type list returning Vendor Items.
Now, we want to use a dropdown in place of the text box which is exactly where well reference this data
page. Using the UI Inspector we can easily open the section where we want to make that change.
Now click on the ItemID properties to change the existing text input control to a dropdown.
157
Scrolling down exposes the List Source where we can reference the data page.
Next enter .ItemID as the property for value and the .ItemName as the display value.
That should do it!
Now lets save it and preview the results and we see that we are able to select from a list of products.
In this demo example we have only 10 products, but imagine the usability impact if we had a long list of
products. We can improve the user experience by changing the data page to return only the results
based on the chosen vendor .
To accomplish this well not only need to change the data pages definition but also how the dropdown
control that calls the page because well need to supply a parameter value. Lets start with the data page.
Well go to the parameters tab and enter a vendor parameter.
When adding a parameter, we must apply it in some way. In this case we want the parameter to affect
the sourcing of the data which is a report defition.
So well do the same in the DataTableListReport by adding a parameter there.
Now back to the query tab, where well use the new parameter in a filter condition to limit its results by
vendor.
After clicking save, we can return to the data page.
Here, we must make sure that the data page takes the parameter value it receives and passes it onto the
report definition. Refreshing the data page, the parameters link picks up the recently added parameter to
the report definition allowing us to enter the pass through parameter value.
Another setting we should change on the data page is its scope since the page now contains vendor
specific products as determined by a particular case, thus a better scope is Thread.
Also well need to reload the page if the user selects a different vendor so well modify the refresh
strategy to Reload once per interaction
After saving, we need to return to the section to edit the dropdown control so that we can provide a value
for this new parameter we just defined. First, lets refresh the section so that the updated data page
definition is recognized.
Now by going back into the dropdown controls properties, we see the addition of a parameter value
prompt for vendor once we reselect the data page.
We want to provide as a value the selection made from the vendor dropdown which is bound to the
VendorList property so we enter it here.
Now were done, so we click OK, save and return to the case to see if it all worked.
So now if we select Amazon as the vendor it yields only amazon products.
By changing the vendor to Microsoft, the items now shown are limited to Microsoft products.
Referencing a data page from properties

Another way data pages can be referenced is directly from page or page list properties. This means that
potentially the entire set of page or page list properties can be easily populated from a single data page.
This type of property reference is available as either a copy or a pointer.
Lets say that we configure a customer page property for a balance inquiry case to be populated from a
copy of a data page. The data page is configured to lookup a customer record based on the
customerID. As soon as the customerID is entered on the case, the data page copy is triggered and
158
returns the customer details for the provided customer ID and is persisted to the case. No further access
to the data page is made even if the data on the data page or in the database changes. Notice here, that
the address on the customer data page has changed but that change is not reflected in the case because
it was a copy. This is important to understand. Even if this Balance inquiry case later requires a decision
based on address or is later routed and opened by another operator, once the page copy for a given
parameter value has occurred, it does not reaccess the data page regardless of the refresh strategy.
The other option is to point to, or refer to, the data page. This works differently in that the case never
actually obtains or persists the data but instead always goes to the data page to determine the value of
the data. This setting is used particularly when we want the most up to date information from another
system of record. Take for example a case where business decisions are made based on stock
prices. When a case requests pricing information after supplying a stock symbol, the data page pointer is
triggered and causes the data page to load the stocks information from the database. Any rendering,
processing, or decisions made on that data is done directly from the data page. This way, any changes
to the data are automatically seen by the case throughout its lifecycle since it never stores its own copy of
the data.
Demo: Referencing a data page from properties

This property is a page list that supports persisting multiple products and their details for any given
purchase request.
Now for the interesting part, the Data Access area.
For page and page list properties, there are three options, Manual, Refer to a Data Page, and Copy
Data from a Data Page. The manual option means that the data for this property will be entered via the
user interface or procedurally via other rules as part of the workflow.
The other two options we discussed at a high level earlier, the copy or refer to, both use a data page to
populate the data which is what well focus on here. Lets start with Copy Data from a Data Page, since
that is what this property is configured as to support the product details data automatically copying to their
respective fields as we just saw.
Because LineItems is a page list property, we see the Load this page in this page list individually option
box.
What exactly does this mean? Well explain that in a moment. Lets first take a step back and
understand the use case. For this purchase request, to add products, the end user selects the products
one-by-one.. As each product is selected, we want to show the user the details of his or her choice.
This means the data page must take the Product ID or in this case, ItemID, as a parameter and locate the
product details. Thats exactly what this Product Detail data page does.
It returns a single line item order instance based on a vendor items lookup matching the ItemID
parameter.
Notice the page has been defined with this ItemID parameter.
Since the Object Type of LineItem-Order is not the same as the Vendor Items class, we need a response
data transform here to map the lookup results to an individual LineItem. This is not an unusual use case
as the data model for the system of record may not match that of the case type.
Ok, lets get back to the LineItems page list property.
We have the Load each page in this page list individually selected so as to trigger the data page copy
as each product is selected from the Item dropdown list in the user interface. To be exact, the data page
copy occurs precisely when the parameter value, in this case itemID, changes for any instance in the
LineItems page list.
The trigger could be when adding a new page instance and selecting an itemID or when going back to an
existing instance and changing it to a different ItemID as we are doing here. Its important to emphasize
again that the data page is only accessed when the parameter value changes thus the refresh strategy
159
does not come into play as long as the parameter value remains the same for each page instance.
If we didnt have the option to Load each page in this page list individually selected, then the entire line
items page list would be filled at once as soon as the configured parameter value changes.
If that is the case, the Data Page would have to be configured to return a page list and use a parameter
value that is not a property contained within the page list itself. Both of these requirements are enforced
at design time as we can see when we click save.
By the way, this option is only available for a page list property. Otherwise all the data access settings
are identical for both page and page list properties.
When the data page access method is set to copy, an additional configuration option is available and its
worth mentioning its the Optional Data Mapping option.
The reason it is optional is that the data page itself already has a response Data transform which is used
to map the data.
So why do we even need this?
Its helpful if we think in terms of reuse. We might have three different case types that can each use the
same data page provided they each customize the data mapping just slightly. If that option didnt exist,
we would then have little choice but to create three specific versions of the data page.
Now, as weve already showed conceptually, the other method of referencing a data page from a property
is by pointing to the data page, in other words, using the refer to a data page option.
Again to summarize, the difference with this option is that the data does not get saved with the case. If
we close and reopen the case, the data page would again be referenced to obtain the data and
depending on its scope and refresh strategy, it may still be fresh on the clipboard or need to be reloaded.
The configuration settings with this option are very similar to the Copy option.
There are two differences. One, the Optional Data mapping field does not exist for the Refer To option
since we are directly pointing to the data page as it is defined.
The other is the Save parameters with this property for access on reopen check box which only
appears on the Refer To option.
It gives us the choice to persist the parameter value with the case so that if it is later reopened, it
automatically reloads the data page using the persisted parameter value. If not checked, then the data
page is not referenced until the parameter is set to some value as a result of further processing of the
case.
Demo: Referencing a data page with keyed access

Earlier in this lesson, we talked about the ability to access a data page with a key. Using keys is
appropriate when we want to store a list of frequently accessed items on a data page. All items in the list
are then readily accessible directly from the data page by supplying the key value that matches the
desired item or items.
To confirm our understanding, well look at the exchange rate use case on our purchase request which
implements a keyed data page. For a given base currency such as US Dollars, we can get the exchange
rate for various currencies such as British pounds, Euros, and Japanese Yen. We can also switch the
base currency to Euros so that the exchange rates provided are calculated based on Euros.
Lets see how this is implemented. Well use the UI inspector to quickly access the underlying section.
The two dropdown boxes are bound to a BaseCurrency and a Currency property respectively.
Now the exchange rate calculation is based on the ConversionRate embedded property on the
ExchangeRate page.
160
The ExchangeRate page property is the key link here as it is configured to refer to the ExchangeRates
data page. Lets look at this property configuration.
We can see it references the ExchangeRates data page.
This data page has been defined with a BaseCurrency parameter and a ToCurrencyCode key.
Lets just verify this on the data page definition.
Sure enough this page has been configured with the keyed page access using the ToCurrencyCode
key property and lets check the parameter.
Yes, it has indeed been defined with a BaseCurrency parameter. This parameter is used to limit the data
source results to just a single base currency.
By the way, for the purpose of this demo, we are using a simple data transform simulation to hard code a
list of exchange rates rather than using a realistic data source as would be expected with a production
system.
Ok lets return to the ExchangeRate page property and tie it all together.
As a user selects a different BaseCurrency, a different parameter is used which loads the list of exchange
rates for that given base currency.
When a ToCurrencyCode is selected, it becomes the key that is used to find the correct instance in that
currency list.
To better understand what happens behind the scenes lets look at the clipboard.
We can see the Exchange Rates data page. It contains a unique page instance for each unique
parameter: US Dollars, Euros and Japan Yen.
For each of these pages, the various exchange rates are contained in the pxResults. Here, US Dollars to
Great British Pounds, to Euros, and to Japanese Yen. The currency key value is used to find the desired
instance in the list of results.
Ok lets conclude by returning to the UI and recognizing that the exchange rate field is bound to the
exchangeRate page which in turn automatically points to the exchange rates data page using the
BaseCurrency as the parameter and the target currency as the key.
Referencing data pages from other Rule- records

Referencing data pages is not limited to UI controls or page properties. In fact, there are many rule types
that can access data pages such as Decision Tables and Trees, activities, when rules to name just a
few. You can see here, many, many rules can reference data pages.
While these rules do not support the same design time parameter prompting of data pages, we can
reference any data page with zero, one, or multiple parameters usings a special syntax.
Lets look at some examples using this syntax. The first syntax example references a D_ProductDetail
data page with no parameters. Its pretty simple, just the page name. Notice we can reference the page
or a specific property on the page.
The next syntax references a page with one parameter. Notice the name value pair is separated by a
colon and are both contained within the square brackets. The parameter value can be supplied a number
of ways such as hard coding although not recommended, a property reference, another parameter or
even the result of a function.
When a data page has only one parameter, we can use a shorthand syntax by omitting the parameter
name and just providing the value as shown here.
161
Once a data page has two or more parameters, we must use the full syntax since we need to explicitly
state which parameter values correspond with each of the parameters. Notice in the last example, the
first parameter value uses the result of a function while the second hard codes the Include Image
parameter value to true.
Now lets look at one example of this syntax in the context of a when rule. It checks to see if the
Products ItemCategory value retrieved from the data page is equal to General Purchase. Since the
parameter value supplied here is equal to the current ProductID property value, this when rule evaluates
the product currently in context.
Notice how the when rule references a specific property on the data page. This can be done for all the
other rule types and various syntaxes we just covered.
Just keep in mind that the entire data page is loaded and not just the individual referenced property.
162
Improve Performance with Asynchronous Loading

Describe when and how to use asynchronous loading
As we have already discussed, one of the primary benefits of data pages is that they automatically
manage the loading of data, taking that responsibility away from the consumer of the data page.
Sometimes the data that cases need to complete their tasks take time to load which may negatively
impact the customer experience.
In such situations, we may want to proactively load the data before it is actually needed. Lets use an
example when a customer contacts a customer service representative.
It is highly likely that the customers account and activity information is needed to properly service the
customer which may take time to load and aggregate since it often resides in multiple external systems.
Rather than waiting to load the data until it is actually needed, we could load it while the representative
takes a few moments to verify the customers identity and determine the intention of the call. To
accomplish this from a technical perspective, an explicit call is made to the necessary data page using
one of two activity methods which cause the data to pre-load.
The first is the Load-DataPage method which lets us specify the name of the desired data page to load. If
the data page has parameters, we are able to supply a value for each. The other is the Call-AsyncActivity method which does not directly load a data page but instead calls another activity which would
want to make a reference to a data page in order to load it.
If at any point, we require the data to finish loading before proceeding, we can use the connect-wait
method to force the system to wait for a desired period of time before proceeding or return a fail status if it
does not complete in a timely manner.
Both the Load-DataPage and Call-Async-Activity methods and the Connect-Wait have a poolID
parameter which makes it possible to pair a Load-DataPage or Call-Async-Activity method with the
Connect-Wait method by matching their poolIDs. Before using these methods, be sure to understand the
performance gain to ensure it outweighs the cost of loading these pages procedurally and thus,
sometimes unnecessarily.
Conclusion
The new data management paradigm is extremely powerful and flexible and can be applied to a number
of different use cases.
The first and most common use case is where a case has reference data that it does not manage, but is
needed throughout its process. If the data changes we want that reflected in a timely manner. Think of a
vendor object used by a purchase order case. The vendor does not belong to the purchase order, but is
referenced. If the vendor data changes we want to see those changes.
A related use case is the situation where the data to be referenced by the case needs to be a snapshot in
time. We may need the snapshot of a policy for a claim that is processed. If that policy changes AFTER
the claim is created we dont want it to be updated.
A third and very common use case is to use a data page to store a list of items that are used to populate
a drop down. This list can be set to be shared across the entire node improving performance.
In another use case a single data page can be used as a list, for example a list of currency codes, and
also provides direct access to a specific page in the list using the keyed page access feature.
Now, we can describe and define data pages. We know when to use data pages in our application and
how to reference them. We also know how to improve performance using asynchronous loading.
163
Module 05: User Experience
Introduction to User Experience
Introduction to UI Architecture
Building the UI
Introduction to Responsive UI
Introduction to Styling an Application
Understanding Available Controls
Building Dynamic UI
164
Introduction to User Experience

Introduction
Welcome to the lesson on User Experience. What is User Experience? Its the all-encompassing
spectrum of user interfaces, insightful processes and thoughtful layouts that makes an application easy to
use which improves the productivity and moral of its users.
Explain the principles of good user experience
Access and leverage the UI Gallery
Incorporate the UI Kit into applications
Explain the principles of good user experience

Without a good user experience, user adoption is at a risk. Users who dont feel that an application is
easy to use will find ways to avoid using it. Having users revert to paper trails, external systems or
workarounds is detrimental to the overall success of an application.
Therefore it is imperative that we provide a good user experience that is friendly, easy to use, and can be
leveraged with little training.
So what makes a good user experience?

The most important first step to a good user experience, also known as UX, is to not mistake it for the
user interface. This is a common misconception.
While the user interface, also known as UI, does contribute to the majority of a users experience, other
factors that should be considered are:
Automating business processes
Using intent driven processes
Ergonomics
Automating business processes

This consideration is about making things easier for a user. It is an underlying principle that should be
applied thorough out the development of an application and especially since it affects the user
experience.
Lets take the example of a shopping cart. Throughout the history of e-commerce, there have been two
major implementations of shopping carts, ones that update automatically and ones that dont. Which one
do you think has the better user experience? By automating the calculations for applicable taxes,
shipping estimates, running totals, etc., were able to provide the user a better overall experience by
showing them upfront their real costs. This allows users to be better informed, provides better customer
service and thereby helps our users to be more productive.
165
The examples extend beyond calculations. Anything that makes the job easier for a user should be
considered to give the user a better overall experience. This could entail anything from pulling history of
a caller in a call center to see their past transactions to using analytics to determine the next best action a
user should take.
Using intent driven processes

This consideration is about providing users the information they need, when they need it. In most
situations, a user only requires a small subset of the overall information to make an informed decision.
By placing this information upfront for the user, they can quickly make a decision without having to sort
through all the possible information related to that customer.
Lets take the example of a loan application. In most cases, a user who is considering the approval of a
loan application requires two pieces of information, what is the ability of the customer to pay and what is
the likelihood of the customer to pay. Information such as the address of their home branch is irrelevant
to this decision.
The ability to present users with the correct relevant information is a shortcoming of many of the green
screen applications in use today. These outdated approaches of always presenting all the data about a
customer at all times often leads users to spend extra time reviewing irrelevant information and hunting
for the information that is relevant. By focusing on the intent at any one point in the process, the user
spends less time searching for the relevant information and thereby becomes more productive.
166
Ergonomics
This consideration is all about making the system easier to use. Well want to try to eliminate as many
clicks, and as many mouse movements as possible to make the user more efficient in their use of the
system.
Lets take the example of asking users to agree to some terms of service. Weve all seen them, and
weve all seen them implemented multiple ways, but theres two ways that seem to be the most
prominent. Asking users to click a link to view the terms,
or presenting the terms on the screen in a scrollable frame.
Ask yourself which of these is friendlier to a user? By placing the terms of service directly on the screen,
we can save users the unnecessary clicks of opening a modal window and then subsequently closing that
window.
Ergonomics is more than just eliminating clicks though. Its about smart placement of items within the
screen. Using tabs to navigate a multiple input form instead of having the user reach for a mouse.
Grouping selections nearby, so the user doesnt have to move the mouse over a large area. Breaking the
screen up to avoid users having to scroll, especially horizontal scrolling.
Thats actually one of the recommended best practices. Never present a user with horizontal scrolling
and try to minimize the necessity of vertical scrolling.
167
So what about the User Interface?

Even though the user interface is not the entirety of the user experience, it is a very important factor in the
user experience. It is through the UI that a user interacts with the user experiences we build. In order to
build user interfaces in PPRC, we need to know some of the key terms describing the parts of the UI that
we will be building. Each of these is described in more detail in other lessons within this course.
Portal
A portal is really a user workspace. In PRPC, the term "Portal" indicates not only the user workspace, but
can also indicate the role the user has. For example, the User, Case Manager, CSR, Developer, and
Business Architect are all names of PRPC portals that are geared to particular users.
It's important to think about what type of functions and tasks our user groups need access to, to
determine the type of portal that is needed.
Harness
A harness can really be thought of as an HTML Page. It is a top level component within the Pega UI.
There are a number of different types of Harnesses within the PRPC.
168
The Perform and Review Harnesses are the most popular ones to use in an application. These allow
users to enter, edit and review data within a PRPC application.
Section
Sections are exactly what they sound like. Within a harness, there can be a single or multiple sections.
These sections are the building blocks of the application UI. There are hundreds of standard section rules
that are shipped with the product that allow easy configuration of the user interface.
169
Layout
Layouts allow us to specify the way we want our form data to be presented. Every section contains at
least one layout. PRPC and Pega 7 in particular provide several different layouts to get us started with
building our UI and we always have the option to add more layouts as needed.
170
We should note that Layouts are the only UI component that is not its own rule in PRPC.
Controls
Controls are the most granular of the UI components. These allow us to present data, take user input,
make decisions and interact with the user. These include things like text boxes, buttons, selectable lists,
etc
171
Pega 7 in particular provides several new controls aimed at making UI development even easier, dynamic
and more robust.
172
Access and Leverage the UI Gallery

Before we go examining any of the new controls, we first need to take a look at the new UI Gallery. The
UI Gallery has been rebuilt to make finding and examining controls even easier than ever. We launch the
UI Gallery by selecting DesignerStudio->
User Interface-> UI Gallery.
The UI Gallery is configured in two parts. The first is the Showcase, which contains some samples of
complete User Interfaces. The second is the Available Components, which contains samples of individual
controls. These are further grouped into the four categories shown here; Components, Layouts &
Containers, Tables & Grids and Samples & Combinations.
To examine the controls, we just click on the name, like this dropdown. This brings up the examples for
the dropdown. The main part of the screen shows us samples of this control in use. Over here on the
right were shown other controls that share similar functionality to the one were currently examining. The
View design-time configuration link opens the section rule so that we can examine how these examples
have been configured. To choose another control or return to the Overview we click Navigate.
This pop up lets us jump directly to any other control in the gallery. Or, by clicking here we return to the
main UI Gallery
173
Use the UI Kit

The UI Kit is a Pega 7 ruleset (UI-Kit-7) that contains rules and skins available for use in building or
customizing Pega 7 user interfaces. The UI Kit ruleset provides the latest Pega standard end-user UI,
with features designed to ensure responsive interfaces on mobile devices, and includes the most current,
enhanced styles used by the pyEndUser71 skin.
To use the UI Kit in an existing application, add the UI-Kit-7 ruleset to the application rulesets for your
application, using the Definition tab of the application rule. By default, Application Express adds the
ruleset to any new Pega 7.1.6 application that it creates, if the application is built upon a standard Pega
application.
The UI Kit is delivered as a locked ruleset. To customize the rules provided by the UI Kit, copy them to an
application ruleset first.
Conclusion
The overall user experience is so much more than the user interface, but the user interface is still an
integral part of the users experience. Well-designed user interfaces coupled with planned user
experiences leads to user adoption and the success of our application.
174
Introduction to UI Architecture
Introduction
Welcome to the lesson on User Interface architecture, portal, harness, and flow action. What do all these
rules mean? We already know that Section rules provide the building blocks of a user interface but when
do we use all these other rules? How do we put together a user interface?
Thats what were here to discuss today. In this lesson we will cover which rules make up the user
interface and how they interact with each other.
Working with Portals
Working with Harnesses
Working with Flow Actions
175
Working with Portals

This is the top level of our User Interface. It defines what a user sees after they log into the system.
Portals can be built to support a variety of user requirements, and there are several portals available out
of the box we can leverage as starting points. In most cases, we can start with the pyCaseManager
portal. There is also a pyCaseWorker portal, but this portal is just a subset of the pyCaseManager portal
so its considered best practice to start with the pyCaseManager portal and remove the unwanted
elements.
Parts of a Portal
Below is a typical portal a user will use while performing their work and it is a best practice to follow this
same general layout while building our portal.
The top pane is setup as a header that provides access to search for or create new work. It also lets the
user log off and switch applications if access to multiple applications has been granted.
176
The left-hand pane is referred to as the navigation pane. This allows the user to switch between screens
of the application. From here, they can access their recent work, their worklist, and a variety of reports
This main area is known as the Work Pane. This is where a user interacts with each individual piece of
work.
177
Creating a portal
When working with portals, we need to open the portal rule form. In most cases, we will only be dealing
with two tabs.
Skins
The Skins tab allows us to specify three different options. These options tell the system how to display
this portal.
The first option is role. Role can be either user or developer. When developer is specified, the system
includes additional scripts necessary to support development actions, such as check-in and check-out.
These additional scripts cause the system to leverage more memory, so it is a best practice to specify any
new portal as user and to only use the existing developer portals for development.
The second option is for the type of portal. Type can be one of four possible values:
Fixedthis type of portal is provided to support backwards compatibility with applications created
prior to version 5.5. It cannot be used in new development.
Customthis type of portal determines the user interface from an activity. It is an advanced topic
that is discussed in the Lead System Architect course
Mobilethis type of portal supports displays on smartphones and tablets. It is an advanced topic
that is discussed in the Pega Mobile course.
Compositethis portal uses harnesses to define its layout and is the recommended portal type to
use for all new development. The rest of this lesson we will only reference settings for this type of
portal.
The last option is for the skin rule. In most cases, we want to default to the Application Skin option. This
will allow the system to inherit all the same settings for the entire application. Alternatively, we can
specify another skin to use, but this does not provide for reuse and should only be used when its
unavoidable.
178
Spaces
When using Composite portals, the other tab we need to configure is the Spaces tab. In most cases, we
only need to specify a single space called Work and provide the associated harness. The Work space
must always be present even if we specify any additional spaces.
The harness we specify is a special kind of harness that uses a screen layout. Screen layouts allow us to
specify which sections to display to the user. If we open the harness associated with the pyCaseManager
portal, we find a screen layout that reflects the same top, left, and main panes weve seen when viewing
the rendered end user portal.
Each one of these panes is a reference to a section rule in the system.

Screen layouts consist of a main section and its adjacent regions. Out of the box, there are eight possible
configurations for the main and adjacent sections.
179
More combinations can be defined in the skin rule, but the majority of portals leverage the Header Left
configuration.
Each region in a screen layout can only contain a single section, though that section can then in turn
contain multiple embedded sections. The main region is typically a section that provides a single
Dynamic Container. Dynamic Containers are necessary to display work objects.
180
Working with Harnesses

Aside from controlling user portals, the main function of a harness is to support the display of a work
object. You can think of a harness as the form for the work object; it groups the individual sections
together and presents them to the user.
Standard Harnesses
Out of the box there are several different harnesses we can use as starting points. Most of them can be
grouped into four categories that share a similar purpose:
Newthis encompasses any harness that is displayed when the work object is being created.
They are presented to the user after a work object has been instantiated on the clipboard but
before it is persisted to the database. It provides the options to set some initial values that should
be present during the initial creation. As a best practice, the New harness should only be used
for this first step. Examples of a New harness are New, NewCovered and NewSample.
Perform this encompasses any harness where the user is performing their assignments.
These harnesses are what allow the user to interact with the work. There are several different
forms of the Perform harness that provide a different interaction but all fundamentally allow the
user to access and submit a flow action to move the process on from this assignment. Examples
of a Perform harness are Perform, Perform_Buttons, and Perform_Step.
Reviewthis encompasses any harness where the user is viewing read-only data and not
interacting with a flow action. These harnesses are used to present the user with information
about the work object and are most often used to view all the associated assignments with this
particular piece of work. Examples of the Review harness are Review and ReviewSample.
Confirmthis encompasses any harness where the user has submitted the work and does not
own the next assignment. They are used to present final information to the user, but the user can
no longer interact with the piece of work. Examples of a Confirm harness are Confirm and
SimpleConfirm. In addition, there is a special confirm harness called AutoClose that can be used
if we dont need to display that final piece of information.
181
Configuring the harness

When working on a harness rule, there are several options that need to be configured.
The Design tab is where the bulk of the development on a harness is completed. Its here that we use the
Designer Canvas to specify the layouts and sections we want this harness to display. The Designer
Canvas is described in the Building the UI lesson.
Many people focus all their efforts on this tab alone and forget that there are some other essential
elements that should be configured beyond these layouts. These are all described in the help files in
detail, but lets take a look at a high level overview of which features each tab offers.
182
The Display Options tab provides options for how errors are communicated to the user, some control over
the presentation to the user, and an audit feature that allows the system to track every time this harness
is displayed to a user.
The Scripts and Styles tab is used to provide form-level JavaScript to the system. The best practice is to
not leverage these and provide any required actions or events in the Skin rule. They are provided here
for backwards compatibility.
The Advanced tab provides options on how the HTML is generated from this rule to be presented to the
user.
The other two tabs, Pages & Classes and History, are similar to all other rules that support these forms.
Working with Flow Actions

Weve already established that Flow Actions are how a user interacts with a work object in a Perform
harness. But what exactly is a Flow Action?
Flow actions are interesting rules. They are not a UI rule that specifies a layout and how to arrange bits
of the system, yet they are still an integral piece of the overall user experience. These rules are what
allow a user to perform their assignments and interact with the work. They are specified in the flow as
connectors off an assignment.
183
Configuring a Flow Action

To configure a flow action, there are several options that need to be specified. These are all described in
the help files in detail, but lets take a look at a high level overview of which features each tab offers.
The Layout tab allows us to specify which section will provide the user interface for this flow action.
The Validation tab allows us to specify which validation rule (Rule-Obj-Validate) to execute when this flow
action is submitted. We can also use this validation rule to conditionally update the work objects status if
the validation is successful.
184
The Action tab is the second most important tab of a flow action. It is on this tab that we define how the
system behaves when performing this flow action. At this point we have the option to take actions just
before the screen renders, such as to update some of our data or to prepare some calculations. We can
specify which actions to take when the flow action is submitted, such as performing calculations or
updating a back end system. We can also configure how the system interacts with the user for the next
step of the flow such as whether to show the next step of the process or to display a confirmation to the
user.
The Help Setup tab is underutilized in most systems. This tab allows a developer to specify information a
user can then leverage to gain additional insight about this flow action.
185
The Security tab is used to control who can perform this flow action. Privileges and security in general is
discussed in the Security lesson.
The HTML tab lets us specify how this flow action will affect the rendering of the user interface. In most
cases, we will want to specify to use a Reference Section. In some scenarios, we may want to leverage
the No HTML to indicate there is no user input beyond the selection. This is often used in conjunction
with the Perform_Buttons harness to provide an easy means of allowing a user to choose between
branches of the flow, such as Accept or Reject without requiring an additional user interface. The
Reference HTML choice is provided for backwards compatibility and should not be used for new
development.
The other two tabs, Pages & Classes and History, are similar to all other rules that support these forms.
186
Working with Local Actions

Local actions are a special kind of flow action that is not associated with an assignment in a flow. They
function and are configured similarly to flow actions but dont move the flow along a connector when they
are submitted. Instead, these just perform the actions specified on the Action tab but leave the work
object on the same assignment.
These are used for optional tasks, such as transferring work between operators, updating information,
and sending correspondence. Local actions should only be used if the requirement is an optional task. If
the business process indicates that a correspondence must be sent, or that work must be routed to
somebody else, it should be done with a standard flow action instead.
Configuring local actions

We configure a local action exactly the same way we configure a flow action. After all, they are the same
rule. The only difference is how we specify access to them in the flow rule.
Conclusion
When it comes to user interfaces, there are only a handful of rules that need to be configured.
Portals define how the entire screen is presented to the user.
Harnesses define how the work is presented to the user.
Flow and Local Actions define how the user interacts with the work.
Sections are the building blocks of these various user interface rule types.
187
Building the User Interface

Introduction
When we process a case, UI screens are displayed so users can perform a specific action and keep the
process moving. User interfaces can display various content- such as a claim entry form in which users
complete all the entries to enter a claim, or a screen that displays the terms and conditions for users to
read and accept before opening a new account, or a list of all transactions made by the customer in the
past month, etc.
All of the UI requirements we mentioned above present various challenges in terms of complex
behaviors, however the critical piece is how we should present the information to the user. UIs are judged
based on how the data displays, the alignment of various data elements, the consistency across various
screens, the elimination of visual clutter, and so on.
Use the designer canvas to create sections
Add different layouts in sections
Configure dynamic layouts
Configure grids for repeating groups
188
Designer Canvas
The Designer Canvas assists us to quickly build user interfaces without writing lines and lines of code.
The Designer Canvas is accessible in harnesses and sections.
The top part has a toolbar which provides various icons to perform edit operations such as cut, copy,
paste, add/delete rows or columns, merge rows or columns.
In addition to these operations the toolbar also provides control groups (Layout, Basic and Advanced) for
us to add layouts and other controls in the section. The following represents the entire list of layout types,
as well as the most commonly used basic and advanced controls.
Layout group:
This group allows us to add any of these layouts in the section. Well learn about adding these layouts in
this lesson. These can be added by selecting one of them and dragging it into the section.
189
Basic and Advanced group

This lists all the controls that we can use in presenting our data elements and we will talk about these
more in the Formatting data elements lesson. Similar to layouts, we select one of them and drag it into
the section.
190
Layout Types
There are various types of layouts supported in Pega for us to build our user interfaces.
Dynamic Layout This is the most common layout used in sections.
Column Layout As the name suggests, this creates a layout with columns.
Smart and Free form layouts they exist in the product for backward compatibility
Repeating layouts Used to display repeating groups such as a pagelist.
Dynamic Layouts
Dynamic layouts are a newer layout type supported in Pega7. Dynamic layout is the default layout type in
all newer applications. They use HTML5 tags and support responsive behavior.
When a new layout is added, we need to select the layout type.
When adding a new Dynamic layout in a section, we also need to configure the format. The format
controls the presentation in terms of number of columns each row can have, the spacing between
columns, the width of the cell, text alignment, cell padding, label positioning, and so on. The format is
defined in the skin rule. PRPC ships with a set of standard layout formats that we can use in the
application skin. We can also add more application specific formats if required. This is the list of all
formats supplied in the standard skin.
191
Column Layouts
Column layouts allow us to split the work area into columns. They are mostly used on user portals. The
designer studio and case manager portal heavily use columns. Column layouts are typically used when
we need to present different content in differing columns.
For example, if we are looking at a website such as Amazon.com, the product we are looking for is
presented in the main section while a second column displays actions such as adding the item to the cart
or wish list.
Column layouts can be added in sections and the presentation is configured in the skin rule. PRPC ships
several formats. To get the structure that is shown in Amazon example, we can use the Two column
(Main-Sidebar) format. Please look up the link named Using Column Layouts in PDN to see how column
layouts are added.
192
Repeating Layouts
Dynamic and Column layouts can also be extended using the repeating mode. To add a repeating layout,
we select Repeating in the Set Layout Type dialog and then select the type we want.
The Grid is a commonly used choice, to display the repeating group in a spreadsheet format rows and
columns -- new rows representing a new item. A column header row displays to indicate what each
column represents. Grids can be styled using formats and these are saved in the skin rule.
Unlike other layouts, the repeating layouts require us to identify a source. Grids can display a page list, or
a data page (with list structure), or the results of a report definition.
Dynamic repeating layouts can be sourced using either a page list or a data page. The repeating layout
displays a single cell where we include a section. The section gets repeated for each item of the page list.
The Section can be designed to use any dynamic layouts similar to how we set it up for a single level
property.
Column repeating layouts are similar to grids except the items are repeated across columns instead of
rows. Column repeating layouts can be sourced by a page list or a report definition. In the example
below, each column represents a row as part of the Vendors page list.
193
At runtime, the properties VendorName, Address, city and State must be added in each row inside the
column repeating layout.
194
Configuring layouts
As we saw in our screenshots earlier, layouts play a critical role in separating content and presentation.
The presentation is configured in the skin rule while the content is configured directly in the section where
the layout is added. Data elements are added into the layout using Control rules. The Designer Canvas
provides access to controls, we need to select a control and drag it into the cell inside the layout to add
the property.
Containers and Headers

Layouts can be configured to use headers and use containers. They are useful in grouping cells to
present them in logical groupings. The properties panel of the layout has options to select the header and
container format. However the header and container formats are styled in the skin rule. There are three
header types supported in this property panel bar, collapsible and field set.
Tabs and Accordions

We can also use a tab or an accordion as the header format. We will look at how to add a tab layout.
First we click the Layout group and select Tab and then drop it in the section.
195
This adds a tab layout with one tab in there. We can add another layout or a section inside this tabbed
layout as a new tab. To do this, we select Layout or Section in the Layout group and then drop it next to
the existing tab. While doing this, the system will display an orange indicator to guide where we can drop
this,
To delete a single tab we need to click the tab and then use the delete icon that is in the canvas. Clicking
the delete a row icon will remove the entire tabbed layout (including all tabs).
196
Inner layouts and Floats

Dynamic and column layouts allow nesting of layouts. Nesting is a very powerful feature which helps in
the creation of layouts where fields are arranged in multiple ways.
Lets take a look at the ProductInfo example in UI gallery.
A dynamic layout requires us to select a format. This format determines whether its inline or inline grid
and if its the latter how many columns will we have per row. Similarly column layout requires us to select
how many sidebars and the width of the sidebar. If we look closer at this mockup, it is hard or even
impossible to do this without a lot of customization. When we look at the underlying section rule that
renders this page, we can see it uses a combination of dynamic and column layouts to render this screen.
197
Floats
Another powerful feature of a dynamic layout is that it can be floated to the left or the right. When float is
selected the layouts can be aligned to the left or to the right. In the presentation tab there are other fields
that are very important when using floats. In this example, these are all enabled, however by default only
Self-Clear is enabled.
Lets look at the options:
Set layout width to auto This flag allows layouts to use only the width that it requires.
Self-Clear This field is enabled by default and is used to account for the height of floated
layouts. Do not disable this field unless on occasions like we see down below.
Clear floated layouts This field clears other floated layouts so that they dont appear in same
line.
Lets look at a short video that shows us how the float option works in conjunction with these settings.
Click the link named Using Floats that is in the Related links content to see how floats work.
Example of Float:
The Pega 7 header bar uses two layouts (one floating left and another floating right)
The section rendering this header bar rule looks like the screen shot below. [Header_Section.png]
198
So, how do they appear in same line? Besides the float setting we enabled, the set layout width to auto
field makes sure the layout takes up only the space it requires. This helps in putting both the layouts in
one single line.
Notice the other fields are disabled. Self-clear does not apply since there is no other layout in the section
other than these two layouts. If the Clear floated layouts flag is enabled then both layouts float in two
separate rows.
199
Configuration of Grid Layouts

Grid layouts allow us to configure pagination formats, as well as conditions to control the visibility of the
grid, row, header and footer. We can also configure the refresh when condition so that it can refresh only
a single row.
Pagination is useful not just for the cosmetic appearance, but also aids in improving the performance at
runtime. The results are split across pages and at runtime the system displays only the first 20 and then
users have to click to the next page to see another 20. In addition, if we select Progressive in pagination,
it actually gets only 20 rows in clipboard. For example, when we select progressive and set 20 as the
page size, then the grid renders only 20 at a time unless the user scrolls down further.
Grids allow various types of edit modes. Inline allows rows to be edited directly in the grid while Masterdetail allows them to edit the grid in a modal dialog or by expanding the row or in a separate panel
outside the grid. Master-detail is useful if the grid displays the high level information and clicking a row
then provides additional details. The content that is being displayed to present additional details comes
from a flow action rule.
200
All three modes (None, Inline and Master-Detail) support grid operations. Grid operations allow us to
configure sorting, filtering of the records in addition to other settings. When enabled, sorting offers column
specific operations, so we can disable or enable only the columns where we require sorting.
Filtering in grids can be configured to either use a value or range. The options vary based on the data
type of the column, if its numeric it allows the range to use min and max values and if its string it uses a
set of string characters it can search on.
Conclusion
Sections are primarily used in building user interfaces. When a case is being processed the flow actions
control which section it has to render. In each section, the content can be formatted and presented using
layouts. Layouts help in separating the content and presentation layers thereby enabling the UI
development team to quickly build applications.
Dynamic and column layouts are useful in rendering the data elements and we can nest these layouts to
present a complex user interface. When using repeating groups, we use the Repeating layout which can
present the items in a row (grid or dynamic), column or tab.
201
Building Responsive User Interfaces

Introduction
With the ever-increasing popularity and wider usage of smartphones, tablets, phablets and other such
mobile devices, enterprises now require that their applications be accessible on all of these devices. This
leads to developers having to write code and then test applications in various screen resolutions to be
certain that these applications work on different devices. Mobile App development requires specific code
to be written to ensure the application works if its on an Android or on an iOS device.
What if we said PRPC helps in building an application once and run it anywhere? How is this feasible?
How does the application adjust itself to present the User Interface at different resolutions? This is where
responsiveness comes into the picture. In this lesson we will learn about responsiveness and various
ways we can achieve responsive behavior.
Explain the underlying technologies used in user interface development in PRPC
Set Responsive breakpoints for layouts
Use layout groups for creating responsive UI Screens
202
Understanding Standards Mode

Modern browsers comply with stricter standards mode, which follows the W3C and IETF standards. In
this mode, web applications rendered through a browser use a combination of HTML and CSS. Older
browsers rely upon browser-specific code to render content and applications, which often caused web
applications to behave differently if at all in different browsers. Applications that conform to these
standards referred to as running in Standards mode behave consistently in different browsers and
also perform significantly better than applications that do not. Modern browsers also provide a Quirks
mode for backward compatibility, to support the browser-specific code found on older web sites and in
older web applications.
PRPC applications must use Standards mode to use the newer layouts such as dynamic layouts, column
layouts, screen layouts and repeating dynamic layouts.
In PRPC Standard Mode can be enabled in few a places:
1. Application rule: In the application rule there is a flag (Include HTML5 document type) listed
under the user interface section. When checked Standards Mode is enabled.
2. Harness rule: In the harness rule on the Advanced tab we select Inherit from application rule
for the document type and the application renders in standards mode.
If our application was built prior to Pega 7, we can upgrade to Standards mode by using the HTML5
readiness gadget. Refer to the PDN article (Upgrading an application to render in HTML5 Document
Type) available from the related content area. It provides step by step instructions on how to upgrade to
HTML5.
203
When using IE as the browser, we need to disable compatibility view for the standards mode to work.
Using Standards mode, we can add newer layout types such as dynamic layouts, column layouts and
repeating dynamic layouts. The newer layout types use the <DIV> tag instead of the <TABLE> tag which
makes it much more flexible to resize the information based on screen resolution.
204
Designing Layouts for Achieving Responsiveness

When using layouts, we either use a standard Format (such as Stacked or Inline grid double) or define a
custom format. As we can see, the standard formats shipped in the product use % for width, so the data
elements added in the layout use the width depending on the screen resolution. Setting the width in pixels
or ems makes it more difficult to align data to match the screen resolution.
The main factor to remember in designing user interfaces for multiple form factors such as tablets and
mobile phones is to make sure that we avoid horizontal scrolling. Setting the width in % helps us to
achieve this goal.
Floats
We learned about floats in the Building the UI lesson. Floats are useful in aligning the layout to the left or
the right. This is useful when rendering multiple layouts in the same line. The header in Designer Studio
actually uses two dynamic layouts with the second dynamic layout aligning to right.
Login to Designer Studio and reduce the screen size. Notice that the layout on the right always stays to
the right and it the spacing between layouts decreases to fit both layouts on one line. Using Floats helps
us to achieve responsiveness without the need for any additional configurations.
Now lets look at a video to learn how to set responsive breakpoints to achieve responsiveness.
205
Set Responsive Breakpoints

We spoke quite a bit about building a responsive UI. But, what does a responsiveness UI mean? Lets
see with an example. We see the Case Manager portal here.
Lets try to reduce the size of the screen. Notice the content that was displaying on the left with the links is
now hidden.
When the screen size is further reduced, the right nav now disappears. However, unlike the contents in
left nav this one appears right below the main content.
So where did the left nav go? It actually collapsed it! If we click the icon here it opens up the left nav
Now, lets switch back to designer studio.
Here it uses two columns, the main work area and the side bar which displays the PDN news.
When we reduce the screen size the side bar gets pushed below the main layout.
Lets go back to case designer and use UI inspector.
Open the section that is used in rendering this screen.
The section uses a column layout and it uses a format named two-col main sidebar.
Dynamic layouts separate the presentation from the content. The content that displays in the screen is
configured in the section rule while the presentation or the style is configured in the skin rule.
This is the layout format that is being used in the section.
It uses two columns main and sidebar, the side bar width is configured in the skin rule.
Responsiveness is configured by enabling the response breakpoint.
When the screen resolution reaches the max-width it pushes the sidebar below the main area.
The size can be configured in pixels or in ems (the current font size). In addition to max-width we can
also specify the min-width at which the dynamic layout will display in this format. That is typically used
when we have multiple response points.
Response breakpoints can be set on various layouts.
We can specify it on dynamic layouts, column layouts, grids and in screen layouts.
Lets look at how responsiveness can be set on a dynamic layout.
Dynamic layouts are the most popular amongst all these layouts Lets open Inline grid triple.
Inline grid triple displays the items in a grid and it displays three items in a row.
It has a response breakpoint configured, so this layout becomes stacked (meaning 1 row per column)
when the screen size becomes 480 pixels.
Lets add another breakpoint.
Lets configure it to display in Inline grid double (2 rows per column) if we reach 1024 pixels. The layout
adapts to one of these formats depending on the screen resolution.
Note in addition to transformation we also have the option to Hide this layout completely.
Screen Layouts
206
In the demonstration we also noticed that when the screen size was reduced, the left navigation in Case
Manager and in the Designer Studio portals moved to the left.
The Case Manager portal uses a screen layout, the screen layout does not display the format it is using
here. To see the format lets add the screen layout on top of it.
The alert indicates that the panels will be used if we select a layout using the same panel.
The screen layout used in the section closely resembles the Header Left screen layout, so lets select
that.
Great, it was the same so we did not lose any part of the panel.
The format is configured in the skin rule and we see that this has a header on the top, side bar on the
left and main area.
The response breakpoint is enabled in the left header.
At 210 pixels the panel is accessible from an icon in the header.
Repeating Grids
Repeating grids also support responsive behavior. Lets see the various choices it offers.
Lets modify the default format and enable responsive breakpoints.
There are three choices in repeating grids.
We have configured two breakpoints here, the first breakpoint occurs at 1024 pixels, the choice selected
is Drop columns with importance other. Lets see what impacts this has at runtime to understand this
better.
The second breakpoint occurs at 768 pixels and the choice selected is Transform to List. There are
additional fields such as List Item, Primary cell and secondary cell. For now lets leave them as-is. Again
we will look at the behavior in runtime.
The third choice is not configured, but its pretty clear as the name suggests at a specified width it hides
the whole grid.
Lets look at a section which uses a grid layout.
Unlike other layouts, there is some configuration to be done in the grid repeat layout for responsiveness.
If we look at the presentation tab, the grid is using the default format
and notice there is a flag to enable responsiveness.
In addition to this, we also need to configure the columns.
If we open the properties panel for the category column, we have selected the importance as Other.
As per the configuration on the skin rule, this field will be hidden at the first breakpoint.
Similarly, if we open the properties panel for Product, we have configured the importance for this field as
Primary.
We will look at how this is presented in runtime in a little bit.
All the other columns in the grid are configured to have the importance as secondary.
Now lets look at a case., This shows the grid of three rows with all these five columns and this is the
same section we saw a little earlier.
207
Before we shrink the screen, pay close attention to the category column. When the response breakpoint
is reached it removes this column.
Now lets reduce further it to reach breakpoint 2, there we go. We have the grid displayed as a list with
the primary column at the top and all secondary columns under it.
208
Layout Group
In addition to setting responsive breakpoints, layouts can be made responsive using Layout groups.
Layout group is a way to group different layouts such as dynamic layouts, column layouts, repeating
dynamic layouts and present them together. Layout group can also include another layout group.
How is a Layout group presented in user interfaces? PRPC support four formats by default:
1. Tab
2. Accordion
3. Stacked
209
4. Menu
Breakpoint definitions allow a layout group to be rendered in Tabbed format on a laptop, in Accordion on
a tablet and as a menu on a Mobile Phone. Layout groups require that the applications be rendered via
the HTML5 Document Type (Standards mode).
210
Conclusion
Applications are accessed using modern browsers on different resolutions. PRPC applications use the
HTML5 Document type to render user interfaces in standards mode when accessed using browsers.
HTML5 allows us to use the newer layout types like dynamic layouts, column and screen layouts that can
use responsive breakpoints to change how information is presented to users based on screen size.
211
Styling Applications
Introduction
Welcome to the lesson on Styling Applications. Styling applications is all about controlling the look and
feel of the application. This is often required to meet corporate palette and formatting standards.
Create and Reference skin rules
Create and reference formats
Create and reference mixins
Understand backwards compatibility with existing CSS
212
Styling an Application
Intro to Styling
One of the major focuses of user interfaces in Pega 7 is to ensure a definitive separation between content
and presentation. Thats why theres nothing more interesting than the improvements done with the skin
rules. New features like formats and mixins now alleviate the need for inline styles and custom
CSS. Using these features, well cover how to improve the overall look and feel of an application and to
ensure theres a consistent user experience throughout.
Previous to PRPC 6.3, this was handled with the branding wizard.
This was a great tool, but in Pega 7 skin rules make it even better.
The skin rule is now a one stop shop for configuring the presentation of our application. The tools in the
skin provides us the ability to achieve branding and styling consistency throughout our application. The
skin generates the entire CSS for our application.
Skin Rules
A skin rule is broken down into three parts. Mixins, Components and CSS.
Well be taking a closer look at each part as we get a little deeper into this lesson. But first, youre
probably thinking, How do we use it? Well, skin rules are only referenced in a couple of places
throughout the application. The most important spot is in the application rule.
This is the main skin for the entire application. The other spot is in Portal rules.
Normally wed want our Portal rule to use just the one specified for our application,
but we have the ability here to override the default skin for cases where we may want to display a
different look and feel, such as for external vs internal users.
Operators can also setup a preference for a particular skin. This preference is used for developers to
override the skin of the designer studio when previewing or testing an application. Ideally, were going to
want to keep this preference referring to the same skin as our application.
Mixins
A mixin defines values for a group of style attributes. Mixins allow for efficient and clean style repetitions
as well as an easy way to update our styling with ease. A collection of mixins form the palette for the
skin, such that a mixin or mixins can be used to style different components in the skin. Lets say we want
to use red to highlight all important text. We might leverage mixins when we want to use an exact color of
red everytime something is considered important.
There are three different kinds of mixins that can be defined. Typography, which covers anything related
to text. Backgrounds, which covers, well, backgrounds. And Borders, which relates to borders and
shading effects. Theres a 4th category called Combinations, which is any mixin that affects more than
one of the other categories. An example of a combination is Header Text, because this mixin affects both
Background
and Text.
All previous 7.1 skins have been upgraded to leverage mixins upon opening of the skin. Pega 7
evaluates any style presets that were defined in the old skin, and converts these into appropriate mixins
in the new skin.
Lets cover how to create a new mixin. To start off, were going to click add.
We want this mixin to represent anything we deem important, so lets call this one Important. And since
we wanted important text to be red, lets change the color to red.
We now have a mixin called Important that we can use to apply the same red text everytime its
leveraged.
213
Formats
The Components tab is where we define styles for all the different components. Each component can
have multiple formats for it. We can think of a format as a Type of, so that we can have a format of
button (or type of button) called Primary, and another one called Secondary. A format is what determines
the styling of the component once associated to a User Interface element in a section. Once these
formats are defined in the skin, we can then associate formats on User Interface elements that we drop in
a section. This association provides the User Interface element its look and/or style.
There are four categories of components, General, Layouts, Controls and Reports. Every component in
the system can have one or more formats defined. These formats are then used throughout the
application to control the user experience. All components have a default called either Standard or
Default that is supplied out-of-the-box.
Many components, such as this button example, also have additional formats already defined. Formats
are where we use mixins.
By using mixins, were defining the same style to all components formats where that mixin is used. We
also have the option of overriding part of the mixin.
Lets say we wanted to have our buttons use bold text. Wed select Mixin Overrides click add mixin
override, select font weight and set the weight to bold.
Using our important red text approach, if we create a new button format, we can mark that button to use
the Important mixin. In fact, lets go do that now. First, we would select the Add a format link.
We need to give our format a name, Im going to stick with Important. Then we want to change the Mixin
from General to the one we created called Important, which is down here at the bottom of the list.
We now have a style for our buttons, called Important that will give our buttons red text.
Using formats
Leveraging a format is a simple process. In any user interface screen, just select the component to edit,
such as this button, open the properties panel and on the presentation tab, select a different format.
Once we click on OK our button now reflects the style defined by the new format.
CSS
The CSS portion of the skin can largely be ignored. This tab is leveraged to support backwards
compatibility with applications that already use custom CSS. For any new applications, its better to
leverage the format and mixin features. In fact, if style sheets are used, a warning message is added to
remind us that it should be avoided.
Under this advanced section we have the option to automatically generate a css/workform, similar to the
ones used in previous versions. Again this is only for backwards compatibility and is not recommended
so Im going to disable this again.
Conclusion
As we were shown, through the use of a skin rule, and its embedded features of mixins and formats, we
have complete control over the entire look and feel of an application, allowing us to meet corporate
palette and formatting standards.
214
Understanding Available Controls

Introduction
Data Elements display in the user interface forms to either collect inputs from the user or to present the
stored value of a property. In both of these cases, the presentation of the value requires some formatting
for end users. For example, the purchase order approval date should be displayed as DD-Month-YYYY
for all customers.
Control rules are useful in controlling the presentation of the values stored in the property and also
provide the appropriate input fields for users to enter information. So in the same example, if the manager
needs to enter the purchase order approval date, then we present a control that lets them select the date
month and year.
Explain the significance of control rules
Configure the auto-generate controls
Apply actions on controls based on specific events
Apply auto-complete and configure the various options
215
Understanding the Importance of Controls

Controls are used in two places when a property is defined (in the property rule form) and where the
property is referenced in the user form such as sections. Controls are also useful in formatting the
columns of the report definition. PRPC automatically assigns a default control when a new property is
created and the same control is applied when the property is referenced in the section or report definition.
As developers we have the option to change the control in either the property rule form or in the rule
where its referenced.
When a property is defined, the system determines the control based on the data type. It assigns either
pxTextInput, pxNumber or pxDateTime depending if its a string, decimal or date. In most cases we do not
need to change this value in the property rule form. However, in some cases we may want to modify it
here if we think there is a control which we want to use instead. For example when we define a property
such as a password field, we need to change it to use pxPassword instead of pxTextInput. Making this
change in the property rule form helps us if we want to use this control across all user interfaces where
this property is referenced.
In some cases, we might need to specifically change the control depending onthe context in which the
property is displayed. For example, we change Unit Price to use pxCurrency instead of pxNumber
wherever it is set as read-only. Selecting a control in the UI cell overrides control defined in the property
rule form. By default, it uses the setting Control inherited from property. We can use the change link to
change it to another control.
Controls are auto-generated giving us flexibility to use in various browsers, easier configuration options
(eliminating the need to write JSP, JavaScript, CSS or HTML tags). The Product does ship with several
hundred non-auto-generated controls that are still available for selection but they only exist for backward
compatibility.
Most of the commonly used controls are available for selection in the designer canvas under the Basic
and Advanced Control groups. This is the list of all auto-generated controls that are shipped in the
product.
Action
User Input Controls
Formatting stored Values
pxButton
pxCheckBox
pxCurrency
pxIcon
pxDateTime
pxDisplayText (Display value in read-only format)
pxLink
pxDropdown
pxHidden ( The value is hidden from display)
pxRadioButtons
pxInteger
pxAutoComplete
pxNumber
pxTextInput
pxPassword
pxTextArea
pxPercentage
Controls
pxRichTextEditor
Auto-generated controls can be configured to serve most requirements, however some of the non-autogenerated controls that we still use are Chart, SmartInfo, and the Menu Bar.
216
Configuring Controls
Controls are a rule type that is defined as part of the UI Category.
Controls have four separate sections that we can configure:

1. Basics here we select the type of the control. The choices in the UI Element field vary with the
control mode. If the control mode is editable/read-only, it displays the following. For Read-Only
the choices are text and hidden and for action controls the choice is button/link/icon.
2. Options/List Source the choices here vary with the type of UI element we previously selected.
For all controls that are not list based, the options that display allow us to select the size, style
and additional properties depending on the UI element. For date fields it also lets us choose the
Date Picker: Notice it has some values already populated. These values are used as-is unless we
customize them.
217
For List based controls the List Source and Presentation sections appear. The list source
determines the source of the listing as well as the presentation of the list. Usually these are not
configured in the control since they are dependent on the application.
3. Format:The Format section is useful when configuring the presentation. Shown below we can
see how the TextInput UI Element is configured to present a Currency symbol. In this example, it
applies more changes to how the currency is presented than when the currency is rendered readonly. Format appears in the presentation tab at runtime for us to configure or override the default
selections made in the control rule. We need to remember that the presentation in terms of font,
color choice, size, width and other such configurations must be applied in the skin rule.
218
4. Behavior: This allows configuring how a change in value on this control will affect other data
elements. That leads us to the next topic where we learn more about configuring the behavior.
Most of our applications use standard auto-generated controls, so we can configure the options and
formats in the sections where the control is added. Behaviors are also configured in the section where we
add it. Practice adding controls in a section to see how you can configure the controls using three tabs
General, presentation and Actions.
The General tab consists of the property that the control is associated with, the label, visibility
settings and so on. List Source is also configured in the General tab.
The Presentation tab allows us to configure the items in the Options and format sections.
The Actions tab is used for setting the behavior, which we will learn about next.
219
Set Event-based actions on controls

Controls can also be used to apply actions based on certain events. The behavior is configured in the
Actions tab using an Action set. An Action set has two components Event (when we want the action to
occur) and Action (what we want to perform). In this example, when the value is changed on the
dropdown control, (configured by the Change Event) it saves the value that is selected in the dropdown
(using the post value action.)
Other Events
In addition to change we also have other events. These are classified as Mouse or Keyboard events.
Actions
When clicking Add an action, the system lists all the common actions. We can use the All actions link to
see the list of all possible actions.
220
Action Sets and Multiple Actions

The same event can trigger more than one action, such as when a case triggers both Post Value and
then Refreshes the section when the value changes. One point to consider is that it does perform these
actions in the order it was defined. So in this case it saves the value and then refreshes the section. If we
switch the order, the refresh section happens before the value is saved.
We can add an additional event in the same action set. When adding an event the actions are performed
when either of these events occurs. This is useful when we need to add a keyboard event corresponding
to the mouse event in accessible friendly applications.
If we need different events to perform different actions then we need to create it as a new action set.
221
Auto-complete to select from a list

PRPC comes with several list based controls to handle various UI requirements. For a handful of options
(ranging between 2 and10) we use radio buttons or check boxes (to select one or multiple actions
respectively). The dropdown control is useful when we want to present them in a select box which shows
only the selected value. The select box can accommodate a larger list. When the list of options from
which the user selects is in the hundreds, a drop down is not feasible because users cannot scroll down a
list of 100 items to pick one. This is where the Auto-Complete becomes very useful.
How does auto-complete differ from a dropdown? The auto-complete looks like a text box with a special
icon at the end to indicate that it is an auto-complete control. When users enter one or more characters in
the auto-complete field, it filters the list to show only the options that match the entered string option.
Configuring Auto-complete
The auto-complete control provides lot of configuration choices in addition to the standard controls. Look
at the UI gallery for the many examples available for us.
222
1. Listing Source Similar to other list based controls such as drop down, we can select the
source for the list. We can select Data Page, a clipboard page or a report definition.
2. Search Results Configuration- Once the source is selected the system provides us with the
option to select the fields that can be used as search criteria. This section allows us to select
which fields appear in the auto-complete (using the Show flag), if the value in the field is being
stored in another property (using the SetValue flag) and if the field is used in the search (Use for
Search). In the example below, it uses name and employee type to show in the auto-complete,
however only name is being used in the search. Once the user selects a choice, the value of
Name field in that row is saved in the associated property.
Auto-complete looks like a grid if it uses more than one column, except all of the options are inside the
text box.
1. Search Method Auto-complete can be configured to search StartsWith or Contains, this can
be configured using the match start of string.
2. Search Results search results can be categorized using a specific field or can be configured to
display the best bets. Best bets display the most popular amongst the list of options at the top.
3. Number of Options we can also configure the minimum number of characters that a user
needs to enter before seeing the list of choices and also the maximum number of results that it
can display for performance reasons.
223
Cascading relationships using controls

In some cases, when a form is presented to users, the fields are related to one another. For instance a
selection of a category should restrict the list of products from which a user can select. Lets look at how
we configure this relationship? This is the screenshot for category. (Note other fields are cropped in the
image.)
The product which is dependent on this field is configured as shown in the screenshot below. Notice it
passes the category that is selected in the previous field as a parameter.
To make this work we need one more change. In the category field we need to configure an action set.
The Post value action triggers saving the category selection in the case.
PRPC supports cascading relationships to multiple fields as well. For example, if we select a country,
then the state, then the county and then the city, each of these fields accepts the selected value of the
dependent field as a parameter for its listing source.
The example above involved a dropdown control, but we can also use other controls, as well. For
example,country might use an auto-complete while state might use a drop down and city might display in
a repeat grid layout in addition to displaying other fields.
224
Conclusion
Controls are very useful in formatting the data elements especially their values when presenting them as
either read-only or in editable format. They are referenced in the property as well as in the section where
they are added. The same property can be presented in different formats using controls. Controls can
also be used to restrict the values that we can select when its used as a user input field or the actions it
can perform when we click a button control.
225
Dynamic User Interface

Introduction
User Interfaces are a key component in any case management application. UI screens of any PRPC
application consists of both static and dynamic content the static content displays on the screen every
time the screen is rendered while the dynamic content appears conditionally. Complex applications
require user interfaces to respond to user interactions to keep them dynamic.
Dynamic UI offer several advantages. Primarily they improve the user experience considerably. Static UI
does not suffice for all complex requirements. Dynamic UI makes the application more purposeful and
responsive instead of displaying dull static content which does not change irrespective of the user and
context.
It is extremely difficult to just use Static UI screens to build an entire application. One of the challenges
with screens based on static UI is that users need to click through or scroll through many screens to find
the content relevant to them and their purpose.
In this lesson, we will address the benefits of dynamic UI, learning about the various concepts and
terminologies that we need to use to apply the dynamic user interface. We will also learn about which UI
components plays a key role in creating dynamic user interfaces.
Illustrate the benefits of dynamic UI
Define Events and understand event processing
Define Actions and understand how they are triggered
Configure the action sets on a grid
Apply visible when and refresh when to create dynamic user interfaces
Learn about the navigation rule and how it is rendered
226
Dynamic User Interface

Dynamic User Interfaces is a term that refers to the concept that UI content should change dynamically
based on user interaction.
In PRPC, dynamic UIs require an event- action model. In this lesson will learn in detail about various
actions and events and how this model can be configured.
Lets look at this with a simple example: When the user clicks the refresh icon (Event), the screen
refreshes its content (Action). Dynamic UI requires us to define both of them (the event and the action).
When the event occurs the action associated with it presents the change immediately to the user. This
helps in creating a user interface that provides a great user experience.
Benefits
We do not need to clutter the user interface with unnecessary information. User forms are no longer
lengthy, they only display information that is relevant to the user.
We can refresh only a part of the screen, even a single cell so the changes appear seamlessly. Users
need not see a whole page refresh every time to see the dynamic content.
If the application uses a static model, the screen must be submitted to the server for the change in value
to take effect. This model forces us to build many screens, with many submit actions and potentially a
performance impact. All of this will surely lead to poor customer satisfaction especially since the user
experience is not good.
This concept is very powerful in PRPC there is a wide variety of supported events and also a wide
variety of supported actions.
227
Events
Events are used to trigger an action that makes the user forms dynamic. As we said earlier, there are a
wide variety of events available in PRPC. Lets look at few examples, when the user
1. Clicks a control such as button, link or icon
2. Double clicks a row in the grid
3. Right clicks on the entire grid
4. Presses Esc key in the keyboard
5. Selects MA in the state dropdown
6. Clicks the checkbox to enable or disable
7. Enters 5 in the quantity field
Thats a little of everything. So now lets see where we can associate events.
228
Event Association
If we look more closely at the examples, we can identify them easily.
1. Controls In most of the cases, we associate events on controls. The main purpose of a control
is to decide the presentation of the data element in the user interface screen. Events are not
defined in the actual control rule. They are defined in the cell where the control is added. So for
the checkbox example, we associate the event on the properties panel of the cell where the
checkbox is added.
2. Grids - The Events are configured by opening the properties panel of the Grid layout.
3. Expression Calculation The event occurs when a declare expression computes the value of a
property. This configuration is enabled by default on all newer PRPC versions. This configuration
is on the flow action rule form.
229
230
Actions
Now that we know about where and how we can identify events, lets take a look at the other part. OK, so
we identified the event, what happens when that event occurs? Thats defined in Actions. Using the list of
examples we saw earlier, lets see what types of actions can occur.
1. When the user clicks a control such as button, link or icon it opens a new window.
2. When the user double clicks a row in the grid it opens the row in edit mode.
3. When the user right clicks on the entire grid it shows a menu.
4. When the user presses Esc key in the keyboard it closes the assignment and goes back to
home page.
5. When the user selects MA in the state dropdown it updates the list of counties.
6. When the user clicks the checkbox to enable or disable it unmasks the password.
7. When the user enters 5 in the quantity field it displays a message that the user can order a max
of 1.
Similar to the list of events, a wider variety of actions can be configured.
231
Actions Association
Actions are usually configured along with the events using an action set. An Action set can be defined
both on controls and on grids. Refer to the Understanding Available Controls lesson for more
information on how we can define actions on Controls. We will learn about setting action sets on grids
later in this lesson.
Some specific actions can also be associated outside the context of an action set. They are directly
configured on the part of the screen where we want the action to take in effect. These actions can be to:
1. Apply a visible when condition on a cell or a section or a layout to hide or show its elements
based on a condition.
2. Apply a refresh when condition to refresh a cell or a section or a layout.
3. Apply a Disable when condition to disable the cell.
4. Apply a Read only condition to make the cell read-only.
Lastly, Actions can also be associated directly in a Navigation rule. The Navigation rule belongs to user
interface category and we will learn more about this rule in the last part of this lesson.
Now lets look at how to create an action set in a Grid layout.
232
Action Sets on Grids

An action set is the combination of an event and the action associated with that event, simply put, what
we want to happen when the event occurs. Action sets are defined in controls and in grids. If you have
not taken the Understanding Available Controls lesson, please go there now to read about setting Events
on the controls.
After a grid is added, an action set can be configured via the properties panel. The action set is
initialized based on edit operations. Below is the default set for a modal dialog.
Actions can be customized on grids, however the list of common actions is a little different from that of
controls. Again the All actions link opens up the complete list of actions.
233
234
Visible When
Visible when is the main mechanism that's used in PRPC to toggle whether or not some part of the page
is visible. Visible when can be applied on sections included in another section, on layouts, and on cells.
Visible when uses a condition.
Three Visible when options exist for dynamic layouts and sections.
Two additional Visible when options exist for cells:
Visibility conditions can also be added on grid layouts. We can configure to show/ hide the entire grid or a
specific row.
235
Conditions
Visibility options are:.
1. Always there is no visibility condition on this field, layout or section.
2. If not blank visible if the value of that field is not blank.
3. If not zero visible if the value of that field is not zero.
4. Condition (expression) uses a condition to determine visibility, visible when the condition is
true.
5. Condition (when rule) uses a when rule to determine visibility, visible if the when rule returns
true.
Condition builder
When we choose Condition (Expression) in the visibility field, the system provides the option of using a
condition builder to write expressions.
In the condition builder we could use an expression and add another expression using AND or OR. If we
need to write more than two expressions, its better to write it as a when rule. The Condition builder can
also be configured to reference a when rule. When we choose a when rule, it provides the option to select
true or false.
In addition to this, when we use expression, the system offers another key factor to choose.
What does this field mean? If this is enabled, the visibility condition fires on the client side. So at runtime,
the section code comes with a markup added to hide/show part of the screen based on the condition. If
this field is disabled, the section code does not contain the hidden part and it requires a communication
with the server to get the hidden part when the condition is satisfied.
Server communication is initiated by refreshing the section which leads us to the next topic.
236
Refresh When
Refresh When allows us to have a portion of a page return to the server to refresh its content when a
specified condition is true. Refresh When can be configured to refresh either an included section or a
specific layout. Similar to Visible When, we can use the condition builder to add conditions.
We can configure the properties to respond to a condition and there is the option to use AND, OR to add
more than one condition. In addition to these, there are two keywords.
1. Changes This indicates when the propertys value is changed, in this example, it refreshes
when the discount is changed.
2. AddDelete This applies only on repeating groups, so a line item can be added to or deleted
from the purchase request.
We can also configure refresh of a specific row within grids. By default, the row never refreshes; we can
configure it to refresh on a specific condition
Unlike Visible When, a Refresh When conditions can also be configured using an action set. The action
set allows refreshing the current section or another section by its reference.
237
Disable When and Read-Only When

Disable whens can be applied only on a control, we can disable using an expression or when. Always
permanently disables it, while Never is the default choice for all controls.
Read Only whens can also be applied only on a control and the choices are not very different. Auto
means editable in most cases while read only can be applied as an expression or a when rule.
238
Run Conditions on Client

When using a condition to control the behavior of our dynamic UI, we can choose to evaluate the
condition either on the server or on the client. By default, events are processed on the server, unless
specifically configured to process on the client. Events can be processed on the client if:
The condition does not reference a When rule. When rules can only be processed on the server.
The condition contains no more than four (4) properties and constants, combined by Boolean
operators.
When the condition is configured to run on the client, the server sends all of the possible layouts to the
client, and the client determines which layouts to display and keep hidden.
The choice of client-side or server-side processing can have a significant impact on how the UI behaves
for end users, as outlined in the following table:
Client-Side Event
Server-Side Event
Fired client-side and changes seen without
Fired server-side and requires a
requiring a refresh action
refresh action to see changes
Refresh is not required since the html source
Content requested from server which
already has the content downloaded in client
changes the html source
side and is usually hidden using a markup

Can be applied only when using a direct
Can be used on all possible
expression for determining the visibility
conditions
Usually done in cases where the content is to be
It can be made to look not obvious
hidden, there is not a lot and it is more effective
by refreshing only that part of the
and quicker to save an extra trip to server
section that is changed
Example: Check if the user has AAA
Example: Display 5 recent
membership, enabling it opens up a textbox to
transactions and then click next 5 to
enter member number
see the next 5 transactions
239
Navigation rule and its usage

Navigation is a type of UI rule which is very useful in rendering a menu. The Landing pages in Designer
Studio make use of navigation rules. The screenshot below shows the Locale Settings landing page
being accessed by way of Navigation rules.
This is how the navigation rule looks in development:
This rule essentially has one tab (Editor) to configure. We add nodes using the icons in the header and
form a tree. Typically a parent-child relationship ( so in this example UI is the top level which then has the
UI gallery, Skins&PortalsTools) and then Tools has some child nodes. This rule is used by the main
navigation rule to have UI listed as a child for designer studio. (For an example, look at the navigation rule
named pxMainMenu.).
Other than setting the hierarchy, the next important part is to define the action. Actions can be added by
double clicking the row to open up the properties panel. We can also modify the type field. Item is most
commonly used. An Item list can reference a page list which is useful when presenting a dynamic list of
options stored as part of a pagelist. Reference is useful to refer another navigation rule.
240
How does the navigation rule get referenced? There are multiple options:
1. We can reference it in an action set either using a control (such as a Button, link) or on the grid.
2. In the menu bar control. (Refer to the PDN article listed in the related content for this.)
3. Using the reference keyword in a navigation rule.
To access a Navigation rule, we need to define an action set that can have an event (click, doubleclick,
rightclick, etc.) that invokes a specific action (Display Menu) [Action_Nav_rule.png]
Conclusion
Dynamic User Interface is a very powerful feature that comes handy in implementing smart looking user
interfaces that interact with user choices. Presenting content dynamically gives us flexibility in defining
various layouts, section includes and cells that can be hidden and made visible only when required.
Dynamic UIs are useful in presenting updated property values that are populated using a declare
expression seamlessly.
241
Module 06: Automating Business Policies
Data Transforms
Activities
PegaPulse
Case Attachments
Routing
Get Next Work
Correspondence
Ticketing
Declarative Processing
Declaratives Rules
Delegating Rules to the Business User
Automating Decisions
Validation
242
Data Transforms
Introduction
The Data Transform rule is a powerful tool in Pega 7 which makes data manipulation on properties and
pages easy and efficient. Data Transforms map data from a source to a target, performing any required
conversions or transformations on that data. The source could be one case such as a purchase request
case and the target could be another case, such as a purchase order case. To create the purchase order,
we might require data regarding the vendor from whom we bought the items on the purchase request.
In PRPC, Data Transforms are part of the Data Model category and are instances of the Rule-Obj-Model
rule type.
Explain the purpose of the data transform rules
Define the action in data transform rules
Describe the iteration of pages and symbolic indexes
Express where to reference data transform rules
243
Data Transform Purpose and Rule Form

There are multiple situations in which the use of the Data Transform is more appropriate than any other
rule type. Whenever we need to set properties values on a given page, whether they are the initial values
or updated values, a Data Transform is the best option. For example, we can set the default value of Full
Time for the employment type of any new hire. This can be changed in the user interface later, if needed.
Also, when updating property values on a page using properties from another existing page there is no
better option than using a Data Transform rule. For example, if we plan to have our purchase delivered to
our home, then our billing address and shipping address are likely the same. We can have a Data
Transform rule read property values from one page, such as the billing address, and copy those
properties to another page in this case, to the shipping address. We can also use it when there is a
need to append a new or existing page to a page list or to append and map properties from one page to
another page. Multiple features in PRPC accept a reference to a Data Transform rule.
In general, there are only a few situations in which a different approach might be more appropriate than a
data transform:
A property value should be set declaratively, rather than procedurally. To set a property value
declaratively, use a declare expression rule instead.
When defining source data for a data page. Depending on the source of the data use of a report
definition, database lookup, or activity may be more appropriate.
Updating data in a database. Data transforms do not provide any means to write data to a
database.
First, lets look at the Data Transform rule form itself (shown below). The Definition tab is where we
define the actions to be taken. They are presented as a sequence of rows in a tree grid. We will discuss
the structure in detail shortly. The next tab is the Parameters tab. On the Parameters tab we can either
list the variables that input data to, or return data from, the Data Transform. Variables defined here are
referenced on the Definition tab by the notation Param dot ParamName. We use the Pages & Classes
tab to specify the pages referenced on the fields of the Definition tab. These two tabs are standard tabs
for most rules.
Lets look at this example to review the capabilities of the Data Transform rule.
In the first row, we delete the vendorlist page from the purchase request.
In the second row, we iterate through each of the line items that comprise the LineItems page
list. The rows indented under the second rows are performed for each page of the page list.
In the third row, we check whether the vendor listed in the specific line item is unique or not, using
the when condition IsDistinctVendor. Any rows indented under this row execute only when the
condition is true. Otherwise, the data transform skips the indented row(s).
In the fourth row, the unique vendor information is copied from the source line items to the target
vendor list whenever the vendor is considered unique, as determined by the when condition in
the third row.
Data transforms can be chained with other data transforms defined in their parent classes. To do this, we
need to enable the Call superclass data transform? checkbox, and the data transforms must share the
same name.
244
PRPC checks for the same name in all the parents of this class following both pattern and directed
inheritance. Then it applies all the data transforms starting with the deepest ancestor continuing for each
child upward.
From the pyDefault Data Transform for the Purchase Request case, we can use the open icon next to the
check box to open the Data Transform of the parent class and keep going until we find the deepest
ancestor. From the chain, we can see nothing is set for @baseclass first, and it sets pyWorkIDPrefix as
W- in Work-. Then when it applies the data transform in Work-Cover- it sets the same property as C-.
Finally, it applies the data transform in the Purchase Request class, so the WorkIDPrefix is PR- when a
new purchase request instance is created. This is a powerful feature to set default values for the
properties at the appropriate level.
245
Structure of Data Transform Definition

We use the Definition tab to manipulate the data. Understanding this tab helps us to ensure we have the
correct steps at right place and avoid any potential defects due to the wrong data being transformed. The
Data Transform rule definition is a sequence of rows. The system invokes each row in sequence starting
with the first row except for the conditional and transitional types of actions.
There are four columns on this tab:
Action This is where we identify what the step is for. This is required for each step. We will look
at the different actions that are possible shortly.
Target Most actions require a target. In cases where an action is not required, we cannot select
one. The smart prompt box acts both as a select and a text box. We can select a property from
the list or we can type text.
Relation This is an optional column. The typical relationship between source and targer is
equal to. There are few actions that use other relationships.
Source This becomes selectable only if the action requires a source. We can specify literal
values, properties or expressions. We can, for example, set the target property Employment
Type as the value Full Time, target property Full Name as the concatenation of two other
properties First Name and Last Name, and target property Rate as an expression, namely,
the sum of source properties BaseRate, LoanRateAdjustment, and RiskRateAdjustment.
To add rows we can use one of two options. We can click the Add a row icon or we can right-click on
any row to access the context menu. The right click menu is context sensitive, so the choices depend on
where we click. In some cases, when we add a child it adds a tree like nested structure. We can use the
Delete this row icon or the right click and select delete from the menu.
As a best practice, and to improve readability, do not create more than 25 steps. If we need to define
more than 25 steps, we can group some of the actions and define them in another data transform rule.
We will see how we can reference another data transform rule from one data transform rule shortly.
Lets look at some of the key actions available to us.
246
Set is used to set the target from a source. We can set a value to a Single Value property which exists in
the top-level page such as the pyWorkIDPrefix or in an embedded page such as the LoanType in the
LoanInfo page.
Remove is used to delete the target and any associated values from the clipboard.
We can also use Update Page to set the properties defined on an embedded page. When we use
Update Page we need to set individual properties using the Set action with the nested rows after the row
with Update Page. In fact, we have the option of selecting any of the actions shown above for the
nested rows below the Update Page row.
We can reference another data transform rule from our existing data transform rule. This might occur if
we are going over 25 steps and want to break the rule into smaller manageable data transforms. Or we
might have a reusable data transform, such as one for initializing a case with some default values.
Whenever we need to invoke a Data Transform from another data transform rule, we use Apply Data
Transform.
Conditional Actions are Data transforms that execute all the actions in the order defined. However there
are a few conditional actions that are available to add logic, to perform steps based on a condition.
When To conditionally perform actions.
Otherwise When and Otherwise To provide actions for the alternative to the When actions.
We can also iterate over a pagelist using For Each Page In action. Using this action we are able to apply
the change for all the child nested rows of the page list. We have the option of selecting any of the actions
for the child nested rows, such as Update Page. Update Page is primarily for a single page, while For
Each Page In is for a page list. We can use the Append to action to copy a page from the source to
the target. For instance, if we want to add a new page to the Assets page list, we can select new page.
We can also add another existing page or copy all the pages from another pagelist, by selecting the
appropriate values in the drop down in the relation column. Append and Map to is used to map
individual properties in the page list. When we select this action, at least one nested child column is used
with Set action.
If we dont want to loop through all the pages in the pagelist, we can use the Exit For Each condition to
exit the loop, or we can exit from processing all the remaining steps with the Exit Data Transform
condition. Typically, we have these steps after a when condition.
247
Use of Symbolic Indexes

When we are iterating through the pages or updating a page, we dont know the index of the page on
which we are working. We iterate through the pages in both Data Transform and Activity rules.
As we iterate through the list of the line items page list, <CURRENT> represents the current index of the
iteration.
Here is the list of symbolic indexes that we can use when we loop through the iteration:
<CURRENT> - Identifies the index of the current iteration
<APPEND> - Inserts the element at a new position at the end
<LAST> - Retrieves the highest index
<PREPEND> - Inserts the element at the top
<INSERT> # - Inserts the element at a specific position that is indicated by the number
Param.pyForEachCount Same as <CURRENT>. Identifies the index of the current iteration.
This can be used for the Page index and in the expression as well, while <CURRENT> can be used only
for the Page index.
For Data Transform rules, we cannot use the <APPEND> keyword in the For Each Page In
action. Instead, we need to follow the For Each Page action with an Append to action or Append and Map
to action. We can use <APPEND> for Update Page action in the Data Transform and also for looping
through in the steps of an Activity rule.
While we are discussing symbolic indexes, lets understand two more keywords that are useful to
access the correct pages. These are used in a host of rules, wherever pages are referenced.
Top Refers the top most page of the embedded page.
Parent Refers to the parent page of the embedded page. If the embedded page has only one parent,
and no grandparents in the hierarchy, Top and Parent refer to the same parent page.
248
Data Transforms in Business Processes

Data transforms can be referenced in multiple rule types during the execution of the business process.
Lets look at the key data transforms that would be used in our business scenarios.
In the starting processes of a case, the data transform rule is defined on the Processes tab, which is
invoked to set initial properties for the case instances. The starting process has the Creates a new work
object setting selected as shown below.
Anytime when we create a new case either through an explorer, or create new cases with a new
application through Application creation wizard, PRPC creates pyDefault. We always recommend that we
use the same name for all starting process to take advantage of the chaining. The main purpose of Data
Transform usage in the process tab of the starter flow rule is to initialize the properties of the case
instance, when it is instantiated.
Here is an example where we initialize the properties of a Purchase Request case. When a case instance
is instantiated, it is initialized with who it is requested for, the cost center is, and the currency.
249
In the case hierarchy, we use the data propagation configuration to propagate the data from the parent
case to the subcases when the subcases are instantiated.
We can propagate the data from the parent case Purchase Request into the subcase, Purchase Order. If
we are simply taking the data without making any changes, we can use the data propagation option and
we do not need to select Also apply Data Transform. If we are using the data conditionally or looping
through a pagelist or if we need to reuse propagating data from parent to subcase in other rules, we can
use the Also apply Data Transform, option and use a Data Transform rule.
We can also use a Data Transform rule in a step where a subcase is instantiated from the case designer
of the parent case. We propagate the data this way if we dont want to take advantage of propagating the
data from Case Designer Data Propagation configuration. Lets say, we are creating Inventory
Selection step in two steps of different stages in the Purchase Request case, and in those steps, the
data that needs to be propagated is different. In this scenario, we need to reference the different data
transform rules in the step configuration, instead of relying on the one data transform rule referenced in
the data propagation settings in the details tab of the case designer of the parent case. The example
shown here is using CopyLineItemsPO data transform when creating multiple subcase instances of the
250
Purchase Order case in the step configuration of Create Orders step of Purchase Request case stage
design.
For each step, there is an appropriate flow rule associated with it. A step of step type Case uses the
Create Case(s) smart shape in the flow rule for that step. Referencing a data transform on step
configuration is the same as setting the properties on the smart shape in the flow rule. We can modify it in
either place and it is reflected in the other place.
To avoid accidentally overwriting data when a subcase is instantiated, it is important to understand the
order in which an application evaluates these Data Transforms:
1. First, the application applies the Data Transform on the starting flow of the subcase
2. Next, the application applies the data propagation and Data Transform configured on parent case
type rule (defined on Case Designer Details tab)
3. Finally, the application applies the Data Transform defined on the case instantiation step in the
Case Designer of the parent case, or the Data Transform defined in the Create Case(s) smart
shape in the create case flow rule of the Parent case.
In flows, on any connector between any two shapes, we can set properties or reference data transform
rules. If it is a simple setting of one or two properties, we can use Set Properties. But, If we are using
data conditionally or looping through a page list or if we need to reuse the data transform in other places,
we can use the Also apply Data Transform, option and use a Data Transform rule. For example, when
the flow is processed on a decision shape, on the connectors, we can use the appropriate data transform
rules based on the decision made by the end user.
In Flow actions, we can specify a data transform on the flow action's Action tab. To populate the
properties from another page, we can invoke a data transform in the before this action area. If we want
to copy the values submitted in the user session to another page, then we can invoke after the action is
submitted.
251
We can reference a data transform in a section rule, for a change event of any cells directly, and also we
are able to reference a data transform if we select Refresh This Section for the client change event. This
is handy, when we change a value from a drop down or select a radio button. Lets say, a business
requirement is, that for the state of Texas, the state tax is 0 % and the state tax for California is 6% and
so on and so forth. We can use a data transform rule when the state is selected from a dropdown and the
user interface is refreshed to show the tax to be deducted based on the state selected.
252
We can reference a data transform from another data transform rule with Apply Data Transform action,
as we described earlier in this lesson. We can also reference a data transform rule from an activity rule,
which we will discuss in the Activities lesson.
Conclusion
We learned that Data Transforms can process steps in sequence.
Data transforms rules can be used for setting and manipulating data such as:
To set default values for the properties defined on a clipboard page.
To copy one clipboard page to another clipboard page.
To map properties defined on one page to another page.
To append properties from one page list property to another page list property.
To iterate over pages in a page list property to map data on each page.
We can reference Data Transform rules in a host of other rules wherever we need to set and manipulate
data as in the list above.
253
Activities
Introduction
Activity rules provide us with one way to automate the processing of work in PRPC-based applications
using a program-like approach. It consists of a sequence of steps executed procedurally.
In PRPC, Activity rules are part of the Technical category and are instances of the Rule-Obj-Activity rule
type.
Each step can call a PRPC method, transfer control to another activity or execute custom inline java
code. As a programming tool, it also provides features such as iterations and conditions. While activities
can appear to some as an easy and flexible way to automate work process, they can quickly become
complex to analyze, execute, debug and maintain. Consequently if writing an activity is our only option,
we must keep the following best practices in mind. Keep activities short, no more than 25 steps, and
avoid inline hand-coded java as much as possible by using library functions instead.
Understand the Purpose of an Activity Rule
Configure the Tabs of an Activity rule
Configure an Activity Step
Use common methods in an activity
254
Purpose of an Activity Rule

Activities are structured as a series of steps which are executed in sequence. Each step references a
method, or another activity, or can contain plain java code.
Lets look for at alternatives before diving into writing an activity. Programmers tend to write too many
activities since they relate to other programming languages that they may know. However, activities are
harder to maintain and not as easy to construct as other rules in PRPC.
We should not use an activity for calculations or property validations that we can implement as
constraints rules or Declare Expression rules. Use of a declarative rule (rather than an activity) eliminates
the need to control how and when an activity executes. A best practice is to use declarative processing
rather than activities when feasible. For data manipulations, we can use a Data Transform instead of an
activity. To query from an external DB, we can use Report Definition rules instead of activities.
We may need to automate the processing of cases with a sequence of steps to be executed. Most of the
time, this is possible with the steps in the case designer or multiple shapes in a flow rule or with
declarative rules or data transform rules or a combination of those and other rules.
Before writing our own activities, lets look at the standard activities that come with PRPC. These are
called API activities; they are accessible from the landing pages. We can search for an activity and each
activity has a description explaining what it is used for.
There are times when we need to use activities and in order to find out if one exists, we use APIs. Some
standard activities we can use are CorrNew to create and send emails, AddWork to create a new case
instance, and UpdateStatus to set the status of the case instance.
Here are some scenarios where we cannot avoid writing an activity. For example:
To perform Case related functions such as creating a case instance, routing the case, or updating
the work status, as part of certain operations such as parsing an input file.
To send requests to external systems or to receive requests from external systems.
To perform functions such as writing to a log file or to the history database.
Lets take a look at the Activity rule form starting with the standard activity, UpdateLocaleSettings. The
steps tab is where we define the steps to be processed. They are presented as a sequence of rows in a
tree grid. We will discuss its structure in detail shortly.
255
Configuration of Tabs of an Activity Rule

We need to understand the Parameters, Pages and Classes, and Security tabs first to understand the
Steps tab.
We use the Parameters tab to identify any variables serving as input or output parameters to the activity
rule. We can reference the properties listed here as Param keyword (Param.PropertyName) in the Steps
tab for any processing. The Local variables section identifies scalar variables, and they are stored as
fields in the java class that PRPC generates to implement the activity. They are often used to pass
information from step to step. We can reference the properties listed here as Local keyword
(Local.PropertyName) in the Steps tab for any processing.
Before writing an activity, it is important to understand the three common page types we will interact with.
They are:
Primary pages
Step pages and
Parameter pages
A Primary page is a clipboard page which has the same class as the Applies To class of the activity and
is designated when the activity is called. This page is the default location of properties referenced with a
dot and no preceding page name. For greater clarity, we can reference a property on the primary page
using the keyword Primary followed by a dot and the property name.
When a Branch or Call instruction executes as defined in a step in the Steps tab, the page in the Step
Page column of the step becomes the primary page of the called activity. If the Step Page column is
blank, the primary page of the current activity becomes the primary page of the called or branched-to
activity. That is, the primary page of an activity becomes the step page of each step, except for steps
where the Step Page column is not blank. The step page becomes the primary page for the duration of
this step's execution.
A parameter page contains parameter names and values, as listed in the parameters tab. It has no name
or associated class, and is not visible through the Clipboard tool. However, we can display the contents of
the parameter page with the Tracer tool.
On the Pages and Classes tab, we list the pages used in the steps of the activity along with their
classes.
256
The Security tab has a few settings that allow us to set who can access the activity and how.
Allow direct invocation from the client or a service check box indicates whether user input
processing can start the activity or it must only be called from another activity.
The authenticate checkbox, when selected, only allows authenticated users to run the activity.
The Privilege Class and name identify a privilege a user must have in order to be allowed to
execute the activity.
The Usage type determines whether and how the activity can be referenced in other rules. Select
one usage type depending on the intent of the activity.
257
Configuration an Activity Step

We use the Steps tab to do sequential programming steps.
Each step of an activity contains multiple parts. There are non-action items such as Label, Description
and Step Page. Other parts such as Loop, When, Method and Jump to indicate an action or condition for
an action.
The Label provides an identifier for the step that can be referenced from other steps. The label name is
used in the When and Jump conditions, which well look at later. We can also put two slash characters as
a step label to indicate to Process Commander not to execute the step. Such steps can also be used as
comments.
The Loop allows us to setup the iteration through the elements of a Value List, Page List, Value Group or
Page Group and performs the provided activity method on each value or each embedded page.
As we iterate through the loop, we can select the For Each Page option to sequence through all pages
of a specified class or classes and perform a method or instruction for each page. Leave the Step Page
field blank. Each time the step repeats, the step's page changes internally automatically.
Use the For Each Embedded Page option to apply a method or instruction to each embedded page in a
Page List or Page Group property. Identify the property containing the embedded pages in the Step Page
field.
For the optional Valid Classes (Only loop for certain classes as shown below) parameter for these two
Repeat conditions, we can enter a class or classes. We can click the Add Row icon to add more than
one class. When valid classes are populated, iteration processing only processes pages of the valid
class list and the ones derived from them and skips over the pages of classes that are not in the list.
258
We can select the For Each Element in a Value List option to repeat the step for each element in a
Value List property. When we select this iteration form, a Property Name field appears. Identify the Value
List property in the Property Name field.
We can select the For Each Element in a Value Group option to repeat the step for each element in a
Value Group property. When we select this iteration form, a Property Name field appears. Identify the
Value Group property in the Property Name field.
We select the For Loop option to repeat the step a number of times determined by the values of integer
constants or integer properties. Enter integer constant values or integer property references for the Start,
Stop, and Increment fields. The Increment must be a positive integer.
To add a child step to an iteration, right-click the iteration step and select Add Child.
The When allows us to define a precondition that controls whether the step is executed or skipped.
259
We need to check the Enable conditions before this action to display the row where we can enter a
condition or reference a When rule. When the rule returns true or false, we can select one of the
conditions.
Continue Whens
To continue to evaluate other when conditions if any
Skip Whens
To skip processing rest of the when conditions if any
Jump to Later Step
To move to a later step with the label of the step noted in the param field
Skip Step
To skip the step and to move to the next step
Exit Iteration
To skip the iteration and to move to the next iteration in the same step
Exit Activity
To skip processing rest of the steps in the activity
The Method indicates which Process Commander method the step will execute. We will look at some
common methods that we can use, later in this lesson.
The Step Page, as mentioned earlier, identifies a Page to be used as the context for referenced
properties within the step
The Description is text that explains to other developers the action that the step is performing. As a best
practice, always provide a comment for each activity step.
The Jump condition or post condition is similar to the When precondition. After the step is executed, a
condition is evaluated. Based on the result, the activity may perform different actions such as jump to
another step, or exit the activity. Also, there is another option of what needs to be done in case of an
exception in the step processing.
260
Some Common Methods

Process Commander provides an extensive library of methods that we can use in our activities. We can
use the expand method button to expand the parameters for the selected method or activity.
Some common methods are:
Property-Set used to set the value of one or more properties. If this is the only step, we would
be using a data transform rule instead of activity rule. When setting the properties, we can use
any of the symbolic indexes that we had described earlier in this lesson.
Call used to find and execute another activity. After the called activity completes, the calling
activity resumes processing.
Page-New creates a blank clipboard page of a class specified.
Page-Remove used to delete one or more named pages from the clipboard. If no page is
specified, the page referenced by the step page will be removed.
Apply-Data-Transform used to invoke a Data Transform rule directly from a step.
A full list of the methods provided is available in Developer Help.

PRPC enhancements are continuously reducing the need to create activities, but there might be
occasions when we cannot avoid using them. Some of the activity methods operate on pages and hence
we can use a Data Transform. When using the Page-New method, a Data Transform rule can be
specified to set some initial properties values on the new page. Similarly, the Page-Copy method allows
a reference to a Data Transform rule which is applied to the destination page before copying data from
the source page. Page-Change-Class method also allows a reference to a Data Transform rule in the
target class or any of its parents to be applied to the page when changing its class.
Conclusion
Best practice is to use data transform rules, declarative rules, report definitions, and so on, in place of
activity rules. All the actions provided by a Data Transform rule are also possible through an activity.
However, using a Data Transform rule speeds up development as its rule form is easier to read than the
activity rule form. In addition, a Data Transform rule provides runtime performance improvements over an
activity.
In some instances an activity rule cannot be avoided, often times they are mandated, for example,
Service Rule Request processing
261
Pega Pulse
Introduction
PegaPulse is a rich social platform that adds social activity streaming capabilities to the user interface.
We can collaborate and converse with other application users or developers.
By default, PegaPulse section is included in the standard portals, where we can share messages, URLs,
and files with others in our work group. It is included in the standard perform harness as well; hence
when processing cases, we can share messages, URLs, and files. Here we can set the shared content to
be viewed in either public mode or private mode. In private mode, only those who have access to the
case can view the content. In public mode, anyone who has access to the case and also users in the
workgroup can view the content. Workgroup users can view the content in the standard portal interface.
A Social User Profile is the profile for any user that includes their name, position, phone, etc. When we
click on the link of any users profile, not only can we see that information, but we can also send a
PegaPulse posting to only that user.
PegaPulse is limited to attaching conversations, URLs and files, compared to Case Attachments where
we can attach screen shots, scanned documents, etc. In PegaPulse, we can take actions such as
creating a task, which we cannot do with Case Attachments. We can use the Post to Pulse SmartShape
to have a Pega Pulse posting added to case instances. Similarly we can use the Attach a Content
SmartShape to add attachments to case instances. The attachment types are limited in PegaPulse; while
Case management lets us add more attachment types. For more information on Case Attachments, see
the Case Attachments lesson in this course.
We can view the details of the PegaPulse in the following video.
Describe PegaPulse as a social platform
Explain the Contextual Activity Stream in different contexts
Determine how to view Social User Profile and send individual messages.
262
Configuring an Application to Automatically Post to Pega Pulse

To automate the posting of an update to the contextual activity stream, we can use the Post to Pulse
smart shape. The properties panel for this shape contains four configuration options that govern how
updates can be viewed.
The User posting drop-down list lets us select the user under whom the system adds the update to the
contextual activity stream. By default, posts are attributed to the assigned operator (Current Operator).
We can also select Other, then select the operator ID we want to use.
The Message field contains the content of the automated post.
The Message pertains to the current case and Make secure post checkboxes allow us to configure
the availability of the post. The Make secure post option is available only when Message pertains to the
current case has been selected.
Message pertains to the current case is
disabled.
Post is public and appears in the Pega Pulse feed in

the Case Manager.
Message pertains to the current case is

enabled, Make secure post is disabled
Post is public and appears in the Pega Pulse feed in

the Case Manager. Post references the case ID.
Both Message pertains to the current case and

Make secure post are enabled
Post is private and only appears in the Pega Pulse

feed when the case is opened.
263
Conclusion
PegaPulse is a rich social platform built into PRPC that can easily be integrated into Pega applications for
the purposes of collaboration, document sharing , and conversation among application developers and
end users.
PegaPulse content, whether it is message or file or URL, can be shared among the workgroup users only,
to those only involved in a case instance, or to any individual user directly.
If PegaPulse needs to be included in other harnesses, or in any user interface rule, simply embed a
section rule, @baseclass.pxActivityStream.
264
Case Attachments
Introduction
During the normal sequence of processing a case instance, we may have to add attachments to enable
users to take the appropriate actions and also for future reference. When we process an insurance claim
for an automobile accident, we can attach the police report to identify who is at fault.
A case attachment can be a file, screen shot capture, URL or text note. By default, case instance
attachments are stored in the pc_data_workattach table as instances of concrete classes derived from
the Data-WorkAttach- class. They are not stored directly with the case instances in the same table.
We learn how to add attachments manually and automatically. Suppose, we want to provide access to
certain users so they can add attachments and we want to provide rights to delete attachments only to
managers. Using the Attachment Category rule type we can enable security and restrict access for
certain attachment operations.
Describe how to add attachments manually to a case instance
Explain how to add attachments automatically to a case instance
Explain how we can restrict access to attachments
265
Adding Attachments Manually

PRPC comes with six types of attachments. They are identified by concrete classes derived from the
Data-WorkAttach- class. We have:
Note attachments from the Data-WorkAttach-Note class;
File attachments from the Data-WorkAttach-File class;
URL attachments from the Data-WorkAttach-URL class;
Screenshot attachments from the Data-WorkAttach-ScreenShot class;
Scanned document/image attachments from the Data-WorkAttach-ScanDocument class; and
Enterprise Content Management attachments from the Data-WorkAttach-ECM class.
While processing a case, end users can add attachments to a case, for future reference. We can do so
easily with the standard perform and review harnesses. On the right hand side, we can use the Case
Attachments section to add attachments. We can use the Add or Advanced link to add attachments.
We can attach a File or a URL using the Add link.
When we click the Advanced link, an attachment listing window pops up and it has an Add dropdown
button. Using the button, we can attach a Note, File, URL, Screenshot and a Scanned Document.
The Attachment user interface is slightly different for each of these choices so lets quickly look at how
they work.
When we click Attach a File from either menu, we get the Attach a File dialog box, where we can drag
and drop a file or browse to the file folder and select a file to attach it.
When we click Attach a URL from either menu, we get the Attach a Link dialog box, where we can
enter a subject for a description or why we are attaching the link, and the URL.
When we click the Attach a Note link in the advanced menu, we see the Attachment dialog box and
we can enter a subject and the text for our note.
266
When we click the Attach a Screen Shot link in the advanced menu, we see the Attachment dialog box
and we can select a window name from the drop down and enter a note as description/reason for the
attachment.
When we click the Scan and Attach a Document link in the advanced menu, we see the Attach Scan
Document dialog. We first need to scan a document before we can attach it. So, from the Select Source
button, select a scanner. Next select the Scan button and we will see the scanned document in the
viewer.
As mentioned earlier, there is also the Enterprise Content Management attachment type. We can
configure our application to store attachments of type file in an external enterprise content management
system (or ECM) using the CMIS protocol such as Microsoft SharePoint or IBM FileNet. We can enable
this option by selecting a checkbox on the application rule Integration tab. We can select this checkbox
267
to enable content management system integration for the application. Two more fields are needed in
order to properly ensure the attached files are stored in the ECM.
We use the Connector Name to specify the Connect CMIS rule used to connect to the external CMS
system.
If the Connect CMIS rule has not been created before, we can click the magnifying glass icon to create
the rule now. The second field, CMIS Folder, provides the Browse button to select the directory
location on the content management system in which we are going to store work item attachments for this
application
Anyone who has access to this case can view the list of the attachments and can also view the contents
of the attachments. In the Attachments section, we can see the list of attachments associated with this
case. To view the contents of an attachment, just click on the link.
In the Advanced attachments window, attachments are grouped by type. Here we get to see the timing,
description, and who attached it as well. If permitted, we can also remove the attachment if the
attachment is not required. For quick viewing, we can use the attachments section in the harnesses. To
see other details and/or to remove the attachments, we can use the advanced attachments window.
If the perform or review standard harnesses are customized, or some other standard or custom harness is
used, the case attachment section may not be available to end users to add attachments. In that
268
scenario, the system architects can provide a local action to the end users; end users can select the local
action menu option from the other actions menu. All attachments types can be added as a local action.
AddAttachments allows us to add a file attachment and assign it to an attachment category.
AddMultipleAttachments though provides the ability to add multiple file attachments, with a
category for each, in a single action. For every attachment types, there is one flow action.
AttachAFile as its name implies is used to attach a file to the work item, including an explanatory
note but no attachment category.
AttachANote flow action prompts users to type in a text note that becomes an attachment to the
case instance.
AttachAScreenShot is used to select one window from a list of windows on the Windows
desktop, and then capture and attach a screen shot JPG image to the case instance with an
explanatory note.
AttachAUrl is the flow action you might use to attach a URL reference to the work object with an
explanatory note.
AttachFromScanner allows us to start the Image Viewer tool to scan, view or update a TIFF file
from a scanner and attach it to the case instance.
AttachmentForECM allows us to attach a document from content repository to the case

instance.
269
Adding Attachments Automatically

There may be times where we want to add the attachments automatically to the case, so users do not
need to add them manually as optional steps. For example, if the same file should be attached to every
case instance of a certain case type, there's no reason to use a flow action and require user input.
To add a note or link or file, we can use the Attach Content smart shape in the flow rules. In the flow
rule, when the smart shape is processed, an attachment is attached to the case instance automatically.
End users can view the attachment in the same way as before, in the perform and review harnesses.
When attaching a file, we can either choose to attach a binary file from a folder or to reference an
attachment from the case type.
Attach a URL and Attach a note options require a URL and description, and a note and description,
respectively.
As part of attaching a file automatically, we can generate a PDF file and attach it to the case. To
accomplish this, we can use the smart shape Create PDF. For example, a list of the purchase request
items can be generated as a PDF file and attached to the case instance. We provide the section name
that has the data that needs to be included in the PDF file plus the description. The description is used for
the PDF file name.
270
Once the PDF file is generated and attached, it can be viewed the same as other attachments.
271
Security through Attachment Category

Process Commander provides a powerful tool to restrict operations that can be performed on case
attachments. We restrict access using the attachment category. The attachment category is a business
classification to indicate the content or significance of the attachment. It is different from attachment type.
At the same time, it is used to control operations on attachments including create, edit, review or delete.
In PRPC, Attachment categories are part of the Security category and are instances of the Rule-ObjAttachmentCategory rule type. Below is the standard File Attachment Category rule. This rule can be
specialized by copying to a different ruleset and Applies To class. We can reuse the standard categories
or create entirely new attachment category rule instances, such as invoice, packing slip etc. Two main
tabs are available on the rule form. On the first tab, Security, we can control access to the attachments
through Privileges or/and When rules.
In the Access control List by Privilege section, we can select a privilege rule in the Privilege Name
field. The system uses the Applies to class of the attachment category to validate the privilege name.
We can select any of the following checkboxes that apply. If the checkbox next to an option is not
selected, the qualified user cannot perform it.
Create to grant users the ability to add attachments of this category if they have the privilege
in the Privilege Name field.
Edit to grant users the ability to edit attachments of this category if they have the privilege. The
permission to Edit implies permission to view.
View to grant users the ability to view attachments of this category if they have the privilege.
Delete Own to grant users the ability to delete attachments of this category that they added
earlier if they have privilege.
Delete Any to grant users the ability to delete any attachments of this category if they have the
privilege. The permission to delete any implies permission to delete own.
We can add multiple privileges by using the Add a row icon. When we have multiple rows, users must
hold at least one privilege to gain access. The order of rows in this section is not significant.
We can also define a list of When rules to control access to the attachments. In this case though, all
When rules must evaluate to true for a qualified user to be granted access.
In the Access Control List by When section, we select a When rule in the Rule field. The system uses
the Applies to class of the attachment category rule to find the When rule. Next select any of the
operation checkboxes that apply. If an operation checkbox is not selected, the user cannot perform that
operation. The operations are similar to control by Privilege with the difference that they are now
controlled by a When rule rather than a Privilege rule.
The Enable Attachment Level Security option allows the operator at runtime who attaches a work
attachment of this category to identify one or more work groups that have access to the attachment.
272
When enabled, this attachment-level restriction operates in addition to and independently of any
restrictions defined on this tab for the category.
The next tab, Availability, provides a list of the attachment types. We select the checkboxes for the
attachment types that are valid for the category and the work type identified by the Applies to class of
this attachment category rule.
In this example, only File attachments are valid for this category.
If no types are selected, the category is not inaccessible. Instead, a default category rule in Work- class is
used for its respective type. The default category has no security restrictions.
When adding an attachment to the work item, users have the ability to choose the category to which the
attachment belongs.
Conclusion
End users can add attachments to case instances manually as needed. Or we can add attachments
automatically at a certain point of the flow. We can view the added attachments easily through the section
included in standard harnesses.
We can restrict who can add, view and remove attachments through the Attachment Category rule type.
We can reuse the standard attachment categories or create a new attachment category. When adding an
attachment, the end users can select an appropriate category for the attachment to ensure that the
attachments are secure.
273
Routing
Introduction
Routing is a critical component of business process management as it determines who can actually
perform the work required to complete a process.
As we learned in the introductory courses, an assignment of a case can be routed to an operators
worklist or to a queue known as workbasket. Assignments can be pushed to or pulled by an individual
operator. In this lesson, we will look at more details of the push versus the pull concepts.
Sometimes we want to assign a task to an external person who is outside of the organization and may not
have access to PRPC. For example, when we are processing a purchase request, we may want to get
quotes from multiple preferred vendors. The quoting task assignment is sent to the vendors and they can
respond to the assignment through web. This process is called Directed Web Access (DWA). We will
learn how we can configure DWA and how the external users can respond to the assignments in this
lesson.
We have seen some basic standard routers such as ToWorkList, ToWorkBasket etc., in the
introductory courses. Now we will learn about standard routers for advanced requirements.
Explain the concept of push versus pull routing and how to use each one effectively
Describe Directed Web Access (DWA) and how to configure it
Identify some advanced standard routers and when and how to use them
Determine work balanced and skill based routing
274
Push and Pull Routing

There are two basic types of routing: Push routing and Pull routing.
Push routing routes the assignment to a single users worklist, and as such there is immediate ownership
as soon as the assignment is created. PRPC can use multiple criteria to select the owner, including
availability (if an operator is available or on vacation), the operators work group, his/her skills, or current
workload. Depending on how the routing is configured, it is possible to route to a substitute operator if the
chosen operator is not available. The worklist shows all the assignments for that operator, which can be
filtered to show only specific case type instances and can be sorted using any column title. Users can
work on any assignment from the worklist.
Pull routing, on the other hand, routes to a workbasket that is shared across multiple users. Ownership
does not occur until an operator takes action on it. Most applications use GetNextWork logic to select
the most urgent assignment from multiple workbaskets. When this happens, the assignment is removed
from the workbasket and is assigned to the operators worklist. GetNextWork logic is covered in more
detail in another lesson. In most of the standard portals, we can pull the next assignment to work with
Get Next Work logic by clicking on Next Assignment button at the top of the portal.
Lets take a look at how routing is incorporated into a typical user experience, especially from a work
group manager perspective.
The case manager portal, typically for work group managers and other managers, shows a list of
operators in their work group on the right side of the dashboard.
275
As a work group manager, he/she has the privilege to view individual members worklists. Selecting a
particular operator (in this case, the operator named Purchasing Manager) shows all the items that have
been pushed to his/her worklist. There are at least three that have not been processed for a long time.
The work group managers and all the other operators can see the list of workbaskets to which they have
access, on their portal, on the bottom right hand side of the dashboard.
Selecting a workbasket shows the assignments in a particular workbasket. They are waiting to be pulled
by an operator.
276
An operator can select one of these items directly, which promotes it to his/her worklist, or use the
GetNextWork function, which selects an item for him. GetNextWork queries both worklist and workbasket
items. GetNextWork is a great way to ensure that the most appropriate item gets the most attention. This
way, we can prevent an operator from cherry picking the item that they want to work on from the
workbasket, instead of the items in the worklist.
277
Directed Web Access (DWA)

We might need to get information from external users who dont have operator credentials to login to
PRPC to provide the data that we are looking for. During the Purchase Request process, for the items
that we are planning to acquire, we can request for a quote for the specific item from an external vendor.
The vendor is not an operator who can log into PRPC.
Sending the assignment to an external user is called Directed Web Access (DWA), because the external
users accesses the assignment on the internet through a web browser. As a prerequisite, we need to
configure PRPC to send emails. (See Designer Studio -> Integration -> Email -> Outbound Email).
We can send the assignment to an external user, by selecting the assignment type as External in the
assignment tab. When we select this assignment type, we can configure what correspondence we want
sent to the vendor.
When the case reaches request for quote external type assignment in the flow, PRPC sends an email to
the vendor. The vendor gets an email as shown below, with a link.
278
When the recipient of the vendor organization, clicks on the link, they get the quote request flow action in
a web page. When they fill in the requested data and submit the flow action, the assignment and the flow
action are complete and the flow moves on to the next shape.
We need to configure URL that is to be sent in the emails. We can configure this through Designer Studio
-> System -> Settings -> URLs -> Public Link URL. Public Link URL is set typically in the
form http://nodename:portnumber/PRServlet, as shown below.
279
More Standard Routers

When we have the assignment type as WorkList or WorkBasket, we can select a host of standard
routers. The introductory courses covered some of the standard routers and the purpose of selecting
them. Now, lets look at some more standard routers.
We can see a list of standard sample routers list in the smart prompt for the router field.
Most of these routers are for push-based routing, which routes to the worklist of a particular
operator. Most of the routers are parameterized and we can enter the appropriate parameters
when we select a router.
ToWorklist routes to a particular operator by name.
ToWorkParty routes to a work party. The actual operator depends on the work object; for
example, if the workparty is Initiator, the actual operator is different for every work object. Work
Parties are covered in more detail in another lesson.
ToWorkGroupManager and ToOrgUnitManager route to the manager of the operators

workgroup and Organizational Unit.
ToWorkgroup routes to a random operator within a workgroup.
ToSkilledGroup also routes to an operator in a workgroup and takes required skills into account.
ToLeveledGroup is similar ToSkilledGroup, but instead of the system choosing an operator

randomly, operators are sorted by workload and desired skills.
We should not get confused by the naming of some of these routers. ToWorkgroup, ToSkilledGroup, and
ToLeveledGroup do NOT route to a group; they route to an operator, as is the case with all push routing.
These routers simply use the workgroup as a criterion for selecting the operator.
A couple of workbasket routers are worth noting. Workbasket routers are used with pull-based routing.
280
The ToWorkbasket router does exactly that; routes to a particular workbasket.
ToSkilledWorkbasket also routes to a particular workbasket. We will look at the details of this
router in later in this lesson.
281
Work Balanced and Skill Based Routing

To assist both push and pull routing, we can associate skills to operators and assignments.The skill rule
stores very little information; the description, as well as a range from Low to High, the high score
representing the highest level of proficiency with the skill.
Operators are associated with any number of these skills, and the appropriate rating is supplied. The
assignment is then associated with skills as well, depending on the type of router selected.
If the operator has a rating that is equal to or above the level required by the assignment, that operator
can be chosen by the router. Note that a skill can be set to be required, or not. If skill is not set, the skills
are fundamentally considered by the system as a nice-to-have, and are used in ranking the choice, but
not considered as an absolute requirement.
282
Lets look at a few out-of-box routers that incorporate skills into their algorithm.
For skill-based push routing, an operator is selected for a specified group and required skill. For the
ToSkilledGroup router, this selection is random.
For Pull-based routing, the ToSkilledWorkbasket router adds an assignment to a workbasket, and also
associates a skill with that assignment. Subsequently, GetNextWork will take these skills into account
when finding an assignment for an operator to work on.
Please do not be confused by the term ToSkilledWorkbasket. There is no such thing as a skilled
workbasket. This router merely sends an assignment to a workbasket and marks the assignment as
requiring a particular set of skills.
For the ToLeveledGroup router, the selection is prioritized by load and desired skills. A high load, in this
case, refers to when an operator has a high number of assignments that are past deadline.
Conclusions
As we saw, work can be pushed to either a worklist or workbasket assignments and workbasket
assignments can be pulled to create a worklist assignment. We can send the assignments to external
users and external users can process the assignment over the web by clicking the link in the email.
There are a variety of standard routers available to us and we can choose the appropriate one based on
our need. We saw how some of them relate to load and skill based routing.
283
Get Next Work

Introduction
PRPC allows us to either push tasks directly to workers or allow workers to pull a task from a workbasket
when they ready to perform a task.
In the first case, when pushing tasks to a workers worklist, the process flow can be configured to use
criteria such as worker availability, skills, region or others to assign a task to a specific worker. Typically,
this happens when the task is first created. This can be fully automated or manual.
Many business processes though can require that the tasks be stored in a centralized workbasket.
Workers can then select a task when they are ready to work on it. To avoid cherry-picking, PRPC
applications can select and provide the best, most appropriate tasks to workers. Every task is eventually
completed, but the order in which workers process those tasks may be an important factor. PRPC
provides an easily tuned set of capabilities that match workers to open tasks using the Get Next Work
functionality.
Routing to worklist or workbasket is covered in detail in the Routing lesson.
Explain the default Get Next Work functionality
284
Default Get Next Work Functionality

PRPC provides different ways to access the Get Next Work functionality. On the top left corner of the
case manager or case worker portal, the Next Assignment link provides a way to access the
GetNextWork functionality.
On the other hand the Get Most Urgent button may also appear at the bottom of the user forms on the
confirmation harness allowing users to access the next available task right after completing one.
When users click the Next Assignment link or the Get Most Urgent button, PRPC starts the standard
activity Work-.GetNextWork. This activity calls the final activity Work-.getNextWorkObject.
285
This final activity (Work-.getNextWorkObject) examines the property pyWorkBasketFirst. The

pyWorkBasketFirst property corresponds to Get from workbaskets first? checkbox in the Work tab of
the operator ID data instance, identified with number (1) below.
When Get from workbaskets first is checked, the activity Work-.findAssignmentinWorkbasket is called.
Otherwise, PRPC calls Work-findAssignmentinWorklist before examining the workbaskets.
The Work-.findAssignmentinWorkbasket uses a standard list view rule AssignWorkbasket.GetNextWork.ALL which returns a list of tasks sorted in decreasing order of urgency.
On the same operator ID rule form, the Work Settings tab has another check box, Merge workbaskets?,
which is identified with number (2) in the screen shot above. It indicates whether or not all tasks in all the
workbaskets listed should be combined for the operator in a single list before sorting them. If this check
box is not checked, the task assigned could come from the first workbasket, even though there could be a
task with a higher urgency in subsequent workbaskets listed in the work tab for this operator.
If the Merge workbaskets? checkbox is checked, PRPC displays another checkbox Use all workbasket
assignments in the users work group, which is identified with number (3) in the screen shot above. This
checkbox, when selected, indicates to PRPC to consider tasks only from workbaskets for which the work
group field (on the workbasket rule form) is the same as the work group field, (identified with number (4))
of this operator.
The next step is to filter the list to get to the most appropriate task. To do that, PRPC applies the decision
tree Assign-.GetNextWorkCriteria to each task in the sorted list.
286
This decision tree rule first checks to see if the task is ready to be worked on. This means that the
pyActionTime property of the task is NOT in the future.
If it is ready to be worked on, the decision tree checks if the current worker has already worked on or
updated the task earlier that day.
If the current worker did not work on the task, the Assign-.GetNextWorkCriteria now examines whether
the worker has the required skills to work on this task. The workers skills are recorded on the work tab of
the operator ID rule form. Note that skills are covered in detail in the Routing lesson of this course.
The search ends when PRPC finds the first surviving task (if any) that meets all the criteria.
The GetNextWork activity creates and populates the newAssignPage page and locks the case instance. If
the System Setting rule GetNextWork_MoveAssignmentToWorklist is set to true, the selected task is
moved to the operators worklist.
If no task is found in the workbasket related operations, PRPC repeats the process but uses the Work.findAssignmentinWorklist activity and the list view Assign-Worklist.GetNextWork.ALL.
Thus the default Get Next Work functionality can be summarized into these steps:
1. Users click either the Next Assignment link or the Get Most Urgent button.
2. The Work-.GetNextWork activity starts
287
3. The Work-.GetNextWorkObject activity starts

4. The pyWorkBasketFirst property is checked
Get from workbaskets first? Check box on Work tab of the Operator ID rule form
o If TRUE then it calls Work-.findAssignmentinWorkbasket activity first then examines the
worklist
o
If FALSE then it calls Work-.findAssignmentinWorklist activity first then examines the

workbasket
5. The Work-.findAssignmentinWorkbasket activity starts and uses the list view AssignWorkbasket.GetNextWork.ALL
The list of assignments are sorted in decreasing order by assignment urgency (property
Assign.pxUrgencyAssign)
o Merge Workbaskets? checkbox is NOT checked
workbaskets are searched in order defined on Work tab
Merge Workbaskets? checkbox is checked
use all workbasket assignments in users workgroup? is checked
list of assignments from all workbaskets with the same workgroup as this
user
use all workbasket assignments in users workgroup? is NOT checked
assignments from all listed workbaskets in the Work tab are assembled
into a single list
6. Assign-.GetNextWorkCriteria Decision Tree is used to filter the most appropriate task

7. First task that passes all the above requirements is selected
8. New newAssignPage is populated with this task and the case instance is locked
o Based on GetNextWork_MoveAssignmentToWorklist system setting rule
9. No assignment is found from the workbaskets
o Repeat steps 5 to 8 but with the Work-.findAssignmentinWorklist activity and the
standard list view Assign-Worklist.GetNextWork.All
(Note: The order in Step 9 is reversed if pyWorkBasketFirst property is false, as explained in step 4 the
worklist is processed first and then the workbaskets.)
Conclusion
The Next Assignment link and the Get Most Urgent button use the Get Next Work functionality. This
functionality can be customized for each operator using the settings in the Work tab of the operator ID
data instance. The next assignment to be worked on can come from a workbasket or first from a worklist.
All the workbaskets listed in the tab can be merged before pulling the next assignment. Either the
workbaskets listed in the tab are considered, or workbaskets belonging to the operators workgroup are
considered.
Your PRPC application selects and provides the best, most appropriate task to operators when they click
the Next Assignment link or the Get Most Urgent button.
288
Correspondence
Introduction
Correspondence refers to letters, email messages, Fax , and SMS text messages that PRPC applications
send to interested parties while a case instance is being processed. For example, we may want to notify
the case originator and others about its progress, request needed information or obtain a signature. The
interested parties may be PRPC operators or people who are external to the system.
In order to generate correspondence during flow processing we need to define who to send the
correspondence to and what to send. We must also select one of the standard correspondence types; ,
email, Fax, mail or phone text (SMS).,. A PRPC application can provide this information by prompting
users to specify values or can provide these values programmatically at the appropriate place in the flow.
In PRPC, correspondence is part of the Process category and is an instance of the Rule-Obj-Corr rule
type.
In this lesson, we will look at email correspondence, also known as email notifications.
Identify the major components of notifications
Create an email account for a sender
Explain how to create and configure correspondence
Add correspondence while processing case instances
Describe how to create ad-hoc notifications
289
Major Components of PRPC Notifications

In order to better understand the notification functionality in PRPC, lets take a quick step back and
identify the major components of email communication, even outside the PRPC world. This helps to frame
our discussion on PRPC notifications.
An Email is sent from a sender to one or more recipients, and uses a four-step model.
1. We need very little information for recipients, an email address, and perhaps the recipients
names.
2. The sender, in addition to needing an address and name, requires account information, and
perhaps a provider, server and port. If an email client program is used, these are typically set
once early on in the process.
3. The body of an email, contain the actual message that needs to be communicated to the
recipient.
4. In between the message and the recipient, lets add a delivery step. Gone are the times when
every email requires someone to click a send button. We still send these ad-hoc messages, but
our inboxes fill up with other emails as well, such as Task-triggered emails, like You were
recently sent a new credit card. Call to activate." We also get (friendly) reminder emails, like
Your credit card is now two weeks past due. Pay now or expect a large fee.
Lets look at the PRPC rules and data that fit into this four-step model.
1. The recipients of the emails are represented as PRPC work parties or the email ID itself as that
can be typed in certain configurations. If the recipient is internal to the system, the email address
is stored in the operator record.
2. The Sender information is stored in an Email Account rule. This rule holds account information,
and as with life outside PRPC, a single account is used to send multiple emails.
3. The message itself is created from a Correspondence rule, which dictates the actual content
and layout of the email body. Correspondence rules can also contain smaller, reusable
Correspondence Fragment rules and/or Paragraph rules.
4. On the delivery front, task-driven notification is setup from the PRPC representation of tasks:
Assignments. Assignments point to a special subset activities, called Notification Activities. Or
they can be set up with the Send Email smart shape after the assignment shape in the flow
rules. Reminders are set at the SLA level. That is, when the goal or deadline of a service level
agreement has been reached, a notification email is sent out. This is done using an Escalation
Actions. Ad-Hoc emails are typically sent using the out-of-the-box Send Correspondence
290
flow action, which can be configured as a local or flow wide or stage wide or case wide flow
action.
Creation of an Email Account

In order to send emails, we need to set up an email account. The easiest way to create an email account
is through the Email wizard, which can be accessed by selecting the DesignerStudio button > Integration
> Email > Email wizard.
In the wizard, change the drop down value to Configure an email account. Note that this account is
being shared for a workpool. Multiple cases, even multiple assignments for a case type, will share the
same email account record, therefore, we only need to do this once, for a workpool. When creating an
email account using the wizard, when you select a workpool name PRPC makes the Email Account rule
name the same as the workpool name, , and implicitly associates this account rule for the subsequent
notifications.
Use the form below to provide the account information. To help us get started, click the Select Email
Provider button to pre-populate the form with information from a well-known email provider.
291
Lets select Yahoo! Mail from this list.
We then fill out other critical information, such as the address, host, user ID, and password. Its possible
to use different account information for sending and receiving. For now, well use the same.
292
Correspondence Creation and Configuration

In PRPC, we can create a correspondence from any explorers, under the Process category.
In the correspondence rule form dialog, we need to specify what type of correspondence, by selecting
one of the standard correspondence types, Email, Fax, Mail and PhoneText. We also need to make sure
the Context (App Layer, Apply to class and ruleset name is accurate.
A correspondence rule is a template that contains the standard body of the message that we wish to
send. We can insert PRPC properties and include logic as well as text in this content. The
correspondence rule provides a Rich Text editor with a wide variety of formatting tools to change the
appearance of our correspondence. The toolbar includes selectors for bold, italics, fonts, font size, color,
spell checking, list formatting, alignment and including images and graphic elements.
PRPC properties are marked using angle << >> brackets and these are replaced with the actual values at
runtime before the correspondence is sent to the recipient.
293
We can also include larger fragments of text, including paragraphs, sections, other correspondence rules,
and correspondence fragments, by clicking the Include a Rule button, when we are editing the message
contents of a correspondence rule.
Correspondence Fragment rules are part of the Process category, and Paragraph and Section are part of
the User Interface category.
294
Add Correspondence to a Flow

Once the correspondence rule is created, we can configure the flows and assignments to utilize the rule,
to send the correspondence when the case instance is being processed.
We have covered the details of the Send Email smart shape in SAE I course. We can use the smart
shape in a flow rule to send the correspondence to any work party. The correspondence rule should be of
Email correspondence type in the correspondence template field.
Instead of the smart shape, we can also use a utility shape and call a correspondence activity. PRPC
includes several standard correspondence activities. The two main ones are CorrNew, which is typically
used when generating correspondence from a utility, and CorrQuickStart, which is a simpler
correspondence generation activity, with fewer options than CorrNew. The usage of CorrNew directly is
greatly reduced, as that is the one used behind the scenes for the Send Email smart shape with easier
configuration.
In a flow rule, instead of using the send email smart shape or utility shape with a call to a correspondence
activity, in the notify tab of the assignment we can configure it to send correspondence . Assignment
shape correspondence is generally used to send automatic notification messages to the users who have
the assignments, alerting them that more work has arrived in their worklist or acknowledging some other
party that the specific assignment has happened. For example, in an UnderWriteLoan flow of an
insurance application, an assignment can alert the loan officer that a new loan is ready for his or her
review. In the purchase request application, the Ship Purchase Items assignment can notify the
requestor that the items requested are about to be shipped.
295
Note that, since notification is now set up in the notification tab, a mail icon appears on the assignment
shape, similar to the Send Email smart shape. We can enter one of the activity rules Notify, NotifyAll,
NotifyAllAssignees, NotifyAssignee and NotifyParty in the Notify field, and enter the appropriate
parameters.
NotifyAssignee, sends a message to the assignee, or to the first contact in workbasket for
workbasket assignments.
NotifyAllAssignees is similar, but sends to all workbasket contacts.
NotifyParty sends a message to designated work parties
NotifyAll sends to all work parties
Notify is a template for creating customized notification activities.
Some of these rules can optionally check for urgency, and only send email when the urgency is equal to
or above this value.
If the service level is not met for an assignment, we can send the correspondence to the appropriate
recipients. Previously we learned that service Level rules are referenced in the Assignment tab of the
assignment shape in a flow.
In the service level rules, we can do one or more escalation action(s), if the goal or deadline is not met
and the deadline is passed. The list of possible actions is shown below.
Notify actions can be used to send correspondence. We can see what activities are called when using the
Notify Assignee and Notify Manager activities.
296
Whenever an email is sent automatically as part the processing the case instance, or manually (ad-hoc),
a copy of the email is attached to the case instances, and we can view them from the attachments section
in the perform harness.
Clicking the attachment link opens up the copy of the email with the contents and identifies who sent it.
297
Ad-hoc Notifications
Weve looked at use cases for automated emails; smart shape in a flow, on an assignment, and triggered
from an SLA. Now, lets look at ad-hoc messaging. Imagine a situation in which a manager wants to send
an initiator a question about the current purchase request. He doesnt want to approve the message until
he gets his answer. He could just email the requestor directly, but prefers doing it in PRPC for better
record keeping. The assignment is set with the local flow action SendCorrespondence. This could also
be set as a flow-wide or stage wide or case wide flow action.
At runtime, from other actions menu, we can click the Send Correspondence link and this enables us to
send ad-hoc notifications.
When we click on the link, the correspondence action is initiated and we see the work parties drop down.
Owner work party is configured as the operator who initiates the purchase request case.
Now, we select from a list of out-of-the-box correspondence template rules. We can select
SampleLetter, which allows us to edit the correspondence before sending it.
298
We can click the Next button to finish and the correspondence is sent back to the requester. Please note
that all emails sent from PRPC, are included as attachments in the case instances just as we have seen.
Conclusion
Correspondence can be in the form of email, mail, fax or SMS text. This lesson focused on email
correspondence, which is critical to timely and fluid execution of a business process. We looked at the
high level components of PRPC communication, and learned which PRPC rules are mapped to each of
these components, and how they can be configured.
Notification can be sent through a smart shape in a flow rule (utility shape in a flow rule which might not
be needed at all), notification configuration in an assignment shape, and SLA rule. Ad-hoc notification
can be enabled with a local action in an assignment shape. Notifications are sent to the work parties in all
the configurations and in some configuration, such as Send Email smart shape configuration, we can
also type in an e-mail directly.
Once the correspondence is sent, it is attached to the work item and is a permanent record that cannot be
deleted.
299
Tickets
Introduction
During the normal sequence of processing a case instance, an event may be considered a business
exception. When that event occurs, a ticket may redirect the processing to another point in the processing
of the case.
In PRPC, tickets are part of the Process category and are instances of the Rule-Obj-Ticket rule type.
We raise the ticket when the business exception happens, and we reference the ticket at a point where
we want the flow of the case to resume again. In this lesson, we will learn how to raise and reference
tickets.
Know when to use tickets
How to raise a ticket
Determine how to reference a ticket
Identify and use some standard tickets
300
Using Tickets
With the introduction of alternate stages in Pega 7, the use of tickets is diminished. An alternate stage is
meant for exception flows and processes that deviate from the happy-path primary flow. Lets look at one
example. During the processing of a purchase request, anyone can reject the request for any reason.
Whenever the request is rejected, we have a different starting point for the special processing of the
rejection. This can involve sending a notification to the requestor who requested for the purchase, return
the funds allocated for the purchase request etc. This special processing can be done with the use of
tickets or alternate stages. We recommend the use of alternate stages. Whenever rejected, we change
the stage to an alternate stage such as rejection, where we can have the steps to notify, return of funds
etc. Alternate stages are discussed in detail as part of the Case Lifecycle Management lesson group.
In another example, we want to hold the purchase request case from processing further until all the
subcase instances of purchase orders are resolved. This can be done either with the use of tickets or by
using the advanced Wait shape, with Case Dependency being the wait type. We recommend using the
Wait shape. The Wait shape is covered in a different lesson.
But, we still might have instances where using a ticket is the easiest or only way to satisfy a requirement.
For example, when a purchased item is delivered to the requestor, they can confirm delivery or they can
return the purchase if the item is defective or did not meet their expectations. So, in the purchase order
subcase, a ticket is raised whenever the purchased item is returned. It is referenced in the purchase
request parent case to restart the purchase request process.
A ticket rule only defines a name and description and not the processing to occur in the case of an
exception.
301
Raising a Ticket
In the flows for a case, we define when an event may be considered a business exception by raising a
ticket.
PRPC provides us with two distinct ways to raise a ticket. One way is to provide users the option of
selecting the Work-.SetTicket or @baseclass.SetTicket flow actions when processing an assignment. If
an assignment is presenting a case instance with a condition that meets the business exception criteria,
users can select this flow action to trigger the exception processing. As shown below, users have to
select a ticket from the dropdown, to set the ticket flow action during the processing of the case. We use
an HTML rule, ActionSetTicket to display a list of Tickets. These standard flow actions require users to
have the ActionSetTicket privilege.
The second way to raise a ticket is by calling the standard activity @baseclass.SetTicket. This activity
takes the ticket name as a parameter and turns it on or off. Instead of using the standard SetTicket flow
action, in the flow action where the business exception is occurring we use the standard activity to raise
the ticket. In the return to purchase business exception flow action, we raise the ToPurchasing ticket
that we created earlier, by passing the name of the ticket as the parameter to the activity.
The SetTicket activity takes the ticket name as parameter and turns it on or off.
302
Referencing a Ticket
In the flows for a case, we also need to define the starting point of the processing that needs to occur
once a ticket is raised. We do this by referencing the ticket.
Once a ticket is raised, flow processing stops and resumes at the point in the flow where the ticket is
referenced.
In the process modeler, specific shapes have the ticket functionality built into the Properties panel.
Use the Tickets tab of the Properties panel on the shape we want the processing to resume from when
the ticket is raised.
The following shapes provide a Tickets tab in their properties panel:
Assignment
Decision
Subprocess
Utility
End
Split For Each
Split Join
Integrator
Assignment Service
Most of the smart shapes
The shape has a ticket indicator with the description next to it as shown below.
303
We can use the Ticket landing page available by selecting the Pega button >Process and Rules > Work
Management >, Tickets in our current application to verify which ticket rules are in active use, and by
which flows or activities.
304
Key Standard Tickets

Several standard tickets are available in PRPC. Among those, there are few common ones. The
advantage of using these tickets is that we dont need to raise them. We just need to reference them
where the flow has to resume.
Work-.StatusResolved is automatically raised by the system when a work item is resolved. We

can then reference it in our flows to indicate the starting point of the processing we would like to
occur when our work item is resolved.
Work-.Withdraw is similar but is raised when the work item is withdrawn. If this needs to be
handled in a special way in our flow, we can reference it to indicate the starting point of the
special processing.
The Work-Cover-.AllCoveredResolved ticket is raised by PRPC when all covered work items
are resolved. The ticket alerts the covered work item and any needed special processing
referenced by this ticket is triggered. The parent Purchase Request case is waiting in a
workbasket and when all the subcases are resolved, the ticket is raised. It is referenced here in
the Update Status utility shape to resolve the status of the parent case automatically.
The Data-Party.ApprovalDecisionMade ticket is quite common to use when processing needs

to occur as soon as enough parties have reached a decision either approved or rejected.
Conclusion
Tickets are a powerful feature that helps to handle business exceptions easily and efficiently when
alternate stages or Wait shape and dependencies cannot be used. Turning tickets on and off is simple.
They are also a great tool to build flexibility into our applications.
The Ticket rule itself is just a name and description. We raise the ticket where the business exception is
happening and we reference the ticket where we want the flow of a case instance to resume.
There are some standard tickets available for us to reference in our flows and they are automatically
raised by PRPC.
305
Declarative Processing
Introduction
Traditional programming models involve procedural execution of logic, in the case of a BPM application
these are tied to the business process. In certain scenarios this programming model poses significant
challenges especially when it comes to adapting to change quickly. Declarative programming specifies
what computation should be performed without explicitly mentioning when to compute it.
Lets look at an example - a customer is entering a questionnaire during the enrollment process that is
used to determine the quote for his insurance plan. There are several factors to consider here, the
insurance calculation depends on a variety of factors, the execution of the calculation should not dictate
the order in which the questions are answered and lastly the model should be flexible enough to handle
new or changing factors. PRPC offers a powerful declarative engine that can compute declarative
calculations. These declaratives work in tandem with the business process and do not require any explicit
reference in the business process for these rules to be invoked.
Explain the benefits of declarative processing
Differentiate between forward and backward chaining
Identify the performance impacts
306
Benefits of Declarative Processing

Declarative rules are not invoked from other rules. This eliminates the dependency on different rules
making the creation and deletion of rules independent of each other. For example, management decided
to eliminate the discount offered to all employees. If we used a procedural rule like a data transform to
calculate the discount and if management decides not to offer discounts anymore, to effect this change
we delete the data transform and change other rules that invoke the data transform. If its written as a
declare expression, we just need to delete the expression.
Keeping the rules independent makes it easy for us to separate business rules from the process. This
gives us the option to delegate these rules to business managers. A declare expression can invoke a
decision table and the managers can modify decision tables directly in production.
Declarative rules offer speedier development because developers only need to configure the rules and
not decide on where to put the rule. Not having developers configure how these rules are invoked offers
multiple benefits. Development time is shorter because the code is less prone to errors since the
declarative engine handles the processing of the rules. Maintenance is easier since newer teams do not
need to dig through to locatethese rules and the rules are easier to configure than activities. We can use
the Declarative Network landing page to access the declaratives defined in that application.
Declarative rules support all those features that apply to other rules such as class specialization, ruleset
and rule specialization, circumstancing and or effective date.
When developing PRPC applications, we may have some situations where we need to decide whether a
rule can be written as a declarative or as a procedural rule. In most cases, the answer to that question is
to write the rule as a declarative rule. For example, the unit total for a selected line item is the product of
the price of the line items and the quantity (UnitTotal = LineItemPrice* LineItemQuantity). This logic can
either be written using a data transform or a declare expression. In this case this should be written using
the declare expression so its easier to maintain and modify.
Another benefit of declarative processing is Performance. Well written declarative rules offer better
application performance than using a procedural rule. When working on a purchase request application,
the customer can order any number of items. Declarative calculation of line item totals can automatically
trigger the calculation of the grand total for the purchase request. Declarative rules allow us to use
chaining to any number of levels which creates a declarative network.
307
308
Differentiating Between Forward Chaining and Backward Chaining

Since Declarative rules are not referenced explicitly PRPC must determine when to execute them. Most
declarative rules use one of two modes - Forward or Backward Chaining. All declarative rules use source
and target properties.
The target property is what is being calculated or computed using these declaratives and
Source properties (in some cases there is more than one property) are the ones which are used
as an input.
Forward Chaining
Forward chaining is executed when the value of any of the source properties change. Most of the
declarative rules follow forward chaining.
In the case of Declare expressions, the expression is calculated whenever any of the source properties
change. In our example, the subtotal gets calculated whenever the quantity or the unit price changes.
Declare Expressions are configured in Forward Chaining Mode when we select the option Whenever
inputs change.
In the case of Constraints, when the value changes, the constraint is executed to verify that the value
conforms to the conditions expressed. Constraints can have any number of rows and the order in which
they are listed is not significant. The message text can be entered directly in the rule form or saved as a
message rule which can be referenced as shown below.
309
Declare OnChange can track several properties that have been saved as part of the case. When one or
more of these properties change it invokes the activity which has the logic to be performed. The
Declarative Engine invokes the activity only once if more than one property gets changed.
The Declare Trigger executes when instances of its classes are created, saved or deleted in the
database. On the database event, it triggers an activity which contains the logic to be performed. Triggers
can be used in cases when we want to capture the history of how a property got different values over the
case lifecycle. For example, the audit trail must contain information about the different values stored as
part of discount. Whenever the values in the discount change, it causes the trigger to fire the standard
activity which writes an entry to the audit trail.
310
The Declare Index executes when the values of a page list or a page group change which requires the
system to update the records saved in the indexed table (corresponding to the indexed class). This is
primarily used in reporting when we expose page list properties to improve performance. Whenever a
new page list gets created or deleted or when one or more of the values change the Declare Index
automatically create or update the records stored in the index table.
311
Backward Chaining
Backward Chaining mode executes when the target property is referenced. Backward chaining is
supported only for declare expressions.
Declare expressions provide three options for Backward chaining.
1. When used, if no value is present
2. When used, if property is missing
3. Whenever used
The target property is considered used when its referenced by its name, such as in a UI rule, in a
decision tree or in a data transform.
The if no value present / if property is missing options make sure the expression is calculated only
once in the case lifecycle unless the property is removed from clipboard.
When we use Whenever used the system throws a performance warning, indicating that the expression
will fire as many times as the target property is referenced.
Calling Declare Expressions Procedurally

The remaining two options When applied by a rule collection and When invoked procedurally
allow a declare expressions rule to be used in a procedural manner, by a collection rule. These two
options behave similarly, except that chaining in to or out of the expression is not supported by the When
invoked procedurally option.
Both options allow the declare expression to refer to itself, such as in the expression .Property = .Property
+1. With either forward chaining or backward chaining, this type of expression results in a never-ending
recursive calculation.
Collection rules are an advanced topic, and not covered in this course. As a result, the remainder of this
lesson focuses only on forward and backward chaining
312
What are the Performance Impacts of Declarative Processing

Using declarative rules can significantly improve the overall performance of an application, since the
declarative engine controls the execution and it is always better than a procedural rule such as an activity
or a data transform. There are some key points to consider though when designing declaratives.
The decision to use Forward or Backward chaining of declarative expressions is dependent on the
application requirements especially in terms of how the target and source properties are referenced.
Choosing them incorrectly severely impacts performance.
Forward chaining becomes more performance intensive if the expression uses lot of factors and they
change quite frequently. For example, lets say we are calculating the insurance quote based on fifty
different factors, and these fifty different factors are collected in various screens. When we use forward
chaining, the declare expression gets executed fifty times when the user changes these factors and if the
user changes the same factor more than once it recalculates every single time it changes. If we are only
going to display the insurance quote after we collect all the factors then forward chaining is not a good
choice because the quote gets calculated 50 times instead of 1 time. But if we have used backward
chaining (one of the When If used choices) the quote would only get executed once.
However in the same example, if the application should reflect the quote in each of these screens and it
should reflect the change so users see how their selection impacts the quote then we have no option
other than using Forward chaining.
Similarly, when we are displaying a shopping cart where users add items to it and the cart should reflect
the total based on the changes immediately, forward chaining is the perfect choice. By default, a declare
expression uses Forward chaining. So developers should think about the places where the source is
referenced and how the target property is referenced to make sure we optimize the execution mode.
When using Backward chaining we need to determine the execution depending on how the target
property is referenced. Going back to the same example, we determined the Insurance Quote and this
application requires approval from various people, so if we use backward chaining to fire (Whenever
used), the declare expression gets fired every time the application looks for information to display the
insurance quote. The system throws a performance warning when the option of Whenever Used is
selected. This does not mean we should not select that option. Though we can optimize the number of
times the declare expression is calculated, we need to make sure that the value is accurate. So we
cannot select When Used if no value or When Used if not present if we know the source properties can
change.
Lets look at another example, if we are looking at a purchase request application where users tend to
order more than 30 items. So in this case if we have a declare expression for total price written as
Whenever inputs change it gets calculated 30 times. However if we configure the expression for the total
price to use Whenever used the total price is calculated only once when we are displaying it. And if we
are displaying the total price in 5 different screens then the expression is calculated five times. If we use
When Used, if no value present then it calculates only once, however if the user goes back and changes
the request to add or delete line items, the order total does not reflect the change.
Using the Tracer helps us to identify places where we can optimize the declarative calculations as well as
making sure the expressions are always displaying the correct values.
Finally, its important to remember that declarative evaluation can cause severe application errors that
would not otherwise occur with procedural evaluation. When configured incorrectly, a declarative rule may
cause the system to access pages that have not been created or properties that have not been set,
leading to unpredictable results. With a procedural alternative, we can better control rule evaluation. So, if
we need to perform a calculation at a specific point in a process, a procedural approach may prove less
error-prone than a declarative approach.
313
Conclusion
In this lesson we learned about declarative processing, and how it provides an alternative to traditional,
declarative processing. The use of declarative rules can reduce errors and maintenance effort, simplify
development, and improve performance if used properly.
We also learned about forward chaining and backward chaining, how PRPC controls the execution mode
of the declarative calculations using these modes. We will learn more about writing declarative
expressions in another lesson. The Lead System Architect (LSA) course provides more detail on the
advanced rules such as Triggers and OnChange.
314
Declarative Rules
Introduction
Business calculations involving user defined fields should all be implemented using declaratives. Some
calculations use simple mathematical operations like add, subtract, multiply or divide, while there are
some advanced operations which might involve creating a java function.
Business calculations may span multiple layers that together form a deep network. For example, the total
price of an order is calculated as the sum of the subtotals. The subtotal is calculated as the sum of all line
item totals and then deduct the discounts. The line item total is calculated as quantity * unit price.
Discounts may involve other calculations depending on the customer type, geography, time when order is
placed, and so on.
Declare expressions provide a great way for us to implement this functionality. We could use activities or
data transforms to do the same, however using expressions offers greater benefits. Lets look at
Declarative expressions now to learn more.
Design a declare expression to compute calculations
Identify and use Utility functions
Appropriately choose between context-free and context-sensitive expressions
Unit test a declare expression
Explore the declarative network analysis and use declare inspectors
315
Design Declare Expressions

A declare expression can be created by right clicking on the property in the App Explorer and clicking
Define Expression.
In the new rule form, we need to identify the Target Property.
If the target property is of page list or page group then we need to identify the Page Context.
Declare expressions have a number of prebuilt calculation types. This list is different for each type of
target property. In this case UnitPrice is a decimal and you're presented with the list of calculation types
used for decimals. To set a scalar value we use Value Of and then select the free form expression which
allows us to write any expression. There are three other choices that apply to decimals.
316
If the property is an integer it brings up other functions
Other calculation types for decimal and integers include: sum of, min/max of, average of, count of and the
two index calculations. Each of these loops over a list and performs their respective calculation.
The result of the decision tree, table and map value allows us to call other business rules and take
their return value and set the target property.
The Value of first matching property in parent pages option allows declare expressions to reflect
a value for a property of the same name on a parent page. The class of the target page must equal
or be a descendent of the class of the declare expressions rule.
Lets take a look at the examples of declare expressions that can be used to calculate these values. The
subtotal or line item total is calculated as
317
while the total price is calculated as the sum of all line item totals.
When the target property is string, the functions available vary and the selections are only Value Of and
Results of Decision rules. We can also apply a condition to evaluate which expression to pick.
Similarly a date property comes up with different list that applies to date functions. We can also apply a
condition in the In Which field, that applies a condition for each item in a page list or a page group.
318
Identify and Use Utility Functions

Some complex declare expressions require using a Function rule. The definition is easier by opening the
expression builder to pick the function from the list of available libraries.
A function is a rule type in Pega that is used in various other rules. Functions allow us to extend PRPC
capabilities by using custom java code. Functions belong to Technical Category (Rule-Utility-Function)
and are grouped by Library.
The Library rule is primarily used only for grouping related functions. PRPC ships various libraries each of
them containing a list of functions for us to use as-is. The expression builder allows us to select the library
which in turn provides the list of functions that are available in that category. In most cases we should be
able to use these functions as such and we may need to write new ones on rare situations.
In the expression builder, first we need to select the library, if we are not sure which one it might belong to
we can select All.
319
When a function is selected, it opens up the parameters panel. Functions require one or more parameters
to be passed as inputs. After adding the parameters, we click Insert to add the function. The expression
builder provides functionality to validate if the function is valid.
Functions are also used in other rule forms like when, decision trees, etc. We will learn more about these
in other lessons.
320
Context-free and Context Sensitive Expressions

Declare Expressions can be configured to execute either using forward or backward chaining modes. The
lesson on Declarative processing provides more information on this topic.
The other important concept we need to learn in declare expressions is the Context Execution behavior.
There are two general types of context settings, Context Sensitive, which is set by selecting the first
choice and context free, which is set by choosing the regardless of any pages it is contained in option.
The third option is a hybrid where we can explicitly list the classes for which it will behave like a context
free expression. In practice this option has limited appeal as maintaining such a list reduces reusability.
The context sensitive option is the default for expressions. The term context sensitive really means that
the path defined by the page context + target property must be complete from the top level page that
derives from the Applies to class.
In the examples we saw earlier TotalPrice which uses the sum of all lineitemtotals fires only when the
applies to class is the work class in which it belongs (in this case its ADV-Purchasing-WorkPurchaseRequest).
The LineItemTotal or the subtotal calculation that we saw earlier is used to calculate the totals of each
line item. This expression also uses the context sensitive expression. The only difference being the
expression uses .LineItems() as the page context property so the expression is fired based on the page
list property LineItems that is defined in the work class.
321
Context free expressions allow us to define the expression without taking into account where it is used in
the expression. This option is best used for calculations that are ALWAYS necessary and the same,
regardless of where the object is embedded.
In our base application we implemented the unit price using a context free expression. In this rule, we
copy the unit price from a page property named SelectedProduct. The page property SelectedProduct is
auto populated by a data page so this unit price is copied from data page irrespective of where the line
item is added.
Instead of defining the applies to class at the work object and supplying the page context we define the
expression directly on the data class and set it to context-free.
322
Declarative Network Analysis

For many applications the complexity of the calculations can be quite significant, with potentially hundreds
of nested calculations. Luckily PRPC provides tools for viewing the expressions directly.
The first tool is the declarative network landing page. We can get to the landing page by going to the
Pega button, clicking Process & Rules > Business Rules > Declarative Network.
The landing page shows us the top most expressions. The expressions that are used by these top
expressions are not shown here. Think of this as showing us the final results and not the intermediate
calculations. We can open our Total Price expression to test further by clicking the highlighted icon.
Here we can see that the total price uses subtotal which is an expression and which uses quantity and
unit price. Unit Price is an expression using another unit price.
For complex networks we can zoom out (or in) to see different components of the network. PRPC also
provides alternative views of the network. Here we can see the basic tree view as well as the org tree
view.
Another useful feature for more complex networks is the ability to expand the network one level at a time.
Here we can see that, starting at level one and expanding one level at a time, we can clearly see the
properties that factor in to each calculation.
323
Unit Test Expressions

We can unit test expressions in couple of ways.
In the declarative network on a specific property we can click By clicking the run button to see the test
expression screen.
As we can see all the dependent properties needed to determine the total have been identified. Each
property is editable so we can test directly from here.
To enter a value, we need to click on the property that does not have fx to its left, the ones with fx are
calculated by the expression. We then enter the value in the text box and click update.
Now if we update our Unit Price to 10 the discount expression fires and automatically updates the Unit
Price. Since we have already defined a value for Quantity the subtotal and Total price are also
calculated.
For properties that are lists, such as our LineItemList, we can also add additional pages directly from this
screen. The expression testing tool has a number of other features which can be very helpful when
reviewing the calculations with other developers or the members of the business team. This form can also
be accessed directly from the declare expression rule using the actions menu and clicking Run.
324
Conclusion
Declare expressions are most popular amongst all declarative rules and we learned about defining them.
Declare expressions are useful in cases when we want to calculate the total price on a purchase request,
or derive the quote for an insurance policy. Some applications require us to perform complex business
calculations which require us to use function rules. Remember that function rules are grouped using
libraries.
We also looked at examples of how to write context free and context sensitive declare expressions.
Finally we learned about the declarative network analysis tool to explore the nested levels of declarative
rule and how we can unit test a declare expression to make sure it works.
325
Delegating Rules to the Business User

Introduction
Enterprise applications require us to design the application so its flexible and supports modifying the
business logic in real-time. Pega offers us the ability to delegate the rules to business users who can
change the logic directly in a production system without going through the longer development cycle.
Lets look at couple of simple examples that show how a business user can make changes directly in a
production system.
1. When the employee completes a purchase request, the request is sent to their manager if the
order total is more than 500 dollars. This led to employees tampering with the system by entering
requests less than the order total so that they can get their request auto-approved. Managers
wanted to periodically change the amount so that employees were not aware of the limit and their
requests would get assigned to their managers depending on the new limit.
2. Consider the company is now selling a new product line so we need to update the discount table
to include the new product line.
Illustrate the benefits and consequences of rule delegation
Select appropriate rules to delegate
Improve readability of decision trees using function aliases
Reduce user errors by controlling what changes can be made
326
Delegation of Rules
One of the key benefits of PRPC applications is that they are very adaptive to change. A well designed
PRPC application should involve business users not just to capture requirements in the product but also
provide them with the option to change the rules in real-time.
Some of the changes are related to data, for example the list of products that a user can order or a list of
accounts owned by the customer or the list of transactions made by the customer. This data comes from
either internal or external sources and is usually updated outside of the application. Pega 7 helps us in
designing our application to separate data from the business logic so that changes in data can be
handled easily without impacting the application.
In this lesson, we will look at some changes that impact case processing logic.
1. The bank decides that it wants to automatically approve a credit card dispute if it is less than 30
dollars and if the customer has had the card for more than 2 years.
2. When fulfilling the order, the invoice amount should apply the tax rate based on the state in which
the customer lives.
In the first scenario, if the bank decides to increase the auto approval amount for the credit card dispute
from 30 to 40 dollars or reduce it to 25 dollars or even add another factor such as customer type so that
the amount can be based on the customer type. By delegating these rules, these types of changes can
be made by the user without the need for a developer to be involved.
Suggested steps
1. Identify the group of delegated users These users must be part of a specific access group and
the rules should be in a specific production ruleset that these users can access. These users
should also be able to access the delegated rules from their portal.
2. Identify the Rules that can be delegated Typically any of the Decisioning rules can be delegated.
This makes it easier to make changes and PRPC supports additional configuration to Decisioning
rules which makes it easier for us to update them.
3. Improve readability and customization options to make it easier for users to make their updates.
Lets take a detailed look on how to implement these steps.
327
Setup of Delegation Users

The first step in delegation is to create a new ruleset for end users to make changes. The ruleset should
use the application ruleset as its prerequisites. The ruleset should remain unlocked in production so that
the users can make changes.
If the rules are delegated to more than one user, then we should enable the checkout option so the
changes are not overwritten.
The ruleset should then be added as a production ruleset in the application rule.
The Accessgroup of users should also be modified to include the production ruleset.
Lastly, the operator IDs should be configured to allow checkout of rules.
328
329
Delegated Rules to the Business

Decisioning rules are good candidates for being delegated to business users. These rules frequently
change and are easier for business users to make changes. After a rule is identified we need to save a
copy of the rule in the delegation ruleset.
After the rule is saved, we delegate the rules by using the actions menu to add it to favorites.
This gives us the choice to whether add it as a favorite for a specific user or an access group. The last
two choices appear only after we add the rule to a production ruleset.
Once added, the delegated rules appear as part of the user portal for users to access.
1. For users using designer studio, these rules can be seen in the Favorites Explorer.
2. For users using case manager portal, these rules are accessible in the operator menu.
330
Improving Readability
Decision trees usually look complex with multiple if-then-else statements, but we can make these more
user friendly in several ways. We recommend you follow these guidelines when delegating rules to
business users so its easier for them to configure.
1. Display Label The display label button displays the short descriptions saved in the property
instead of using the property name, so meaningful short descriptions make the decision tree more
readable. Shown below is how the decision tree originally looks., Note it uses the property
identifier (.propertyname or Page.PropertyName) which makes it harder to read.
When we click the Display Label button then the same now looks like the screen shot below.
2. Function Alias Using a function alias adds more meaning to the condition rather than using
the actual function signature. A function signature looks like this:
@(Pega-RULES:DateTime).isWithinDaysOfNow({theDate}, {days}).
We can modify that by using a function alias rule and the tree now looks like this.
331
Function Alias Rules

These rules are part of technical category and they reference a function. So we either need to create a
function and then create an alias or we can create an alias for an existing function.
The key factors involved is to identify how the parameters for the function get values (they can be
assigned to a property value like theDate or can provide an option for users to select when the alias is
selected).
In this case the function requires two parameters the date and the number of days from that date. We
set the first parameter to case creation date, so this alias is used only on cases where we would like to
select x number of days from the case creation date.
A function alias helps in making the decision trees very readable to simulate reading an If then else
condition logic.
332
Customize Options to Reduce Errors

When delegating rules to business users we recommend that you restrict the choices from which users
can select. As shown below, users can select one of three choices in the CustomerType field.
This can be enabled both in trees and tables, and the choices can be added in one of two ways.
We can add these directly in the Allowed Results table. Or, the results can be stored as part of a property
and then we can refer the property in the Allowed Values Property.
We can also set another property when the results are chosen. These property sets are hidden to users,
and we can set one or more properties for each result.
Decision Trees
The options field must be carefully selected on rules that are extended to business users. In most cases
the ability to change functions, call decision or take actions should be disabled. If there is a case where
we need to let users change functions, we should add the list of functions in the Functions Allowed field.
Then users can select from that list and not the entire list.
Similarly if users need to take actions, then we use the Allowed Action Functions field to add the
properties that we need to add.
Decision Tables
The Allowed results in Decision tables works similarly to how it does in decision trees, except in the
Decision table rule form the options are listed as Delegation Options. Only the highlighted flags impact
how users can make the changes on delegated rules.
333
1. Allow to update row layout When this field is disabled, then business users can only modify
the values corresponding to that row. They can neither add new rows nor delete any existing
row.
2. Allow to update column layout: When this field is disabled, then business users can only
change the values corresponding to that column. They cannot add or delete columns in the table.
In addition, they cannot change the property that is referenced in the columns.
3. Allowed to build expressions : This field enables the end user to use expressions as part of
the cell in the decision table. If disabled, then users can enter either a constant or a property in
the cell.
Map Values
Map Values offer two options for delegated users they can change the matrix layout or use expressions
in the cell.
Conclusion
Applications require rules to be delegated to business users so that they can make updates to business
logic without requiring a developer to make change. Though we all know the benefits, delegation comes
with some challenges. To make it easier for business users, the development team should configure the
delegation options so the choices that the business users have to make are restricted.
334
Automating Decisioning
Introduction
Applications become powerful when we automate its decision making capabilities. Decisioning can be
applied on the action paths taken by the case or to assign a specific value based on a set of specific
conditions. Lets look at couple of examples:
1. A customer calls in to dispute a transaction that appears on his statement. The company would
like to automatically approve all disputes that are smaller than a specific amount since it is not
cost effective for the company to process the dispute as a claim. In some cases, we may need to
include other factors like the number of such claims filed by the customer in the past year to make
the decision.
2. When completing a purchase request the system determines the discount for which this requestor
qualifies. The discount is determined using a set of specific conditions such as the department,
customer type (platinum, gold, silver), time period in which the order is made and so on.
Pega provides decision rules that can be used to implement these conditions to automate the process. In
many cases these rules are delegated to business users so they have the ability to change the small
currency amount or the factors that are used to determine the discount factor.
Decide which decision rule to choose based on the requirement
Configure and use a decision tree
Configure and use a decision table
Check for consistency and Unit test the rules to check results
335
Decision Rules
Decision rules play a key role in any enterprise application that involves business processes. They
represent the decisions and policies that drive business processes and case management.
Decision rules can be invoked using a decision shape in the flow, using a declare expression or using a
method in an activity step. The referencing of the decision rule depends on the context in which we need
them.
We use flows in case processing to determine which path the case goes down. Using decision rules in
our flows automates the case processing. For example, a decision table can decide if the case requires
approval from another manager or if it can move to the next step in the business process.
Declare expressions can use decision trees or decision tables to get a specific value based on a set of
conditions. For example, if the customer lives in Massachusetts, has a credit score above 720, and is
paying at least 20% as a down payment, then the APR for the car loan is 1.7%.
Decision trees are used in activities when we want the activity to decide whom to route the case to or
what the escalation activity on the SLA should perform.
There are four types of decision rules that we can write to evaluate decisions:
When
Decision trees
Decision tables
Map Value
When Rules
When rules belong to decision category, however they can return only one of two values True or False.
When rules are used in processes to decide which one of the two paths the case can take. For example,
if the purchase request total is less than 500 dollars then the purchase request does not require approval.
When rules are also used in other rules like UI, data transforms, other decisioning rules and declare
expressions to evaluate a condition. Though most of these rules support adding the condition directly, we
recommend that you use a when rule so the condition is entered once in the when rule and is used
everywhere.
When rules can use a Boolean expression or a function rule part of the library shipped in the product or a
custom function defined as part of the application. When rules can involve any number of conditions and
can be combined using AND, OR & NOT.
336
337
Decision Trees
Decision Trees are useful when applying the If- Then- Else construct. Decision trees can be constructed
to have many branches which evaluate different properties to determine a decision. Decision trees can
also use function rules or when rules for building the condition.
One of the main reasons to use Decision trees is that it allows nesting, which means it can invoke another
decision tree or other decision rules such as a decision table or a map value.
Decision Tables
Decision Tables are useful in presenting the set of conditions using a tabular structure. This is very user
friendly to for managers since it resembles a spreadsheet with rows and columns. Decision Tables are
suited to cases where we use a set of properties to arrive at a decision.
Some of the main reasons we use Decision Tables are that they:
1. Give us the option to evaluate all rows to arrive at a decision.
2. Let us increment values on the specified condition which is useful in implementing scoring.
3. Can invoke another decision table
4. Decision Table
338
339
Map Values
Map Value rules let us determine a specific value based on one to two properties- think of this as in a
map determining the location based on the latitude and longitude.
Map Values are usually used in special circumstances where we the values of one to two factors decide
the outcome. For example, if we want to determine the interest rates for bank accounts and customer
types.
If we have five different types of customers and eight different types of accounts, we need forty rows in
decision table to present this while we can do this in a 5x8 matrix. Map values can be chained to other
map values as well if we need to use more than two properties to determine the outcome.
Map Value
340
Decision Trees
The decision tree can use the direct expression such as .pyStatusWork = Resolved-Completed or
reference a when rule named StatusIsResolved or use a function rule.
Decision trees usually return a value, these values can then be used in the calling rule such as the
declare expression or the flow.
The decision tree can also be configured to set a value to properties and this can be done using the Take
Action option in the menu. Continue is used to check additional conditions and otherwise is always used
as an else condition.
Decision trees can also be configured to check values on a specific property and decide its course of
action. Evaluate is used in such scenarios.
A new tab Input appears when the Evaluate option is selected to enter the actual property that is
evaluated.
341
Though the decision tab is where we configure the decision, the developers need to use the entries in the
Results tab to control how decision trees can be used.
The Options area has two options basic (by default) and advanced. Selecting Advanced enables all the
checkboxes in the options area. Besides the options we can use the Functions Allowed section
determines what function rules are allowed for the selection. Similarly we can configure what options are
available for Take Actions in the Allowed Action Functions area.
The decision tree can also have restricted return values, in this case the decision tree can return either
true or false. We can also enter a property in the Allowed values property, in that case it uses the values
saved as part of local list in property definition. The decision trees must be configured to have all these
selections if they are delegated to business users. This helps our users to select the results that are
allowed, use the functions that are required and only take the appropriate actions.
342
Decision Tables
Decision tables are easier to delegate to business users and in most cases is the sought out decision rule
if the same logic can be written using either a tree or a table. This resembles tools like MS Excel and
hence most developers also feel more comfortable using them.. Decision tables are more apt to be used
if we are using a smaller number of unique properties to evaluate the decisions. Since we use tables,
each property gets a column and it makes sense to have rows added in a way that each of these columns
have values.
The table columns can use properties for specifying a set of conditions. The property can be compared
against a single value like Customer Type = Retail or against a range like Total price is greater than or
equal to 300 and less than or equal to 1000.
Decision trees also offer additional capabilities to add OR conditions. Suppose we want to introduce a
new column for Supplier and for two of the three customer types the values in other columns do not
change. We could use OR to split a cell instead of adding a new cell. In the example below we have a
single cell using OR for suppliers (Named vendor, New Vendor) for the first two rows.
We can return values or enable the property set field to set properties directly, using other icons we could
return more than a single property based on the condition.
The results tab provides a similar set of options that we saw in decision trees we can restrict the results
returned using a property or a set of values. The main difference between the tree and table is the first
option (Evaluate all rows), if this is selected, the decision table continues evaluating other conditions even
if one condition is satisfied. This behavior is not enabled by default and is used only on specific cases.
We will review one such case later in this lesson. When this setting is enabled, the decision table cannot
return values and hence we cannot execute the decision rule from a declare expression.
The delegation options apply only for the delegated user. Refer to Pega 7 Help for the details of each of
these options.
343
344
Implement a Scoring Rule

A scoring pattern is quite common when determining risk or discounts. The total score is usually the sum
of a number of intermediate scores each looking at a specific factor. In our case, our total risk for each
line item is the sum of the total amount risk score, plus a risk score for risky suppliers, plus a risk score for
beer products. The second part of our requirement is to track which factors were in play for the
calculation.
Here is a sample screen shot of the result. We can see that the first item had both the beer risk and the
high price risk factors, and each item had different factors that contributed to the scores. Lets build the
rule that can represent this business logic.
Start by creating a decision table on our line item class. Since we want to have the decision table
evaluate all possible factors and not just the first one that matches, we enable Evaluate All Rows on the
Results tab. Notice, the IF has become a WhenNext we will add rows for the 3 factors. And complete
the header columns for our 3 factors.
Now, for our Action column we dont want to set a specific property, but want to increment a score. We
can use the plus-equals operator on our risk score property.Now we can fill in our business logic. For
each row that matches, the risk score will be incremented by the amount in the row. Now we can move on
to the second part of the requirement the rule auditing. We create a second column to store the text for
each matched factor. We will utilize an already created page list called Risk Factors to store our list of
applicable factors.
The key to this is to use the <APPEND> directive to add a new page to the page list for each row that has
evaluated to true. Next we can add the values that we want to store. Now we have a completed rule that
when fired evaluates all the rows, increments the score property and adds a page with the description for
each matched row. With some minor UI adjustments we can display the score and the list of factors.In
implementing this pattern there are a few design considerations to be aware of. First, we chose to use a
page list instead of a value list, as the page list provides more flexibility should we want to add additional
metadata as requirements change.
Also, in many cases the complexity of the logic may require more than a single decision table. A common
pattern in those situations is to separate the logic into multiple tables each using the pattern we just
discussed. The group of trees can then be executed as part of a rule collection. We will discuss
collections in a future lesson.
345
Checking Consistency and Unit Test Rules

Some rules become increasingly complex especially trees and before we release our rules we need to
verify that they are correct. To help us, PRPC provides two options check for consistency and check for
completeness.
The Check for Consistency button verifies that there are not any unreachable paths in the rule and that
there are no logic conflicts. For example, if we configure two conditions that evaluate the same thing, say
the first condition is if urgency is < 40 and the second condition is if urgency is > 20, then both these
rows are in conflict since a value of 30 satisfies both conditions.
The Check for Completeness button populates all values that are part of otherwise, giving us an
opportunity to review and maybe add logic for those conditions. Completeness is just a suggestion by
PRPC and we need not always use it.
The rules can be tested by using the Run option in Actions menu.
It shows the first column, we enter a value and click the Run again button to see the second column.
346
Conclusion
Decision rules play a key role in automating business processes by evaluating a set of specified
conditions. The decisions made can affect how the case is processed in terms of which path it takes, how
the calculations are changed based on decisions, and what is presented users based on a set of
conditions.
Pega offers decision trees, decision tables, when and map value rules to handle these requirements.
Well learn more about how to reference the decision rules in the Process modeling and UI lessons.
347
Validation
Validation of data ensures the quality of the information being used in the application and in the business
process.
In general, data validation involves examining incoming values to ensure that they meet the applications
requirements. The values coming into the application from a user or external source are compared
against pre-defined criteria. If the values do not meet the criteria, the system raises an error, and further
action can be taken, such as prompting for the correct information, or rejecting the incoming values
entirely.
Validation of data input by the users has been covered in detail in the System Architect Essentials (SAE) I
and II courses, as well as in the user experience lessons in this course. In this lesson, we will look at the
overall validation process. We will review some of the concepts that are already covered, at high level,
and we will explain new concepts in detail.
In PRPC,
Property rules are part of the Data Model category and are instances of the Rule-Obj-Property
rule type.
Control rules are part of the User Interface category and are instances of the Rule-HTMLProperty rule type.
Validate rules are part of the Process category and are instances of the Rule-Obj-Validate rule
type.
Edit Validate rules are part of the Data Model category and are instances of the Rule-EditValidate rule type.
Constraints rules are part of the Decision category and are instances of the Rule-DeclareConstraints rule type.
Explain the different levels of validation that PRPC provides
Configure Constraints validation
Describe Case level validation
Use the appropriate validation mechanism for different validation requirements
Different Levels of Validation

PRPC supports different levels of validation:
Mode validation: This validation is automatic and always in force.
Dictionary validation: Part of this level of validation occurs automatically and another part
occurs when it is built into the application and at specific times during the process execution.
Object validation occurs only when explicitly designed into the application.
Another validation level which is optional and occurs only when built in the application is
Constraint validation. Based on declarative constraint rules, it is evaluated automatically by the
system each time a property identified in a constraint rule changes
Mode validation leverages the property mode setting. A property mode is identified on the General tab
of the property rule form and it is combined with property type, as shown below. The Mode Validation
enforces the property mode when a value is being assigned to a property. For example, you cannot set
348
the value of a Single Value

V
property
y to a page. As
A stated earliier this validattion is alwayss in force and done
cally by the sy
ystem.
automatic
The Dictio
onary validattion examines
s a property value
v
in the co
ontext of the ccorresponding
g property rulle. It
includes multiple
m
valida
ation tests. Th
he first validattion test is to ensure that the property vvalue is compatible
with its typ
pe. For example, a propertty of Integer type
t
cannot ccontain stringss as a value. The list of
available standard prop
perty modes and
a types is shown
s
above .
The next validation
v
tes
st is related to
o the Maximum length asssigned to the property. On the Advance
ed
tab of the Property rule
e form, Pega 7 allows us to
o specify a ch
haracter limit ffor Value mod
de properties of
sword, Text orr Identifier. Th
he system uses any value specified in tthis field to restrict the prop
perty
type Pass
value to a specific max
ximum numbe
er of characters. If the leng
gth of the inpu
ut string excee
eds this limit, the
clipboard keeps the lon
nger value, bu
ut the dictiona
ary validation adds an asso
ociated error message.
We may also
a
reference
e an Edit Validate rule which
w
defines a Java routin
ne that tests th
he validity of a
an
input value. Normally, if user input fa
ails such proc
cessing, the in
nput is rejecte
ed and a red X appears ne
ext to
f
in error along
a
with me
essages that may
m convey m
more about th
he error and the suggested
d
the input field
349
remedy. Users
U
can cha
ange the inpu
ut and resubm
mit the form. Edit Validate
e validation iss only possible
with prope
erties of mode
e Single Valu
ue, Value List, or Value
e Group. Anyy architect who
o has java
knowledge can build ne
ew edit-valida
ate rules. Or we
w can use a ny of the stan
ndard rules th
hat are availab
ble to
us.
ample, we use
ed a standard
d edit validate
e rule, USZipC
Code, which cchecks for wh
hether the patttern
In this exa
is 5 digits.
The otherr validation tes

sts performed
d at this level are the Cont rol and Table
e validations. Both are
configured
d in the Gene
eral tab of th
he property rule form.
The contrrol shown here

e is for a date
e property and
d when this p
property is inccluded in a UI rule, PRPC
validates that the user can enter a date
d
or select a date from a calendar.
For other properties su
uch as States or Countries in an addres s, we can havve the users sselect from th
he list
ossibly typing an invalid vallue. The Tabl e type field iss used for thiss purpose. To
o use
of values instead of po
dation, first make sure to select Single Value,
V
Value List, or Value
e Group for the Property Mode
table valid
field as we
e cannot use table validation for properrties of any otther modes. T
Table values ccan come for any
one of tho
ose in the list shown.
As we jus
st saw, Dictio
onary validatio
on includes multiple
m
differe
ent tests. The
ese tests are performed byy the
system when:
User
U
input ente
ered on an HT
TML form is placed
p
on the
e clipboard.
The Page-Validate method (in an activity

y rule) is appliied to a page
e containing th
he property, o
or to
he property if it has mode Page.
P
th
350
An
A Edit Input rule and Prope
erty-Validate method (in an
n activity rule
e) is applied to
o the propertyy. [An
ed
dit input rule provides
p
a co
onversion facility. We can u
use edit inputt rules to convvert data ente
ered
by
y a user (or re
eceived from an external system)
s
from a format that our applicatio
on doesn't usse into
an
nother formatt. We can refe
erence an ediit input rule in
n the Edit Inpu
ut Value field on the advan
nced
ta
ab of Property
y rule.]
This type of control and

d display valid
dation can be
e enabled in a user interfacce rule as well, under the
ation tab of th
he cell, where
e the property is included. We can conffigure require
ed fields valid
dation
Presenta
in the Ge
eneral tab.
The next level of valida

ation is Object validation
n. This valida
ation is optional and occurss when a flow
w
e calls a Valiidate rule, orr when called by a corresp
pondence rule
e to validate u
user response
es to
action rule
prompts, or
o when the Obj-Validate method is ca
alled in an acctivity. This me
ethod execute
es a validation rule
to test a set
s of property
y values. The details of the
e validate rule
es have been covered in th
he SAE I and SAE
II courses
s.
The valida
ation error me
essage invalid
dates the pag
ge, preventing
g it to be perssisted. The dissplay of the
validation error messag
ge can be con
nfigured or cu
ustomized. Th
his has been covered in SA
AE I and SAE
E II
courses
Process Commander
C
provides
p
one more level off validation: th
he Constraintts validation with Declare
constraintts rules, which
h we will discuss next.
Constrraint Validation
Constraints rules provide an automa
atic form of prroperty valida
ation every tim
me the properrty's value
o the validation provided by
y the propertyy rule or otherr means. The technique ussed is
changes, in addition to
called forrward chaining, like in many other declarative rule tyypes.
The syste
em automatica
ally adds a message to any property tha
at is present o
on the clipboa
ard and fails a
constraintt. No other rules explicitly reference
r
con
nstraints ruless. When we save a constra
aints rule, Pro
ocess
Command
der enforces it immediately
y and thereaftter.
We can create the constraints rule using
u
any exp
plorer. In the C
Constraints ru
ule, use the C
Constraints ttab to
e configurations that constrain the prope
erty values.
record the
351
First row checks

c
for a When
W
conditio
on. Here we are
a checking whether the cclient is a pre
eferred client ffor
any applic
cation that inv
volves custom
mer service. The
T second ro
ow is the consstraint and he
ere we are
checking whether the client
c
name has a value orr not. The third
d line, Else a
add message allows us to
o add
essage to bec
come associa
ated with that property or a
another prope
erty when the
a specific additional me
f
the consttraint. Like ma
any other rule
es, we can usse or build ourr own expresssions for the w
when
property fails
and consttraint conditio
ons. We may add
a more con
nstraints by ussing the Add
d new Constra
aint before thiis
one or A
Add new Cons
straint after th
his one icons
s.
At runtime
e, when the system detects
s that a consttraint fails, it a
adds a messa
age to the pag
ge of the prop
perty
identified in the left porrtion of the R
Require That field, if any.
Because constraint
c
vallidation is enfforced automa
atically by the
e system anyttime the prope
ertys value
changes, it might cause a performance impact. Therefore,
T
it iss critical to evvaluate the po
otential impacct
oosing this ty
ype of validatio
on.
before cho
Case le
evel Valid
dation
We learne
ed in other co
ourses how to
o use validatio
on rules in flow
w actions in a flow rule. In the Details ta
ab of
the Case Designer, we
e can configurre the validation rules to ru
un when a casse is instantia
ated and/or
s
in the database.
d
The
e advantage o
of having the validation at case level is,,
wheneverr the case is saved
wheneverr we need to validate
v
certain data for ev
very saving off the case insttances, we ca
an configure iit in
the case designer
d
once
e instead of needing
n
to call the validate rule in multip
ple flow action
ns. When a
purchase request is ma
ade, we can validate
v
whether the paren
nt case has en
nough funds tto process this
efore adding the case to th
he Program Fund
F
parent ccase.
request be
352
Clicking on
o these two links opens up
u Work-Cove
er-.OnAdd an d Work-Cove
er-.Validate ru
ules. These ca
an be
specialize
ed by putting the
t rules in th
he work class of the work p
pool or a speccific case. The
e validation ru
ules
can be co
onfigured like any other validation rule th
hat we used i n the SAE I a
and SAE II courses.
353
Similarly, we can perfo

orm validation upon stage entry,
e
which w
we configure in the Case D
Designer. For
r
to validatte whether alll the data entrry for the ven
ndor informatio
on
example, we can have a validation rule
ed by the requ
uestor himselff/herself or the
e acquisition department, before final a
approval by th
he VP.
either fille
Since we would not know who would be filling in that informat ion, we can h
have that valid
dation in the sstage
ead of at each
h flow action meant for the
e requestor an
nd the acquissition departm
ment. We can also
entry inste
require that any specifiied attachmen
nts be added to the case b
before the casse can enter a stage.
Usage of Valida
ation rule
es
Most the validations
v
ex
xplained in the
e previous se
ections, such a
as property m
mode, propertty type, contro
ol
(such as pxDateTime),
p
, expected len
ngth, required
d field, and ta ble values arre self-explan
natory and easy to
understan
nd how they are
a used.. Butt, will these be
e enough for validation? Lets looks at a
an example. W
We
want to re
estrict users so that they ca
annot enter a date in the fu
uture for the d
date of birth fiield since it iss not
valid. Defining date of birth as a date property an
nd using the ccalendar contrrol users cannot choose
o
than a date
d
value, ho
owever users can select a future date. T
This is where Validate, Ediit
anything other
Validate, and
a Constrain
nts rules com
me into picture
e.
Lets do a comparison of the first tw
wo to understa
and when to u
use them appropriately.
The edit validate
v
rule te
ests the validity of a single
e input value a
and the tests are built usin
ng Java. It is
specified in the propertty rule for the tested prope
erty. The syste
em has a num
mber of stand
dard edit validate
rules that we can use in our application.
354
In contras
st, the validate
e rule can tes
st the validity of
o multiple inp
put values at once, and the
e tests are bu
uilt
using eas
sier-to-understand "If-And-O
Or" logical ex
xpressions ratther than Java
a code.
It is speciffied on the flo
ow action rule
e that presents
s the form to the user, and
d multiple flow
w actions can use
the same validate rule.. Or it can be at the case le
evel or stage level validatio
on.
In general, it is a best practice
p
to us
se validate rules over edit vvalidate rules, because:
Validate
V
rules are easier forr non-program
mmers to desiign and unde
erstand. Edit vvalidate rules
re
equire Java programming skills.
s
process and tthe user interrface, becausse

Validate
V
rules are more con
nnected with the
t business p
flo
ow actions an
nd case desig
gner can call them.
t
Validate
V
rules simplify application design
n, because on
ne validate rulle can verify m
multiple inputt
va
alues at once
e.
Constraints validation automatically

a
happens whe
en a propertyy changes its value. If we w
want the automatic
n we use cons
straints valida
ation.. But thiss might have a performancce
validation at the properrty level, then
o we need to use it properlly.
impact, so
Constraints, Edit Valida
ate, and Valid
date rules are
e server-side vvalidation va
alidation occu
urs on the serrver
esult is sent back
b
to the clie
ent. All other validations ru
ules are clientt-side validatiions. The En
nable
and the re
client side
e validation fllag should be
e checked in the Advanced
d tab of the h
harness or in the HTML ttab of
the flow action
a
rules, fo
or client-side validations
v
to
o work. The ha
arness rule en
ption for the w
whole
nables the op
flow, if the
e harness is not
n changed, while
w
the flow
w action rule ccan be used tto override forr a specific acction.
355
Conclu
usion
In this lesson, we discu
ussed how to help users enter valid pro perty values into an HTML
L form in PRP
PC
ate the data re
eceived from another syste
em or source
e. When a valu
ue fails to passs the validattion
and valida
test, the system
s
adds a message to
o the clipboard
d page contaiining the value that displayys to end users.
The valida
ation error me
essage invalid
dates the pag
ge, preventing
g it to be perssisted. A set o
of configuratio
on
items and
d rules allows different type
es and levels of validation.
Validation
n can be confiigured on pro
operty rules an
nd section rulles. Validation
n rules can be
e referenced on
flow action, property ru
ules and on Case
C
Designerr. Validation ccan be serverr side or client side.
356
Module 07: Reporting
Creating Business User Reports
Configuring Reports
Data Model in Reports
Data Visualization using Charts
357
Creating Business User Reports

Introduction
End users, like managers, want to track the progress of everyone who reports to them. VPs would like to
receive the same report in their email and managers might want to modify the reports or even create
some of them. In this lesson, we will learn how we can address these requirements.
One of the key functions of Pegas PRPC reporting capabilities is to provide access to ad hoc reports that
a business analyst or a manager can easily run. These reports help them check various business and
process metrics such as the average time it takes to resolve a case, the workload for various operators,
and key performance indicators.
PRPC also offers the ability to schedule an email containing the results of a report by subscribing to them.
Learn reporting terminology
Create reports using the Report Editor
Use the Report editor to filter, sort, and summarize reports
Lets take a step back and learn about some of the key terms we need to know to better understand
PRPCs reporting capabilities.
Reporting Terminology
The Ad-hoc Reports are accessible in a Report Browser. The report browser is included as part of the
default Case Manager portal. While designing end user portals, we highly recommend that you customize
how the reports are presented. PRPC ships with a wide variety of standard reports, so its absolutely
essential to decide which of these reports are necessary for users.
358
Next are the Report Categories. There are two types of categories Private and Public (with standard
and shared types). Private Categories are specific to an operator, so the reports in that category can be
accessed only by that operator. Public Categories include all standard and shared reports.
There are two types of standard reportsreports that are shipped with the product and categories
created by developers. When a developer creates a category, in this example ADV reports, its
accessible for all users who can view the report browser.
Public Categories also include shared reports. When a manager creates a new category, PRPC saves it
as a shared category and only users belonging to the same access group can access the reports in it.
The Category is saved as a rule but when we open the rule we can see that it only has a short
description. The category rule does not indicate the category typePublic (Shared or Standard) or
Private (Personal).
That leads us to Shortcutsa shortcut is a link that displays the report title in the report browser. When
we click on a category, for example, Monitor Assignments, we see all the shortcuts that are defined in that
category.
Shortcuts serve two purposesthey provide a pointer to a report definition rule that is used in presenting
the results and the category type where this shortcut appears.
The shortcut rule has three parts:
359
Category it belongs to: MyReports
Category type: Private (P)
Operator Manager@LES (only that operator can access it)
The shortcut is displayed as a link and when we click, it, we see the report results in the Report Viewer.
The Report Viewer also allows us to manipulate the results. There is a toolbar on the top with options to
export the results to a pdf or excel or to a printer.
360
The Filter criteria can be edited by clicking on the link and modifying the condition.
In addition to this, the report viewer supports a wider choice of command menus which can be accessed
by right-clicking on a column header.
We can control what users can do in the report viewer by configuring them in the actual report definition
rule. This allows us to configure these actions to be specific for each report instead of using the same for
all reports the managers are using.
We can also restrict the report from appearing in the report browser if the report is not to be used as an
ad-hoc report.
361
For making additional edits, we also have the Report Editor which lets us edit the report by adding new
columns and making a variety of other changes. The report editor is very powerful and enables us to build
a report using a visual interface rather than using the report definition rule form.
The report definition rule form is accessible only to developers; however, developers can access the
report browser by using the edit link on the report definition rule or by using the reporting landing page.
362
Creating New Reports

If a manager wishes to restrict reports to their own group of users, then the manager should create a new
category in the report browser. The categories must be created manually before we begin creating
reports. If a developer creates a category all reports saved as part of that category are standard reports.
In this case, ADV Reports are defined by the developer.
After creating the category, we can create a report and select which category it belongs to. When
creating a new report, we need to select the following:
1. Type of report (list or summary) and
2. The data that we want to run the report against it can be one of the case types or, if we need to
run it against all the case types, then we select the work pool. We can also report on assignments
to track the case processing.
Clicking OK opens up the report in Report Editor for the manager to complete it. The system actually
creates a report before the manager makes any changes. To do this, it uses a template rule named
pyDefaultReport. We can modify the template rule to include additional columns or new filter criteria.
363
The Report Editor provides more options than the Report Viewerwe can add new columns for filtering,
add new columns to the report, delete the columns that are currently in the report, and so on. The Report
Editor is also available for developers in addition to them being able to work on the report definition rule
form directly. In most cases, we can build the report with all the features without ever opening the report
definition rule form.
After making changes, use the save link (at the top of the Report Editor) to save the rule.
When a manager creates a report, it must be saved in the private category (in this case, My Reports).
The system also creates a shortcut rule which provides access to the report definition rule.
After defining the report, the manager can keep it private until he finishes completing it. To share it with
other users, they should use the Take action on report icon to access this menu.
364
The manager then has to select the category where they want the report to be saved.
The copy action creates only a new shortcut rule and, when opened, we see that the report is in the
Manager Reports category accessible by all operators (A) in the Purchasing:Managers access group.
When copied, it creates a shortcut rule and is still referencing the same report definition rule that was
created earlier.
When we open Records explorer, we can see all the instances of shortcuts. The OpenCases report has
two shortcuts - one in the ManagerReports category which is shared with all purchasing managers in
the PurchasingMangers access group while the other is in the MyReports category accessible only for
Manager@LES and is a personal report. Both of these reports point to the same rule and, at this point,
the manager has the option to delete the shortcut that is in his private category.
365
Report Scheduling and Subscription

In additon to the business users who would like to view and create reports, there are other users who are
interested in looking at the report results but do not want to login to a system to do so. Managers can print
report results as a PDF and send them via email, but PRPC has a report subscription feature that does
this automatically. The report that we created can be scheduled to be run on a set interval and the report
results can be sent automatically in an email.
To configure this, use the Take action on report menu to schedule a report.
Once we click Schedule, it provides options for us to configure to schedule the report. We can select if it
has to be scheduled once or if it can be a recurring task that occurs after a specific time period. We can
also configure the format of the report results and the email message which is sent automatically to a set
of users.
366
367
Production RuleSets
Before concluding this lesson, lets quickly run through another important concept that developers need to
implement for the managers to create reports. When applications require business users to make
modifications, we need to make sure that the report definition rule allows modifications even in a
production environment.
To implement this functionality, we need to define a RuleSet and then add it as a production RuleSet in
the application. Production RuleSets remain unlocked in production so that the rules belonging to that
RuleSet can be modified by users. However, we need to ensure that we are allowing this for a specific
group of people and not to everyone.
For example, if we want managers to work on performance metric reports, we create a new ruleset and
add it as the design-time configuration ruleset on the manager access group so only they get access to
these rules.
Often, developers create reports in a private ruleset such as a branch or a personal ruleset so that
they can test their reports before making them available to all users. By branching the production ruleset,
we can also allow business users to create and configure reports in a private environment without
disrupting the production environment.
Conclusion
Business users require the power and flexibility to create or modify reports and giving them the option to
do this increases their productivity since they can directly build them in the system instead of waiting for
developers to create it for them.
In this lesson, we learned how PRPC offers toolsets like the Report Editor, the Report Viewer and the
Report browser for end users to quickly create, modify, and access these reports. We also learned about
the scheduling and subscription feature where users can get the report results directly in their inbox as an
email attachment.
368
Configuring Reports
Introduction
Reports generated by PRPC sometimes display a lot of data that does not serve any purpose. We will
learn about how to split a long running report into various pages, available options to query a limited set
of records and how not to compromise application performance.
Cases capture a lot of information and instead of presenting all of it as columns, we may need to present
the primary data as columns and supplement the data with options to look up the additional details using
sections.
We will also lesson learn how to:
Customize the presentation of the reporting results to improve usability
Add pagination, headers and footers,
Format the column value
Add sections to provide additional details for each row
Enterprise applications usually involve a lot of data. Reporting on such applications is not always as
simple as displaying the columns in a list or grouping them on a specific field. There may be cases where
we would like to apply manipulations to the data before presenting the data to the user. Lets take a look
at couple of such requirements:
The database stores the feedback score as numbers like 3, 9 and 6. It makes more sense to
present the results to the user as Low, Exceptional, and Average.
We want to get a list of all purchase requests that are not waiting for any user action. This report
involves two separate entities case and assignments.
How should we design reports to handle these requirements? In this lesson, we will introduce concepts
such as SQL Functions and Sub Reports that helps us in building these reports.
Use the report definition rule form to configure different features
Configure Pagination and threshold settings
Setup SmartInfo and custom row sections
Define and Configure Sub Reports
Use existing SQL Functions and create new functions
Leverage an alternate reporting database
369
Using the Report Definition Rule form

We can use the Reporting Landing page to access the report browser and then use the Report Editor to
create and configure reports. However, there are a few requirements that force us to work directly in the
report definition rule forms. Lets take a look at some of these requirements. The settings within the first
two tabs, Query and Chart can be configured either with the report definition, report editor or the report
viewer. The last three tabs exist in most of the rule forms.
The choices in the Report Viewer and Data Access tabs can be performed only in the report definition
rule form. In the Report Viewer tab we decide which options we want to make available to the business
users when they are in the report viewer. For example, do we want users to be able to change filter
criteria, and/or access the command menu by right-clicking on a column, and what options should be
made available in that toolbar.
We will learn about the Data Access tab in the Creating Sub Reports topic later in this lesson.
There are other features that require us to open up the report definition rule form. Lets look at few of the
most common ones.
370
Configuring Pagination and Threshold Settings

Enterprise applications over a period of time will have thousands or even millions of database rows as
more and more cases are created.
One way to limit the number of results that the user can see at a time is to use Pagination. Pagination can
be added by just enabling a flag in the User Actions area. This is accessible in the Report viewer tab of
the report definition rule.
The Paging options allow us to customize the pagination features such as the Page size (number of rows
per page) and Page mode (the pagination format).
When paging is configured, the system retrieves only the rows that are required in the current page and it
retrieves the results for the next page only when that page is accessed. Paging in addition to filtering
helps to limit the number of records that we query from the database.
In addition to this, PRPC also allows setting threshold values on cases when paging cannot be enabled.
In such cases, these threshold values help to limit the number of rows accessed by the system. We can
limit the maximum number of rows that it can retrieved, by default its set to 500. We can also set the
maximum elapsed time in seconds, by default its set to 30 seconds. The system stops at the time limit
and displays a message indicating that the report is taking a long time to run.
If the application is configured to export the results, we can set thresholds for the maximum number of
records and the maximum amount of elapsed time to avoid performance issues.
371
Setting Up Smart Info and Other Sections

Reports can use section rules to present additional content.
Lets take a look at the two of the most important reasons sections are applied on a report definition rule.
The first reason is when we need a custom section for filtering. When we define filters for a report, PRPC
automatically opens the section in a new dialog. However we can override that by using a custom section.
We typically use a custom filter section when we want to give business user some help in selecting a filter
value or customizing the filters.
The second reason is to include smart Info. Reports display data in a grid structure rows and columns,
each record displays as a row and the columns provide values of other fields specific to that row. For
example, a Purchase requests case collects data for twenty different properties. In our report we include
three columns to show case type, case ID and case status.
To see the additional information, users can click the icon in each row.
372
The feature that we use to configure this behavior is called Smart Info. First we select the Enable Smart
Info flag in the Report Viewer tab and then click the options next to Enable Smart Info. This opens up a
dialog where we enter getSmartInfo in the Content field. That is the name of the activity rule shipped in
PRPC to render a Smart Info box. The activity references a section named SmartInfo to get the contents.
The default SmartInfo section shows this content.

[SmartInfo_Expand.png]
To display the information that is specific to our application, we can create a section rule named
SmartInfo in our application.
373
In addition, we can also change the appearance of the report header by configuring the corresponding
section, pyReportEditorHeader, in the Code-Pega-List class. Unlike the other sections weve discussed,
we can customize this section by copying it into an application ruleset and configuring it as needed.
374
Creating and Configuring Sub Reports

A report can be added as a sub report to another report. In such cases the sub report results are
available in the main report where it is linked. We typically use sub reports when we want to filter a list
based on data stored in another class. For example, we want to display a list of all Purchase Requests
ordered by total price (higher to lower) with assignments that are past goal. To do this, lets create a
report in Assign-Worklist where all the assignments are past goal. Then lets create a parent report that
shows the details of all the Purchase Requests that match the results of the sub report.
In short, sub reports are PRPCs way of handling the IN, HAVING and WITH clauses.
Another popular way of using sub reports is to display aggregate calculations. For example, suppose we
want to see a list of cases, along with the number of sub cases within each case. We use sub reports
when we require aggregate calculations to be performed on a specific row. When we use Sub reports to
display aggregate calculations, they usually appear as a column in the report. Another example of a sub
report used to display aggregate calculation is : The report displaying the list of all resolved parent cases
should display date the first sub case was resolved and the date the last sub case was resolved.
Review the related content link titled When and how to use sub-reports in Report Definition reports
which details various use cases where sub reports can be used.
375
Creating Sub Reports

So, how do we create sub reports? It is the same way we create any other report - we create a report,
add the columns that we are interested in, add any filter conditions and save it. If you need more options
to link the sub report to another report, we may need to disable the Get Row Key in the Row Key Settings
section under the Data access tab.
In the main report, sub reports are configured in the Data Access tab. We add a prefix, enter the class
and select the report we want to use as a sub report. When sub reports are used to filter the results in the
main report, we do not need to make any changes in the dialog, but we may need to use the alias
mentioned in the sub report dialog in the filter condition.
However when fields in sub reports are presented in the main report such as in the aggregation example,
we need to enable the Columns to Include field and then configure the join condition, filter criteria and
what rows to include.
376
Using an Alternate Reporting Database

Running reports on live data may cause performance issues, impacting both the users working with
cases, and users reporting on those cases. To avoid potential or realized performance issues of this
nature, reports can be run against a copy of the database, also referred to as a mirror.
To run reports against a mirror database, enable the Use alternate database option on the Data Access
tab. When enabled, report queries are run against the database identified in the Reports Database field of
the Data-Admin-DB-Table record that corresponds to the class of the report.
For this configuration to work properly, all of the data used by the report must be present in the alternate
database. This includes any tables that are required by JOIN operations.
377
SQL Functions
Reports display the results that are stored in a specific database table. Tables might store codes which
require us to format the values to present them in a way that enable us to interpret the results better.
Lets look at a couple of requirements:The first requirement is to have the report always display the number of days it took to resolve a
case from the date of its creation.
The second requirement is to have the report format the feedback rating received from users
(who enter the rating on a scale from 1 to 10) to convert them into labels (Excellent, Good, Fair or
Poor).
SQL functions are helpful in addressing this requirement. SQL functions are applied at the database level,
so the function is passed directly in the query that is executed against the table.
SQL Functions apply to a class named Embed-UserFunction and are saved as a Function Alias rule type.
PRPC comes with a lot of standard SQL functions that we can use without making any changes.
Data Type
Standard SQL Functions
String
Concatenate, Replace,
Substring, Length, Upper Case,
Lower Case, etc.
Number
Add, Subtract, Divide, Multiply,

Subtract Decimal, etc.,
Date
Difference between days,

Current date time, Add Days,
Day of, Month of, First day of
quarter, etc.
Conversion
Numeric to text, text to date,

text to decimal, text to integer,
etc.
SLA based
SLA Age Timeliness, SLA work

Timeliness and SLA assign
timeliness etc.
The first requirement can be addressed by using the Difference between days function.
To add a function, we need to add a column and then click the fx button to open the calculation builder.
378
To pick a function from the list, enter a few characters of the function name and then we can select the
one we want.
A Function Alias if created properly can provide the proper instructions so that managers can add them in
reports.
When we run the report it now shows the date difference.
However, for the Rating score field we need to write a new function. We can access the list of all SQL
functions using the landing page. The landing page has a new button to create a new SQL function. The
Function Alias rule must be defined in Embed-UserFunction class.
379
The Function Alias rule form has three main parts:

Input Parameters In our example, we have one input parameter (Feedback Rating) which has
to be converted.
Presentation section Identifies the type of function (text), and also the data it returns. The
string entered in the Pattern Template is what is shown in the calculation builder from which users
make a selection, so we need to make sure that we enter something meaningful.
The Source Here we enter the code for implementing the logic. Usually to create a Function
alias you need to have knowledge of SQL, therefore they are usually created by developers who
are familiar with SQL. Since it uses SQL, we may have to create platform specific rules if SQL
scripts vary with the database we use. Most of the time we will be using one database. However,
when defining new SQL functions it makes sense to define them for other databases so that in
future the migration is smoother. We can use circumstancing to create function alias rules for
different databases.
380
Functions once defined can be added onto reports directly by managers. Functions are available
in the report editor under the Calculations tab.
381
Conclusion
PRPC offers a wide variety of tools report browser, report viewer report editor to create and configure
reports easily. In this lesson we looked at various reasons why we may require opening the underlying
report definition rule form to make these changes.
Reports may need to reference a sub report to filter data or to include aggregate calculations on each
row. We know we need to use a sub report when we need to query data from a table and use it to filter
the data in another table. For example, if we want to display the date on which the first subcase was
resolved in the report.
Lastly we looked at how to format the codes saved in database into meaningful text. What does a
feedback rating of 7 really mean? The underlying database might save the score as 7, but we want the
report to display Good instead of 7 to make it more meaningful. We learned that we can use standard
SQL functions to display the information rather than creating another property that saves these labels. We
also looked at SQL Functions, how to use the standard SQL functions and how we can create a new one.
382
Data Modeling in Reports

Introduction
Customers use reports for a wide variety of purposes. For example, managers may want to know:
How many cases get created by users calling for support
Which CSRs resolved the most cases during the past 3 quarters
How many resolved cases during the past two months had exceptions and required a specialized
CSR to intervene to solve the problem
Having this information then helps managers improve their processes and improve customer service.
PRPC saves data across multiple tables when a case is being processed. When designing reports, it is
important for us to know which table has the data we need.
In this lesson we will learn about the three most important data points that we would like to report on such
as case related information, assignment related information (who is currently on the case) and the audit
trail for that case. We will learn which database tables are used to store this information.
We will see how a PRPC concept like a class, property or the case corresponds to a database concept
such as table, column and row.
In addition, we will learn how to join or associate database tables so that a single report can display
columns from more than one database table.
We will conclude this lesson by learning about the need for optimization and how it helps to enhance the
performance of our reports.
Understand where to look for a specific data set
Create a report that displays values stored in separate tables
Enhance the report performance by optimizing the properties
383
Data Storage in PRPC

Lets begin by looking at how data collected in a case gets saved in PRPC database tables.
Understanding how data gets stored provides us with a good foundation for designing reports.
Though classes are mainly used for applicability of rules and play a key role in inheritance, they are also
useful in deciding where the data is persisted. If the PRPC classes can have instances, then they are
mapped to a database table. When the class is mapped to a table, the instances of that class are saved
as individual rows in the mapped database table.
When a class is used as a work pool (class group), any instances of that class or any class defined as
belonging to the class group are saved in the same database table.
For example, when users create a new purchase request, the system assigns a case ID and it is saved in
a new row in the database table named pc_ADV_Purchasing_Work. When a sub case is created for the
purchase request, such as a purchase order, PRPC adds another row in the same database table.
Each case is treated as a separate entity and is saved as a new row in the database table. So, how do
we know which database table the class is mapped to? PRPC uses two records for managing the
database mapping namely, DB Name and DB Table
DB Name record defines the database configuration detailsand can be configured to use either JNDI or
JDBC url for the database connection details.
Pega by default, uses the:

1.
PegaRULES record which maps to a database where all the rules are saved.
2.
PegaDATA record which maps to a database where all data instances are saved.
The second one is DB Table record- which defines the class name, the database table name and the DB
Table record.
As mentioned earlier, we may need to write reports on varied data sets, so lets look at the three most
important data sets that we would most likely want to report on.
384
Case Based Reports

When a case is created, it uses a variety of properties - a list of all standard properties to save the date of
creation, the name of the user who created the case, the status of the case, the list of all interested
parties for that case and so on. In general, PRPC uses a specialized table structure which uses a BLOB
column to save all of these properties. Using a BLOB column provides us with the flexibility to design the
data model without any restrictions. We will learn about the limitations of the BLOB in terms of reporting
and how we can address them later in this lesson. So in addition to being stored as part of the BLOB
these properties are also saved as columns in the database table.
A purchase request case also has application specific properties in addition to the standard properties.
These properties are also saved in the same database table as part of the BLOB.
Lets take a look at some of the most important standard properties we need to know in order for us to
report on them. We do not need to remember the names because entering text such as the create date
time in the column field will help us find the property we are looking for.
pyID the case ID
pyStatusWork the case status
pxCreateDateTime the date the case created on
pxUpdateDateTime the date the case last updated on
pxCreateOpName the operator who created the case
pxUpdateOpName the name of the operator who last updated the case
Additionally we may also need properties that are used after the case is resolved such as:
pyResolvedTimestamp the time when case got resolved
pyResolvedUserID the operator who resolved the case
pyResolutionCost the Resolution cost
Additional properties for resolved user work group, org, unit or division
There are also properties to determine the time period between goal and resolution
(pyElapsedPastGoal) as well as deadline and resolution (pyElapsedPastDeadline). We can also look at
properties such as pyEffortEstimate and pyEffortActual for the effort in completing the case.
Lastly, we can also see how much time was spent at each status - pyElapsedStatusNew,
pyElapsedStatusOpen and pyElapsedStatusPending.
When we define subcases, then we need to know about a few additional properties if we are creating
reports with data from multiple classes.
The most important property we need to know is pzInsKey this is the internal identifier used by PRPC
for each case. A subcase for a purchase request, say PurchaseOrder will have a property named
pxCoverInsKey (this is the property used to identify the parent case) which had the value of the
pzInsKey of the Purchase Request.
So, lets identify a few properties that are specific to cases as you might find these helpful with reporting:
The Covered SubCase Count, (pxCoveredCount)
The Covered Open SubCase Count,(pxCoveredCountOpen)
The Covered Subcase Actual Effort Total, and (pySubTasksEffortActual)
The Covered Subcase Estimated Effort Total.(pySubTasksEffortEstimate)
385
Assignment Reports
When a case is being processed, it gets assigned to a user if it requires a user action. Each time a case
gets assigned PRPC also creates an assignment object. Once the assignment is resolved the case
moves on and a new assignment is created when another assignment shape is encountered. If the
assignment is routed to an operator, it gets saved in the database table named pc_assign_worklist and
if the assignment is routed to a workbasket it gets saved in a database table named
pc_assign_workbasket.
Lets take a look at some of the properties that are specific to assignments that you might find are
required while creating reports:
pxAssignedOperatorID - the operator or workbasket who has the assignment
pxFlowName the name of the flow rule for the assignment
pxTaskLabel the name of the assignment shape
One other important property to know about is the pxRefObjectKey which is mapped to pzInsKey so the
case and assignments are related to each other.
Audit Trail reports

When a case is being processed, the system automatically captures the audit trail using history classes
which are mapped to History database table where the data is saved. History reports use a variety of
properties such as:
pyHistoryType the type of history

o
F - flow action
L Local Action
A - When flow reaches assignment shape
M - Memo
R the assignment transferred to another operator/workbasket
pyWorkClass - the description of the case
pyFlowName the name of the flow
pxTimeCreated time when audit trail is recorded, this is actually after each action is submitted
pyTaskName the name of assignment
pxFlowAction the name of flow action
pyPerformer the operator id
History tables can also be used when designing performance-based reports and we want to capture
process metrics to see how to improve the business process.
pxTaskElapsedTime total time spent on an assignment
pyPerformActionTime total time spent on the most recent action
pyPerformAssignmentTime total time spent on that assignment including all local actions on
that assignment
These times along with a few others give an indication as to why an assignment takes longer to complete.
If more than one operator works on the case then we need to know about these properties as well.
pxAssignmentElapsedTime total time elapsed after the assignment is routed -this indicates
how long the assignment was waiting for user action
386
pyPerformTaskTime total time spent by all users, this is applicable when the assignment is
routed to multiple users - this value is equal to pyPerformAssignmentTime if only one user works
on the case.
If pyPerformTaskTime is significantly lower than pxTaskElapsedTime then the assignment has been idle
for a long time.
Using these properties in a report we could find out how each operator is performing. Note that the times
returned by these columns are in seconds, so we would need to use functions to convert them into the
time into hours or days. Functions are discussed in detail in a separate lesson in this course.
387
Defining Relationships between Tables

Now that we have seen all the data sets, lets see how we can build relationships between tables.
Remember that we need to build relationships between tables to access data from multiple tables in one
report. We would like relationships between the following tables.
1. Case and Subcase relationship - : Use to access subcase data along with the parent case data
2. Case and Assignments: Use to show how assignments are processed for a specific case or a
subcase
3. Case and History: Use to monitor the performance to show where the total time is spent on a
specific case
The second and third relationship require building a relationship between two different tables while the
first one requires building a relationship to get data from two different records in the same table.
PRPC gives us two options to do this. We can configure the Join directly in the report definition rule form
or we can create an association rule which defines the Join, and then reference the association rule
wherever its required.
Join:
Class Join is configured in the report definition rule form. For example, in this case we have the
OpenCases report defined in Purchase Request class. To configure a class join we define a prefix (PO)
to join to ADV-Purchasing-Work-PurchaseOrder class with the Purchase Request Class. PRPC allows
both Inner and Outer Joins - Inner Joins return records that are in both tables while Outer Joins return all
the matched records from one table and all the records(including unmatched) from another table. Select
only include matching rows is an option to configure the Inner Join. There are two options to configure an
Outer Join depending if we require all rows from PurchaseOrder or from the Purchase Request.
After defining the prefix, we need to define the condition; in this case we need to match the pzinskey of
the purchase request with the pxcoverinskey of purchaseorder.
To display any property belonging to PurchaseOrder class we need to use the prefix (PO) that we defined
earlier while the properties belonging to PurchaseRequest class can be referenced without any prefix.
388
Association:
We can also use associations to join multiple classes. PRPC comes with standard associations to
connect commonly used classes like Assignment- Case and Case History tables.
This is an example of a standard association rule that comes with PRPC to associate workbaskets and
cases.
In the report definition rule, we can access the association by entering some part of the text of the
association such as Assignment which gives us access to the properties in the class. The association
gets automatically referenced in the data access tab once we add a column. If we need to associate other
tables, define the association rule and then reference it as shownbelow.
389
Optimization of Properties
As we learned earlier, PRPC uses a specialized BLOB structure to save property values. To run reports
we can query against this BLOB, however if the dataset involves thousands of records there is going to
be an impact on the BLOB processing time.
To avoid this, PRPC allows optimization of properties for all the standard properties such as work status,
creation date and time, and creation operator, which are exposed by the product.
How do we decide which properties we should optimize? We can add unoptimized properties to appear
as columns in a report definition or in filter criteria, however the system displays a warning. PRPC by
default restricts adding the unoptimized properties in the Report Editor because it impacts the application
performance. But, we can enable a flag in the report definition so that the unoptimized properties can also
be added to the Report Editor.
Optimization can be done easily by running the Optimization wizard which is accessible by right clicking
on a property in the Application Explorer.
PRPC supports varied data structures - single level, page and page list or group.
When optimizing a single level or a page property the Optimization wizard does the following:
1. Tags the Required property flag in the property rule form to indicate its optimized.
2. Creates a new column in the same table.
3. Runs a query that takes all the values from existing cases and populates this column.
When we use a page list, we cannot create a column since we are not sure how many rows we are going
to need. For example in the Purchase request P-1 we will have two items and in purchase request P-3,
we may have 4 items. To do this PRPC creates an indexed table. When optimizing a page list, the
property wizard creates the following:
1. A declarative index class.
2. A set of all indexed properties in the declarative index class.
3. A declarative index rule that maps the properties in the declarative index class to the
corresponding properties in the main class.
4. A database table that corresponds to the declarative index class.
5. Database columns for all of the indexed properties in this table.
6. A query to populate this table with data taken from existing cases.
So in the example above P-1, will have two entries in the indexed database table and P-3 will have four
entries in the indexed database table.
The primary objective of the declarative index is to support reporting on page list properties. After the
declarative index is created, the report is usually written in the declarative index class to display the entire
list. This report is then added as a drilldown report in the other reports that are defined for the case. So
when we run the case it displays the report and we can drill down into it to see the page list.
390
Conclusion
Understanding the data model and knowing where to find the class mapping, the key standard properties
that are mostly used in reporting helps us to design reports to suit the business requirements.
Reports in PRPC are usually created to see the data saved as part of the Case, information on
Assignments or learning about how things are processed using the Audit Trail. Associating classes
enables us to get data from various database tables and displays that information in one report.
Optimizing properties and creating declarative indexes when optimizing a page list property enables us to
improve the BLOB processing time.
391
Data Visualization using Charts

Introduction
There is a popular adage: A Picture is worth a thousand words. Pictures make it easier to absorb a lot of
data faster than browsing through the report results. For example, the CMO (Chief Marketing Officer)
wants to see the quarterly sales made by various departments. Its faster to comprehend data presented
in the form of a bar or a pie chart as opposed to the report that displays numbers that pertain to various
departments.
PRPC supports different types of charts. These can be added to or changed to a different chart with just a
few clicks and does not require any coding effort. In this lesson we will learn how charts can be
configured on a summary type report in both the report definition rule form and report editor.
In this day and age, with companies being located in various geographical areas, it becomes invaluable
for the CMO to look at reports that give them information on orders by continent, country, and regions.
PRPC supports a wide variety of map charts and they are very easy to configure. The product also ships
maps that display countries by continent, states by country, etc.
Charts are added on summary type reports, and these summary type reports also include drilldown
reports. Drilldown reports access another report definition rule, so when users click on a row/group it drills
down to present the results of the drilldown report. By default PRPC uses pyDefaultReport as the
drilldown report rule, however we can configure the summary type reports to use a different drilldown
report.
For example, the map report displays a chart that shows the sales made by various countries in the North
America continent. Furthermore we can drilldown on a specific country, say USA to see the sales made
by various states within USA. The drilldown report can either be a line type or summary type report and, if
its the latter, we can add another chart. Using this approach we can drill down to any number of levels.
Create a summary type report
Create a chart and configure its settings
Create a map chart and configure its settings
392
Data Visualization
Introduction
Most of this lesson is on charts. The chart capabilities have been enhanced tremendously in Pega 7.
However, well also have a look at the new property security feature for reports. Choosing which chart to
use depends on what message to convey. A confusing chart, or one that directs attention away from the
important information in the report, can be worse than no chart at all. The three charts all draw on the
same data. And we have to use our knowledge of the message and our audience to decide whether one
of these or some other chart, would be the one to use. Experiment with charts for your report until you
find the chart type that best conveys the reports information. Then adjust colors, labels, and other
settings until the resulting chart is both pleasing and compelling.
When reading a chart we can zoom in and out to see the big picture or critical section of the chart. We
can also drill down to see the specific data contributing to a particular point, column, or area of the chart.
It is possible to change the filter conditions for the report. Charts can be shown in 2D or 3D. Report
Definitions generate list and summary type reports. Only summary-type reports can include charts. A
summary-type report has at least one column with a numeric aggregate value, such as count, total, or
average and at least one unaggregated group-by column such as status, day/month when the items were
created or as in this case work type.
Work with charts in reports

Lets have a look at how we can configure a chart for a summary-type report from the Report Browser.
The Report Browser can be accessed from the Designer Studio menu > Reporting > Access > Report
Browser landing page. The Report Browser can also be accessed from the Case Manager 7 portal.
Clicking Edit Report opens it in the Report Editor. By default the Report Editor shows simulated data to
speed up rendering time to allow us to concentrate on the look of the report and its chart. Click Actual
Data to switch off simulation and view actual report data.
Click Edit Chart to open the Chart Editor for the report. The Chart Editor is also available on the Chart tab
on the Report Definition rule form. The Chart Editor allows us to create and edit charts for summary-type
reports. We can choose from 12 chart types, most with several sub types.
Pega 7 provides hundreds of maps to use in displaying report data. Combo charts let us combine a
column chart and a line chart in a single display. Area displays data values as lines with the area between
them and the X-axis shown as colored regions. Use funnel to display values for an ordered set of steps or
stages in a process. Normally the first step is represented by the largest part of the funnel. Pyramid is like
a funnel chart, but with the step or stage with the largest value shown at the bottom. Bubble show three
sets of numeric column values in a single display. The X and Y axes represent two values and the
diameter of the bubbles represents the third. In a pie chart the values appear as slices in a pie. In a bar
chart the values appear as horizontal bars. In a column chart the values appear as vertical bars. In the
line chart the values of each data column appear as points on a line. Spark columns and spark lines are
micro charts, typically displaying trend information that we can embed within a layout cell. Gauges can be
very effective in displaying burn rate, throughput and other measurements of the current state.
We want to use a pie chart. The columns available are listed. Those already used in the chart are
indicated with check marks. A static picture of the selected chart type is shown. The drop zones
represent, depending on the chart, where and how report columns can be used within the chart. To
include a column in the chart we just need to drag it from the available columns list and drop it in the drop
zone. Use the data settings to specify formatting and other options. The available options depend on the
selected chart type and the type of data in the column.
Specify chart display settings

Lets have a look at how we can configure the display of the chart. To the right on the toolbar are a series
of links. We can provide a title for the chart. The font size and weight can be adjusted using the
dropdowns.
There are three color settings. The General Color settings option allows us to specify a background color.
The color can either be defined by entering a color code hex value or by using the color picker. The color
palette option allows us to define a set of colors that are applied to chart elements such as pie slices,
393
columns, etc. If there are fewer colors in the palette than the chart needs, the chart selects additional
colors from the standard palette.
Conditional Colors allow us to define colors that are conditionally applied to chart elements. The condition
can be based on either numeric values or Group By column values displayed on the chart. We can use
Threshold Colors to define colored lines or regions to display on the chart grid. For example, on a line or
column chart we can display a red line parallel to the x-axis or specify a range of values.
Use General Settings for additional options. Select Format Options to specify the default font size and
weight for all labels and the size of the chart.
Legend and slider options are also available under General settings. Select Enable User Commands to
specify commands available to end users when the chart displays. The commands available depend on
the selected chart type.
When a chart is added to a report it displays above the report data by default. To display just the chart,
open the Report Definition and select Hide summary data display on the Report Viewer tab.
Configure a map
Pega 7 includes hundreds of maps that we can use to illustrate the data in a Report Definition, allowing
report users to see graphically how data values are distributed and then compare across geographic
areas.
Map charts cant be defined in the Report Editor. They must be defined using the Charts tab on the
Report Definition. Lets have a look at how we can show the number of addresses per country in our
address data table using a map chart. We need to associate the data in the report with the regions in the
map, in this case the countries. We do that on the maps landing page found under Reporting > Settings >
Maps. By default the name of the country is used for the property value. If a country code is used instead
it can be mapped here.
We use the map World By Country for this report. The columns can be dragged directly into the chart. We
can define colors based on how many addresses a country has. It is possible to setup drill down maps so
that users can drill down from the world to a country view to see the same data by state or province in a
country.
Configure the drill down map on the Report Viewer tab. When providing drill-down from a map such as
the World By Country to another map on a drill down report, it is not possible to know in advance which
country a user may click. To solve this problem, we select a set of generic map types that refers not to a
single map, but rather to a set of maps that may be used.
When a user clicks a country to drill down on it, the map for the selected country is shown. This means
that we need to map all state maps for countries returned by the report.
Lets try it out.
394
Conclusion
Charts or graphs are useful when we want to illustrate the data in a way that is easier for business users
to interpret. Some reports like the sales across various geographical regions are better presented as a
map to highlight which regions performed well.
We learned about creating reports that can be configured to display the results in charts. When these
reports are run in the report browser, managers see a chart and the data is usually displayed below.
Another use of charts is that some of the trend or timeliness or productivity reports can be directly
embedded in the dashboard of a user portal. When the portal rule is created, we can include a chart
control which references the report definition rule. When charts are rendered in the dashboard, we always
recommend that the data that displays below the chart be disabled so users see only the chart.
395
Module 08: Integration
Introduction to Integration
Error Handling and Debugging
Configuring a SOAP Connector
Setup a SOAP Service
Setup a File Listener
Interacting with an External Database
396
Introduction to Integration
Introduction
Integration enables your application to interact with other systems, which is a common requirement in
most applications. A wide variety of integrations are supported in Pega 7.
This lesson covers the fundamentals of the integration processing model and how integration fits into the
application architecture.
Understand the Integration Capabilities
Invoke a Connector
Diagram the Connector Processing Model
Diagram the Service Processing Model
397
Understand the Integration Capabilities

As we begin looking at the integration capabilities, its important to distinguish between connectors
and services. If our application needs to respond to requests from external applications the
integration is known as a service. If our application needs to initiate the request by making a
connection to an external service, the integration is known as a connector.
A range of industry-standard protocols are supported.
398
Connectors are available to send the request to

BPEL,
Services are available to process the request from

BPEL,
CMIS,
COM,
.Net,
.Net,
EJB,
EJB,
File,
Email,
HTTP,
File,
Java,
HTTP,
JCA,
Java,
JMS,
JMS,
MQ,
JSR94,
REST,
MQ,
SAP,
Porlet,
SAPJCo (SAP Java Connector),
REST,
SOAP, and
SAP,
SQL applications.
SAPJCo,
SOAP applications.
399
Integration Wizards
The development of most integration is supported by wizards, which guides us through creating
connectors and services and dramatically accelerates development.
The connector wizards use metadata, such as a WSDL file, EJB class, or a data table definition to create
the connector and mapping rules.
Classes and properties used for mapping the request and response data are typically created as
well.
The service wizard lets us create a service for our application, allowing external systems to send a
request to our application.
The wizard creates service and deployment records as well as listeners if they are required for the
specific service.
400
Invoke a Connector
A connector is invoked either from a data page or an activity. If you call a connector from a flow you
can use the Integrator shape to reference the activity.
Use the connector with a data page if you want to fetch data from the service and with an activity if you
want to push data to the service.
Lets have a brief look at the configuration for a data page.
We can specify the type of connector to use as well as the request and response data transforms to map
the request and response. The data page can be used on its own or referenced by or copied to a
property.
401
If we use an activity we can explicitly call a connector. We use data transforms to map application data to
the request and from the response.
For example, lets assume we have an application in which we want to update a supplier, which is held in
an external system.
In this case we could use a data page with the connector for the GetSupplier service and configure a
property to copy the data from the data page.
We would then modify the data in the property and use an activity to invoke the connector for the
UpdateSupplier service to update the external system.
402
Configure Resource Settings

When we migrate an application from one server or environment to another, references to the external
systems that those applications connect to, such as endpoint URLs and JNDI servers might change.
Some of these references are in rules, which may belong to locked ruleset versions. To avoid having to
unlock and update rules, and to manually update these references after migrating, the Global Resource
Settings feature is often implemented.
Diagram the Connector Processing Model

Lets have a look at the rules involved in invoking a connector.
1. Before the connector is invoked from a data page or activity a data transform is used to
map data between our application and integration clipboard pages.
2. Then the connect rule is invoked. Connect rules are protocol specific and implement the
interface to the remote service. They specify the target service, and provide data
mapping configuration details for outbound and inbound content.
3. The service client is initialized based on the connect rule type.
4. The request data is mapped into the format required by this type of connector using the
mapping rules specified in the connect rule. Dont confuse this mapping with the data
transforms. This mapping is between the clipboard and the format required by this type
of connection.
5. The request is sent to the external system.
6. When the response is received, the response data is mapped using the mapping rules
specified in the connect rule.
7. The service client is finalized, and control returns to the data page or activity.
8. Finally a data transform is used to copy all or part of the response from the integration
clipboard data structure to our application.
403
Diagram the Service Processing Model

Lets have a look at the rules involved in processing a service request.
1. The service listener is responsible for sensing that an incoming request has arrived. This
functionality is sometimes provided by the underlying Web or Application Server, and
sometimes provided by a PRPC Listener.
2. The service listener receives the request and instantiates the Service API to provide
communication with PRPC. Then, via the Service API, control is handed to PRPC.
3. PRPC looks up the service package and related service rule, using the access group that is
specified in the service package.
4. It then establishes the service requestor, and optionally performs authentication based on
security credentials that are passed in the request. Once authenticated, service processing
continues using the authenticated users access group, not the access group that is
contained in the service package.
5. The request is mapped onto the clipboard according to the specifications contained in the
service rule.
6. Control is passed to the service activity, which provides the logic for the service.
7. When your service activity completes, control is returned to the Service API.
8. The service rule maps the clipboard data to form the response data.
9. The Service API then cleans up the requestor that it previously created, and returns control to
the service listener.
10. Finally, the service listener sends the response.
Lets take a closer look at the records that are involved in a service, working backward from the business
logic.
The service activity is the primary activity that is executed by the service. It contains the business logic
with the request as input and creates the Clipboard structure that represents the response.
The service rule is the first step toward exposing our service activity as a service. It specifies the service
activity, defines the external API of our service (the signature that external applications use to
communicate with this service), and specifies the data mapping for the request and response.
404
The service package is data, not a rule. It specifies the access group for locating the service rule, plus
provides service requestor authentication, pooling and deployment options.
The job of the service listener is to sense when a request has arrived. In many Integration Types, this
functionality is provided by the underlying Web or Application Server.
In those Types where this is not provided, PRPC provides Listener data classes that allow us to specify
the details about listener initialization.
The data instances should be associated with our applications ruleset since it is our application that
provides the service. There are no special considerations with regards to the enterprise class structure
when creating a service. Note that it is a best practice to use authentication.
Conclusion
Understanding the integration model and capabilities is necessary when integrating an application into an
existing system landscape.
Now, you should have an understanding of the integration capabilities. You should also understand the
processing model for connectors and services. Finally, you should know when to use a data page vs
activity to invoke a connector.
405
Error Handling and Debugging

Introduction
There are techniques that allow an application to detect and possibly recover from errors when interacting
with another system. These techniques vary depending on the role of the application in the integration.
This lesson covers the fundamentals of error handling and debugging for both service and connector
integrations and describes how to simulate connectors.
Understand Error Handling in Connectors
Simulate a Connector
Understand Error Handling in Services
Debug Connectors and Services
406
Understand Error Handling in Connectors

It is important that we understand the types of errors that can occur when integrating with other
applications or systems so that we can quickly identify and fix the error.
There are two basic types of errors that can occur when integrating through a connector:
Transient
Permanent
Transient errors typically dont last very long and correct themselves over time. For example, consider a
situation where the remote host of the application or system the connector is accessing is restarted or
temporarily unavailable.
Permanent errors can also occur. These errors are typically due to a configuration error or an error in the
remote application logic. For example, consider a situation in which an invalid SOAP request is sent to a
SOAP service. In this case, the error persists until the SOAP request message is fixed.
Depending on how the connector is invoked there are different mechanisms for determining if there has
been an error. Each of these mechanisms is described below.
1. If the connector is invoked from a data page we can use the Post Load Processing Activity
to check for and handle errors.
2. If an error occurs while loading the data page a message is added. Check for messages
in the Post Loading Processing Activity and handle the error.
407
3. If the connector is invoked from an activity, use the Transition Step Status to check if the
connector failed and if so handle the error.
In addition to checking and fixing the errors directly after the connector is invoked it is also possible to use
the Error Handling Flow feature available for most connectors.
Note that the Error Handling Flow is not executed if the error was handled in a transition in the activity or
if the connector is invoked from a data page.
The Error Handler Flow feature is enabled by default and is triggered if the exception is not caught
elsewhere.
408
Unless we specify a different flow, the standard flow Work-.ConnectionProblem is used.

Lets walk through the ConnectionProblem flow to understand its behavior.
409
If the exception is a resource unavailable exception, the case is automatically assigned to a

workbasket named IncompleteConnections.
The RetryConnection Service Level Agreement (SLA) goes into effect. It tries the connector again from
the original flow for a maximum of five times: one at goal event, one at the deadline event and then three
times at passed deadline.
Based on the RetryConnection activity, if the connector succeeds during any of those five attempts, the
ConnectionProblem flow assignment is cancelled, the ConnectionProblem flow ends and the original flow
resumes.
However, if the connector fails during any of those five attempts for the same reason, meaning with the
same resource unavailable exception, the assignment is kept in the workbasket so the next SLA event
can retry it again.
The SLA stops trying after the fifth unsuccessful attempt. In that case, the assignment stays in the
IncompleteConnections workbasket until a user or system administrator either restarts the flow or cancels
the assignment.
The other path in the standard ConnectionProblem handles the situation when a different exception other
than the resource unavailable exception is returned by the connector. In that case, the
ConnectionProblem flow spins off the FlowProblems flow and ends.
If a new exception is thrown while retrying from the previous attempts with the resource unavailable
exception, the assignment in the IncompleteConnections workbasket is reassigned to the FlowProblems
flow.
The FlowProblems flow, depending on its parameters settings, can either route the work item to a
problem flow workbasket or notify an operator about the issue. From there, the step that causes the issue
can be retried, or the initial flow can just resume, or the initial flow is restarted from the beginning or the
assignment is simply cancelled.
Of course, we can also create a new flow for handling connector errors or customize the standard
ConnectionProblem flow by creating our own version of it or any of its parts to meet our needs.
410
Simulate a Connector
Connector simulations are very useful in situations where the data source is not available or when one
wants to dictate the response returned. Connector simulators can be setup for most connector types.
The Integration landing page (DesignerStudio > Integration) gives us an overview of the available
connectors and their simulators.
The landing page shows for which connector types simulations are available and if it is active. Connector
simulations can be temporarily enabled and disabled from the landing page using the Enable/Disable
Simulations button. It is also possible to permanently disable all active simulators in one easy step using
the Clear Simulations button. Note that SQL connectors cannot be simulated and that there are no
connector simulations available out-of-the-box.
The connector simulator configuration can be accessed directly from the landing page by clicking the X
Simulations link or from the Simulations button on the connector rule.
411
Simulation activities can be defined on a global or user session level. If global is selected the connector is
simulated for all users on the system. If user is selected the connector is simulated for the current user
only.
It is possible to define several simulation activities for each connector, but only one can be active per
level. Hence, a connector can have one simulation activity active as a global simulation and another one
active for the user session. In such a case the user session simulation overrides the global simulation.
If were using our connector with a data page we have the option to simulate the data source instead of
the connector.
412
Lets have a look at the connector simulation activity for the SOAP connector called GetSupplier.
Place the connector simulation activity in the same class as the connector it simulates. It is worth
considering placing the connector simulation activities in a separate RuleSet, which is not moved to the
production system.
The step page in the connector simulation activity is the service page of the connector it simulates so it is
easy to set response properties. Note that the properties are set directly on the service page and the
stream and parse rules that some connector types have defined on the service page are not used in
simulation mode.
We can use pre-conditions to return different responses based on things such as values in the request.
413
Understand Error Handling in Services

It is critical to catch errors and exceptions during execution of a service rule so that they can be
communicated to the client application in a clean way. It is a best practice to configure clipboard property
values to communicate service errors to the calling application.
Many service types have an exceptions or faults tab. Service SOAP, for example, provides a Faults tab.
Other service types allow a service error condition to be defined on the Response tab.
When the service encounters a processing error and a condition evaluates to true an error message as
defined is returned to the calling application. The following options are available for defining an error
response message.
When Specified When rule returns true.
Queue When If the specified When rule returns true the request is queued and a PRPCspecific SOAP fault that includes the queue ID of the request is returned. Asynchronous
processing is covered in another lesson.
Mapping Error Error occurs while mapping incoming data from the request message to the
clipboard.
Security Error Authentication fails.
Service Error Valid instance of the service activity cannot be found.
If the mapping, security, and service errors are not defined the system returns standard exceptions.
414
Debug Connectors and Services

There are several debugging and system monitoring tools with integration features which are helpful in
testing integration projects. There are also tools that are specific to a certain type of integration; we will
talk about those in the relevant lesson. In this lesson we will review the integration features of the Tracer,
Clipboard, and the log files.
Tracer
We can use the Tracer to capture session information about the connectors actions from the moment the
session starts. The Tracer can monitor any active requestor session. When using it for a connector, we
start it for our requestor session before running the connector activity.
A Service, however, runs in a new requestor session and the processing is usually so quick that it can be
hard to catch the event to trace it. Therefore, the Trace option available in the Run menu is more
convenient to trace service rules. Using this option we can trace a specific rule. This Trace option can be
used when unit testing the service using the Run option in the Actions menu and to trace real service
requests invoked from an external client application.
In the Tracer, we can use the following options when tracing services.
The services option adds steps when the service invocation begins and ends. Nested within
those steps are entries that show when the inbound and outbound data mapping begins and
ends.
The parse rules option adds steps when the parse rules begin and end their processing.
The stream rules option indicates when HTML and XML stream rules begin and end their
processing.
Clipboard
We can use the Clipboard tool to examine property values and messages associated with them.
For connectors, it is easy to examine the clipboard since connectors typically run in our requestor context.
You can create or select a work item, move it through the flow and examine the Clipboard before the
connector is invoked and after it obtains a response.
The session data of a service requestor is also accessible on the Clipboard. However, because the
duration of a service request is so short, it is nearly impossible to examine the Clipboard if it is invoked
externally and therefore not run in our requestor context. To see the Clipboard of a service rule, we must
invoke the service using the Run option in the Actions menu.
Log File
A message is written to the Alert Log file when some processing events exceed their threshold. Alert
messages are available for both services and connectors.
During a service execution, the following operations can contribute to a long transaction time:
Inbound data mapping
Outbound data mapping
Data parsing
Service activity execution
If one of those time thresholds is exceeded, a PEGA0011 alert message is reported in the alert log.
Similarly, a PEGA0020 alert message is reported when a connector call to an external system has
exceeded an elapsed time threshold.
Beside the Alert Log, we have the Pega Log in which system errors, exceptions, debug statements are
gathered. While testing our integration interactions, we can increase log level settings, add more loggers
415
and then examine the results in the log file. Use the DesignerStudio > System > Tools > Logs > Logging
Level Settings landing page to update the log level settings.
For connectors, we need to set a logging level for the Invoke activity.
Below is a list of Java classes with their matching service types. We can set logging levels for the classes
appropriate for the service we are testing.
Service Type
Classes
All
com.pega.pegarules.services
SOAP or .Net
com.pega.pegarules.services.soap.SOAPService
com.pega.pegarules.services.soap.SOAPResponseHandler
com.pega.pegarules.services.soap.SOAPUtils
EJB
com.pega.pegarules.services.jsr94
Java
com.pega.pegarules.services.jsr94
JMS
com.pega.pegarules.services.JMSListener
MQ
com.pega.pegarules.services.MQListener
File
com.pega.pegarules.services.file
Email
com.pega.pegarules.services.EmailListener
Conclusion
It is very important to make time to think through the error handling approach for your integration projects.
Your application will never be robust if you neglect this part.
Now, you should understand the options for error handling for both services and connectors. You should
also be able to debug and unit test a connector and service. Finally, you should now know how to
simulate connectors.
Keep in mind that some integrations have specific error handling, which we will cover in other lessons.
416
Configuring a SOAP Connector

Introduction
This lesson describes how to create a SOAP connector using the Create a SOAP Connector wizard and
then examines the records created by the wizard.
Use the Create a SOAP Connector Wizard
Understand the Records Generated
417
Use the Create a SOAP Connector Wizard

The SOAP Connector wizard is new in Pega 7 and it simplifies the process of integrating with SOAP
services. The wizard walks us through the process of gathering the details of the service and defining a
data model from a WSDL. The wizard then creates the records needed to interact with an external SOAP
service. In this particular example we want to integrate with a supplier service.
From the Designer Studio menu select Integration > Connectors > Create SOAP Integration to start the
wizard. A SOAP integration requires a WSDL that describes the remote service.
We can provide a URL indicating where the WSDL is hosted. The system prompts us for credentials if the
server hosting the WSDL requires authentication.
Alternatively we can upload the WSDL as a file. Many WSDLs do not stand alone, but reference other
WSDLs or schemas defining shared data models. The wizard only allows a single file so WSDLs that
dont stand alone cannot be uploaded as a file, but needs to be referenced via an URL.
Next we have to select the operations that we want to be able to call in our application.
If the service requires authentication click the Edit Authentication link to configure it. It is possible to
configure a single Authentication Profile for the service or different profiles for each selected operation.
418
We can specify an existing profile or provide the required information such as authentication scheme,
user name, and password to have an Authentication Profile generated by the wizard.
You can use the Test button if you want to test the connection for an operation.
Click Next to display the Final screen where we can configure several key components.
In the Integration field, enter the name of this integration service. The short name is a unique identifier
and defaults into the Description field. It is also used in the class, RuleSet, and authentication profile
names created.
The Reuse Layer determines where this connector can be reused.
Global Integrations indicates that the integration can be used across organizations and
applications.
Implementation Integration Class indicates that the integration can be used within this
application only.
Organization Integration Class indicates that the integration can be reused across applications
within the organization.
If implementation or organization integration is selected we can either create a new RuleSet for this
integration above the reuse layer or use the integration RuleSet of the reuse layer.
The setting we use for the reuse layer determines the base class and ruleset in which the connector rules
created.
419
Reuse Layer
Baseclass
RuleSet
Option
Connector RuleSet
RuleSet
Prerequisite
Implementation
Org-App-IntSupplier
New
SupplierIntegration
AppInt
Reuse Layer
AppInt
OrgInt
New
SupplierIntegration
OrgInt
Reuse Layer
OrgInt
Base Pega RuleSet
N/A
SupplierIntegration
OrgInt has
SupplierIntegration
as a prerequisite
Organization
Global
Org-Int-Supplier
Int-Supplier
If the integration already exists at the reuse layer the message This integration already exists at the
reuse layer specified. If you proceed the integrations will be merged appears and proceeding creates a
new RuleSet version of the integration RuleSet.
Click Preview to view a summary of records the wizard will create for this integration.
Click Create to create the integration. Depending on what RuleSet options we selected and the security
settings in use for the application and its rulesets, a password (or passwords) may be required to
proceed.
We can use the Undo Generation button to remove the records generated.
Select DesignerStudio > Application > Tools > All Wizards to see a list of all wizards. This allows us to
complete a wizard in progress or undo generation of a completed wizard.
420
Handle WSDL Changes

If we need to make changes to the WSDL once it has been created, we can re-run the wizard. The wizard
then creates a new RuleSet version of the integration RuleSet and creates new and updated rules in that
RuleSet version.
Updating Connectors Generated Prior to Pega 7

Prior to Pega 7 the Connector and Metadata Accelerator was used to create a SOAP connector. If our
application uses connectors generated prior to Pega 7 we cannot use the new wizard to update those
interfaces if they change. This is because of changes to how the base class name is constructed and the
way value lists were utilized prior to Pega 7. For such cases the old wizard is still available under
DesignerStudio > Integration > Connectors > Create Other Integration.
Understand the Records Generated

The SOAP connector wizard we just used created the following rules.
Classes and properties representing the request and response data
Connect SOAP rule
XML Stream and Parse XML rules for request and response mapping
In addition to the above rules, an Authentication Profile record is created if we configured it in the wizard.
Classes and Properties

Classes and properties are created to hold the request and response parameters.
421
Below the base class, which is named after the integration (Int-Supplier in this case) there is another
class with the same name holding the request and response properties for the operations in the service
as well as the connect and mapping rules.
In this particular WSDL the requests and responses were all modelled as named complex types and are
represented as classes with the complex type name being the class names.
422
Connect SOAP
Lets have a look at the Connect SOAP rule.
The Service Tab
Most of the fields on the service tab were populated from the WSDL file.
If the operation requires authentication and it was configured in the wizard an Authentication Profile will
be referenced in the Authentication section.
The Service Endpoint URL (shown in the Connection section) varies depending on the connectors
environment (development, QA, or production). The Global Resource Settings feature allows us to specify
the endpoint URL with a system variable, rather than using a rule that may be maintained in a locked
ruleset.
The wizard defaults the response timeout to 120,000 milliseconds. This means that a connection attempt
will wait up to 2 minutes before timing out with a failure message. Typically we are going to want to adjust
this to a much lower value, depending on the SLA of the service. In particular, if this service is invoked as
part of a users interactive session, this value should be reduced to a few seconds.
The error handling properties hold status and exception information returned by the connector and the
processing options are advanced settings that allow us to setup the connector to operate asynchronously.
423
The Request tab
Entries in the request headers specify any data that needs to be included in the SOAP envelope header.
Entries in the request parameters specify the data that will be mapped into the body of the SOAP request
message. In this particular case the body is mapped using an XML stream rule.
The Response Tab
We use the target property if we want to store the entire original SOAP response with the case. This
might be useful or required for auditing or history purposes.
Response header entries are used to map the incoming SOAP envelope header.
The response parameters allow us to specify how to map the data from the body of the reply message to
Clipboard properties. In this particular case the body is mapped using an XML parse rule.
424
The Faults Tab
A SOAP fault is an error in a SOAP communication resulting from an incorrect message format, headerprocessing problems, or incompatibility between applications. When a SOAP fault occurs, a special
message is generated that contains data indicating where the error originated and what caused it. The
properties on the faults tab allows us to map the faults details returned and handle the error appropriately.
425
The Advanced Tab
The SOAP connector architecture uses an Axis client to make SOAP calls and process the response. The
client properties allow us to specify settings for the Axis client.
If the connector requires security we can configure it on the Advanced tab.
Compensating actions are intended for use when the connector succeeds, but a subsequent step in the
process determines that the action of the connector should be reversed. Typically the compensating
action sends a message to the external system by executing another connector that un-does the action of
the original connector. Compensating actions are not intended to help recover from system failures.
426
XML Stream
The XML stream rule maps data from the Clipboard to the SOAP request.
The Mapping Tab
Here, we map the supplier to the update supplier service request as we can see in the tree structure.
The XML Tab
The XML tab defines how the properties will be mapped into the XML message structure.
427
Parse XML
The XML parse rule maps the response to the Clipboard.
Mapping Tab
Here, the list of suppliers is mapped from the get supplier list service response.
Conclusion
The Create a SOAP Integration wizard walks you through the process of integrating with an external
SOAP service accelerating the development considerably.
Now, we can use SOAP Integration wizard to create a SOAP connector. We also understand the options
available and the effect they have on the
428
Setup a SOAP Service

Introduction
This lesson describes how to create a SOAP service using the Service Wizard and then explains the
records created by the wizard.
Use the Service Wizard for SOAP
Configure SOAP Service Records
Test the SOAP Service
Lets start by reviewing the requirement for our service. We want to create a service that returns the
details of a purchase request with a given ID.
The information returned for each purchase request should include:
Requestor
Date
Line items
Status
Total Amount
In addition, we have the following non-functional requirements:
Return a SOAP fault if the purchase request could not be found
Use of authentication
429
Create a SOAP Service using the Service Wizard

The Service Wizard walks us through the process of gathering the details of the service to be created.
From the Designer Studio menu select Integration > Service > Service Wizard to start the wizard.
In the first screen the wizard asks us about the purpose of the service. A service always requires an
activity, which provides the logic for the service. The service purpose defines the activity. There are three
options:
Create and manage work
Invoke existing activity rule
Process input and output data
Choose Create and manage work to use the service to create a new case and perform one or more
processing action(s) upon it. When selecting this option, the wizard generates two activities for use by the
service.
svcAddWorkObject, which creates the case and starts the specified flow. This is the standard
service activity for services that create new cases.
svcPerformFlowAction, which identifies the case and then calls the specified flow action. This is
the standard service activity for services that perform a flow action on a case.
Select Invoke existing activity rules to use an existing activity to manipulate an existing case.
Select Process input and output data to map data to or from the clipboard, such as to update the
contents of a data table. The wizard creates the service rule and a new empty activity. This activity can be
configured to use the mapped input data to perform an action, and to populate the clipboard properties to
be returned in the mapped output fields..
This lesson focuses on creating a service to invoke an existing activity rule. Information on the remaining
options can be found on the PDN.
Next we need to specify the activity class.
430
In our case the class is the purchase request case type. Next we need to select the activity to use.
If the activity has parameters those can be used as inputs or outputs to the service by selecting them on
the next screen.
Our activity has no parameters so there is nothing to do.
In the next step the input and output properties for the service are defined based on the properties
available in the service class.
431
In our case we want to take the purchase request ID as an input parameter and return the line items and
total price.
Only properties defined directly in the class (i.e. not inherited ones) are shown. We need take care of
inherited properties outside the wizard.
Our input parameter the purchase request ID is inherited so it is not shown.
In many cases, we can use the clipboard to map data between our application and the other system. If we
want to include a more complex structure, such as a repeating list, in the input or output we need to use
XML for data mapping. In our case we want the line items in the response so we need to use XML for
data mapping. Some of the properties in the response are not inherited so we select those..
Next we need to select ruleset and service package.
Typically we want to create the service rules in the application ruleset. The service package defines the
deployment of the service. A service package typically represents a WSDL and all services belonging to
the service package will show up as operations in the WSDL.
If we select to create a new service package we need to provide details in the next step. The wizard
provides us with a default name.
432
It is a best practice to have a dedicated access group for services, which has minimum privileges required
to run the service activities. If our application has services that have individual security policies, we may
have multiple service packages and access groups.
Select requires authentication to authenticate the service client at runtime. If this option is selected the
client needs to provide a valid operator and password when calling the service.
Selecting Suppress Show-HTML causes the system to skip over any activity step that calls the ShowHTML method in the service activities that execute through service rules that reference this service
package instance. This feature lets us reuse or share an activity that supports both interactive users and
services.
The last step provides an overview of the rules to be created.
Click Finish to create the records.
In the final screen the created records are listed and the WSDL URL provided.
433
The following records were created:
SOAP Service
XML Stream for the response
Service Package
434
Understand the Service Records

Lets have a look at the records involved in a service starting with the Service SOAP rule.
The service tab defines the service page and activity for this service. The primary page holds the data
mapped to the request and response. Optionally you can specify a data transform that is applied
immediately after it creates the page. The service activity provides the processing for the service. Lets
have a look at the activity.
In our case the activity takes the input parameter (purchase request ID) from the service page and loads
the corresponding purchase request directly into the service page. However, the service activity could
create a case or perform a flow action on an existing case or do just about anything.
The request tab contains the mapping configuration for the request message.
435
We can see that the pyID property is mapped directly from the service page. We needed to add the
request parameter manually since pyID as an inherited property didnt show up in the wizard. If we had
selected use XML data mapping for the request in the wizard an XML parse rule would have been
created and configured here.
The response tab contains the mapping configuration for the response message.
The response is mapped from the service page with a XML stream rule since we selected use XML for
data mapping in the wizard. Lets have a look at it.
436
In addition to the properties mapped we also wanted to map the requestor (pxCreateOperator) and the
date (pxCreateDateTime) of the purchase request. These properties didnt show up in the wizard because
they are inherited. We also want to rename the pyID element ID and the LineItems element LineItem
since the element itself represents a single line item.
This is how the XML stream rule looks after weve made our changes.
The fault tab allows us to configure when to return a SOAP fault.
437
We want to return a SOAP fault if the purchase request with the given ID isnt found. We assume that if
the pxCreateOperator isnt available the purchase request wasnt found and that was because the ID
given was invalid. In a real-world application, we would want to provide additional error-handling details.
Finally, lets have a look at the service package.
438
The context and pooling tabs are populated from the information we provided in the wizard. The methods
tab specifies the service type and lists the methods part of the service package.
Use the deployment tab to get the WSDL.
439
Select the service class of interest and click the deployment tab. Typically there is only one service class
per service package. However, it can be several making it possible to have several WSDLs for a single
service package.
If the check-out feature is used we need to ensure that all rules related to the service is checked in before
using the deployment tab since rules in private rulesets are ignored.
440
Test the SOAP Service

We can use the Run in the Actions menu on the service rule to test our service. Select Run and we get a
pop-up that allows us to enter various input parameters.
Our initial test should use the Use current requestor context option to test the service activity and
mapping rules.
We have the option of entering the purchase request ID for our request as either an individual value, or
entering it directly into the SOAP request envelope.
441
Enter a valid purchase request ID, and click execute. We see that the overall result for first test was a
success.
We can see that the response is the purchase request for the given ID.
Now let's test what happens if we give an invalid purchase request ID.
442
A SOAP fault is returned, just as expected. Our service activity, mapping rules, and error handling seem
to be working well.
When using the current requestor context some processing steps are not attempted:
Lookup Service Properties
Initialize Requestor
Perform Authentication
In order to fully test our service, we want to include the above. Select Initialize service requester
context, and enter the user ID and password that were going to use to authenticate.
The final test is to invoke the service from an external application.
Conclusion
The Service Wizard walks you through the process of creating a service, accelerating the development
considerably. In this lesson we used it to create a SOAP service.
Now, we can use the Service Wizard to create a SOAP service. We understand the options available and
the effect they have on the records created. We also understand the records generated so that we can
tune the configuration.
443
Setup a File Service and Listener

Introduction
This lesson describes how to create a File Service using the Service Wizard. A File Service defines a
package of records used for importing the content of character-based files.
Use the Service Wizard for File
Configure a File Service
Start and Stop a File Service
Test a File Service
Lets start by reviewing the requirement for our service. In our purchasing application there is a data table
with suppliers. We want to create a file service that takes a CSV (comma separated value) file with
supplier information and updates the table.
Each row in the CSV file contains the following information:
ID
Supplier Name
Contact Name
Contact Title
Address
City
Region
Postal Code
Country
Phone
Invalid entries should be ignored.
444
Use a Listener to Trigger a Service

Each service that we configure requires a trigger of some sort. This trigger invokes the service, causing it
to process the inbound request.
For a basic SOAP service, the server reacts to the incoming request automatically, performing the actions
outlined by the service. In other cases, however, we not only need to configure the service, but also need
to configure the triggering mechanism, known as a listener. Listeners allow us to configure services that
respond to emails or file uploads, for example. The listener operates in the background, watching a
specific location such as an email address or a folder on the server. When the listener observes activity
(1) at the location a new email arrives or a file is uploaded, for example the system triggers the
appropriate service to process the inbound request (2). The service then writes data to the corresponding
case or data record (3) and can return some of that case data to the originator (4).
In this lesson, we discuss how to configure a file listener and service. Though the configuration
information is valid only for file listeners and services, we can apply the general concepts to any
listener/service combination.
445
Create a File Service using the Service Wizard

The Service Wizard walks us through the process of gathering the details of the service to be created.
From the Designer Studio menu select Integration > Service > Service Wizard to start the wizard.
In the first screen the wizard asks us about the purpose of the service. A service always requires an
activity, which provides the logic for the service. The service purpose defines the activity. There are three
options:
Create and manage work
Invoke existing activity rules
Process input and output data
Choose Create and manage work to use the service to create a new case and perform some processing
action(s) upon it. When selecting this option, the wizard generates two activities for use by the service.
svcAddWorkObject, which creates the case and starts the specified flow. This is the standard
service activity for services that create new cases.
svcPerformFlowAction, which identifies the case and then calls the specified flow action. This is
the standard service activity for services that perform a flow action on a case.
If you already have an activity you want to use to manipulate an existing case, select Invoke existing
activity rules.
Select Process input and output data to map data to or from the clipboard, such as to update the
contents of a data table. The wizard creates the service rule and a new empty activity. This activity
can be configured to use the mapped input data to perform an action, and to populate the clipboard
properties to be returned in the mapped output fields.
In this case, we choose Process input and output data and set the service type to File, so we need to
specify the class and the name of the service.
446
In our case we specify the supplier class of the data table and we name the service UpdateSupplier.
In the next step the input and output properties for the service are defined based on the properties
available in the service class.
In our case we want to use a parse delimiter rule, which cant be configured in the wizard so we need to
manually configure that after the wizard is complete. The wizard requires that at least one input and one
output property is selected so we need to select something.
Next we need to select ruleset and service package.
447
Typically we want to create the service rules in the application ruleset. If we select Configure a new
service package and/or Configure a new file listener, we need to provide details in the next step.
The wizard provides us with a default name. It is a best practice to have a dedicated access group for
services, which has minimum privileges required to run the service activities. If our application has
services that have individual security policies, we may have multiple service packages and access
groups.
Enable the Requires Authentication option to authenticate the service client at runtime. If this option is
selected the client needs to provide a valid operator and password when calling the service.
448
Enabling the Suppress Show-HTML option causes the system to skip over any activity step that calls the
Show-HTML method in the service activities that execute through service rules that reference this service
package instance. This feature lets us reuse or share an activity that supports both interactive users and
services.
The Source Location field identifies the directory in which the listener looks for the input files. The
listener requires read and write access to this directory. Note that this field might change between
environments and supports the Global Resource Settings syntax.
The Source Name Mask field allows us to enter a mask used to select the files in the Source Location.
We can use an asterisk as a wildcard match. For example, *.CSV causes the system to process all files
with extension CSV. Note that case is significant in matching files on UNIX systems. If we leave this field
blank the listener selects every file in the directory identified in the Source Location.
The last step provides an overview of the rules to be created.
Click Finish to create the records.

In the final screen the created records are listed.
449
In this case, the following records were created:
File Service
Activity
Service Package
File Listener
450
Configure a File Service

A file service typically consists of the following components:
Service Activity, which is the primary activity that is executed by the service.
Parsing Rule, which parses the file content and creates the service clipboard page which is used
in the service activity.
Service File, which specifies the parsing rule and service activity.
Service Package, which specifies the access group as well as authentication and requestor
options.
A File Listener which encapsulates details about listener initialization and processing options.
The wizard created the service file, service package, file listener, and an empty activity for us. Lets have
a look at the records created by the wizard and how we can configure the file service to parse our CSV
file and update the suppliers.
Lets start by looking at our service activity.
Service Activity
In the service activity we open and lock the supplier with the given ID.
Then we set the values from the CSV file and save the supplier. If an error occurs when the supplier is
opened or saved the activity simply exits.
Parse Delimited
The service file rules support three types of parse rules:
Parse XML rules which are used for XML files.
Parse Delimited rules which are used when a comma, tab, quote, or other character separates
fields within each input record.
Parse Structured rules which are used to import fixed-format flat files
451
In our case we have a CSV file so we need to use a Parse Delimited rule.
The field format is set to comma-separated values (CSV) and the values in the record are mapped to
properties.
Service File
The service tab defines the service page and the activity for this service.
The service page holds the data mapped from the request. The processing options are used to configure
asynchronous processing, which can increase the throughput of the file service. In the advanced courses
there is a separate lesson describing the configuration of asynchronous file service.
The Method tab describes how the system detects fields and records in the input files.
452
There are three options for the processing method:
File at a time parses the entire file.
Record at a time parses a record at a time. Use the Record Terminator or Record Length fields
to identify the record.
By record type extracts a record type from the record. Use the Offset and Length fields to
identify the record type and the Record Terminator or Record Length to identify the record.
Specify the Data Mode and Character Encoding of the input file. This choice affects which methods can
be used in parsing the record.
The Request tab defines the processing and data mapping for each file or each record.
It is possible to specify an Initial Activity that is run before processing each input file and a Final activity
that is run after the entire file is processed.
How the information configured in the Parse Segments is used depends on the processing method
specified in the Methods tab.
453
The Record Type is used to identify which parse segment to apply to a record parsed from the
file. This option is only relevant if the processing method on the method tab is record type.
Select Once to apply the parse segment only once. This option is useful for files that contain a
header record.
The Map To field defines the action to take in the parse step. The following options are available:
o
Clipboard Map this segment to a Clipboard property
XML ParseRule Parse the segment with a parse XML rule
Delimited ParseRule Parse the segment with a parse delimited rule
Structured ParseRule Parse the segment with a parse structured rule
Skip Skip this segment
In our case we want to use a parse delimited rule. Enter the corresponding key for the Map To
field in the Map to Key field. In this case it is the name of the delimited rule we want to use.
If Auth? is selected the system uses two parameters pyServiceUser and pyServicePassword from
the parameter page as authentication credentials for a requestor. These two parameters can be
set in earlier rows in the parse segments.
Use the Activity field to specify an activity to run after the data is processed by this parse
segment. We want to update the supplier after each record in the file so we specify our service
activity here.
Select Keep Page? to cause the primary page of the activity to be retained after processing of
this row is complete. Clear to cause the primary page to be reinitialized after this row is
processed.
The Frequency field allows us to specify a number of records to process before committing database
changes. When this field is not blank, a final commit operation also occurs after all records are
processed. If this field is blank, no automatic commit operations are performed. In our case we want to
commit after every record so we set the frequency to 1.
Use the Success Criteria to specify a when rule to be evaluated after each record is processed. If this
rule evaluates to false a database rollback occurs backing out of the most recent commit operation and
the processing of the file is abandoned.
454
Service Package
The context and pooling tabs are populated from the information we provided in the wizard.
The methods tab specifies the service type and lists the methods part of the service package. Thats
where we can find our file service.
The Deployment tab is not relevant for file services.
File Listener
The Properties tab identifies where the listener is to run, where it looks for input files, and the Service File
rule.
455
The Startup Option allows us to control how listeners start:
Run on all nodes The listener is run on all nodes, in other words all servers in a cluster.
Node based startup The listener is started only on specified nodes.
Host based startup The listener is started on specified number of nodes on specific servers
within the cluster.
If node or host based startup is selected then additional fields appear for the configuration of the
node or the host name and node count.
The Reset Startup button deletes all instances from the class Log-Connect-AssignedNodes so that
listeners can be started.
The Source Location and Source Name Mask are populated from the wizard. The listener creates three
sub-directories within the source directory:
Work Original files are copied to the Work directory for recovery attempts
Completed Files for which processing completed successfully are copied here
Report Report files are copied here
The Concurrent Threads field allows us to specify the number of threads per server node this listener
requestor creates when it starts. Each thread operates on a single file, in other words multiple concurrent
threads have no benefit unless multiple files are available at the same time for processing.
Each file listener links to a single Service File rule. Service Package is the first key part, Service Class
is the second key part and Service Method is the third key part of the Service File rule.
We can use the Test Connectivity button to verify that the listener thread can be created on the current
node and access the device and directory.
The Requestor Login fields define the user name and password if the service package requires
requestors to be authenticated.
The Diagnostics section allows us to configure remote logging for this service file rule. For more
information on remote logging see the help topic called How to install and use remote logging.
Select Blocked in the Startup Status to prevent this listener from being started by any means. If cleared,
this listener starts with system startup, or can be started using the System Management Application.
The Process tab contains runtime configuration for this file listener.
456
The Polling Interval field defines the number of seconds this file listener waits before it checks for newly
arrived files.
Select Ignore duplicate file names? To prevent processing of a second or later file that has the same
name as a previously processed file. If a match is found it bypasses normal processing and copies it to
the work directory and saves it with .dub as the file extension.
Selecting Lock temporary file names? causes each file listener to lock the temporary files it creates to
avoid name collisions when multiple copies of the listener may be running. Select this only when
necessary as locking adds processing time that can affect performance.
If Generate report file? is selected the listener creates a report file in the source directory using the
content of the Source Property in the page specified in the Source Page Name. The name of the file is
the original file name suffixed with the Target File Extension defined.
Select Persist Log-Service-File instances? to save instances of the Log-Service-File class, which
record the processing of a listener, in the PegaRULES database for reporting and debugging.
The Idle Processing section lets us define an activity to be called after the processing of a file is
complete.
The File Operation field lets us decide what we want to happen to the file if it is successfully processed.
It can either be kept or deleted. Choosing keep moves it to the completed folder.
The Error tab defines what processing occurs at runtime when requestors based on this listener
encounter errors.
457
Some errors are technical and related to the infrastructure and hence might be temporary. It might be
worth trying to attempt to recover from such errors. If we select Attempt recovery? the system leaves the
files containing errors in the Work folder for recovery purposes.
Max Recovery Attempts defines the maximum number of times the system attempts recovery.
In the Cleanup section we can define what we want to happen to the file when an error occurs. It can
either be deleted or renamed. If you choose to have it renamed the file extension is renamed to the
specified value. The file name itself remains the same.
458
Start & Stop the File Listener

In addition to the startup options available in the File Listener record. The File Listener can be started and
stopped manually in the System Management Application, which is available under DesignerStudio >
System > Tools > System Management Application.
Lets select the node on which we want to start or stop the file listener and then select Listener
Management. Select the file listener in the drop-down.
Click Start to start the listener. We get a message that tells us that it was successfully started and we can
now see it in the list of running listeners.
Select the listener and click Stop to stop it.
459
Test a File Service

We can use the Run in the Actions menu on the service rule to test our service. Select Run and we get a
pop-up that allows us to enter the file content.
For our initial testing lets select Use current requestor context to test the service activity and mapping
rules.
We have the option of entering the file content in a text area or upload a file.
Enter valid file content, and click execute. We see that the overall result for our first test was successful.
When using the current requestor context some processing steps are not attempted:
Lookup Service Properties
Initialize Requestor
Perform Authentication
460
If the file service requires authentication we can provide the authentication details when using Run in the
Actions menu or provide the pyServiceUser and pyServicePassword parameters and select
authentication in the parse segments.
In order to fully test our service, we need to place a file in the directory configured.
Conclusion
We can use file services to read in and process the data in files. The data files may be exported from
another system, or created by users as text files in a wide variety of formats.
A file listener monitors the file directory and calls the file service when files arrive. The file service uses a
parse rule (XML, structured, or delimited) to open and read the file, evaluate each input record, divide the
records into fields, and then write the fields to the clipboard. The service activity can then process the
data.
Now, we can use the Service Wizard to create a file service. We understand the options available in the
wizard and the effect they have on the records created. We also understand how to use the additional
configuration options in the records created so that we can fine tune the configuration.
461
Interacting with an External Database

Introduction
There are two ways to integrate with an external database. The first is to use the Database Table Class
Mapping tool, which provides a wizard that generates all the artifacts needed to interact with an external
database. The other way is to use an SQL Connector to connect to the database allowing us to use more
advanced database features.
In this lesson we will look at each of these methods and discuss when which approach is most suitable.
Register an External Database
Describe how External Classes are used
Use the External Database Table Class Mapping gadget
Use the Obj-Methods
Configure Connect SQL Rules
Know when to use Obj-methods vs Connect SQL
462
Register an External Database

Each relational database we need to connect to must be defined as a Database instance. When the
Database instance has been created and a suitable JDBC library has been installed on the server we can
connect to and interact with that database. Database and Database Table instances can be found under
the SysAdmin category in the Record Explorer.
Lets have a look at the Database instance called ExternalDatabase.
There are three options we can use to connect:
Use configuration in preferences
Use JDBC Connection Pool
Use JDBC URL listed below.
A Database Table instance maps classes and class groups to relational database tables or views in a
database. Before creating a Database Table instance it is important to confirm that the table or view is
present in the database schema.
It is not necessary to create a Database Table instance for every concrete class. At runtime, the system
uses pattern inheritance and class groups to locate the appropriate Database Table instance for an
object. If none is found, it uses the table pr_other as default.
However, each class representing a table in an external table must have a Database Table instance.
463
Understand External Classes

An external class is a concrete class that corresponds to a table in an external relational database, rather
than to a table or view in the PegaRULES database.
External classes do not contain the two properties pzInsKey and pxObjClass, which are present in every
internal class. In some cases, no single property in the external class can serve as a unique handler. In
that case a substitute string is assembled from the key columns of the table.
The External Mapping tab on the class form is primarily used for external classes. Typically, this tab is
completed by the Connector and Metadata Wizard or the External Database Table Class Mapping
gadget.
Each external class has an associated database table instance and can therefore not be part of a class
group.
The Column Name is the name of a column in the external table. The Property Name is the name of the
property in the external class that represents the table column in the Column Name Field.
Declare expression, validate, and trigger rules do operate on Clipboard property values for external
classes.
464
Use the External Database Table Class Mapping Gadget

We can use the External Database Table Class Mapping tool (DesignerStudio > Data Model > Classes &
Properties > Database Class Mappings) landing page to create the records necessary for integrating with
an external table.
The external class generated can be used together with a data page and the lookup to fetch an instance
or with a report definition to fetch a list of instances. Alternatively, it can also be used in an activity with
the Obj-methods to open, save, and remove rows from the table.
465
Use the Obj-Methods

Use the Obj-methods in an activity to open, save, and remove instances from the database. The Objmethods can be used on instances of all classes and are not limited to external classes.
Use the Obj-Open or Obj-Open-By-Handle to load an instance.
Use the Obj-Refresh-and-Lock method if the page already is available on the clipboard and youre not
sure if it is current and a lock is held. If the object is locked Obj-Refresh-and-Lock has no effect. However,
if the object is not locked a lock is acquired and if the page is stale it is replaced with the most current
version.
Use Obj-Save to persist the instance in the database.
Obj-Save doesnt cause the object to be written immediately to the database unless the WriteNow
parameter is selected. Every Obj-Save without the WriteNow parameter checked becomes a deferred
save. A deferred save adds a deferred operation to an internal list of operations to be performed on the
next commit. The internal list is also known as deferred operations list or deferred list.
Until the next commit has occurred, either explicit or automatic, changes are not reflected in the
database. Automatic commits are performed:
When a new item is created
When a work object is updated, resolved, or reopened after processing for a flow-action is
completed
When an assignment is created or completed
When GetNextWork processing transfers an assignment from a workbasket to a worklist
When an additional flow execution starts for an existing work item
We can make an explicit commit in an activity using the Commit method as shown above.
There is not necessarily a 1-to-1 relationship between deferred saves and the list of deferred operations.
When we have multiple Obj-Save methods for the same clipboard page, there is just one operation in the
deferred list and that operation tracks all changes. So, there is one operation in the deferred list for each
466
clipboard page on which Obj-Save has been called no matter how many times Obj-Save has been called
on the page.
When a Commit is called and any of the operations fail a rollback is performed ensuring data integrity.
Consequently, it is not recommended to call a Commit method in an activity that is executed within a flow
since a situation may occur in which a failure occurs after the first Commit. In that case, only the
operations that were written to the deferred list since the first Commit can be rolled back, causing some
issue to the data integrity.
Another potential problem includes using the Obj-Save method with the WriteNow parameter checked.
In this activity for example, the first property-set method at step 2 sets pyNote property to Ready for
Review. The Obj-Save then adds this to the internal stack of deferred saves. Following this at step 4,
another property-set method sets the same property pyNote to Review Completed.
The next step is an Obj-Save now with Write Now set to true. This causes a write to the database with
pyNote set to the new value. A Commit follows. The result is the commit method causes all of the
deferred saves to also be submitted, which now re-sets the value of pyNote to the initial value, Ready for
Review.
So avoid using the Write Now directive unless it is absolutely necessary.
Use the Obj-Delete or Obj-Delete-By-Handle methods to remove an instance from the database.
467
Configure Connect SQL Rules

The Connect SQL rule can be used to interact with an external database. They can be found under the
Integration-Connectors category in the Record Explorer.
Lets have a look at a Connect SQL rule used to access an external POSTALCODES table. The Applies
To class is ADV-Purchasing-Int-PostalCode in this case. The mapping between columns and properties
takes place within the Connect SQL rule and does not need to be defined in the class rule. The Package
Name indicates the SQL language variant used and the Request Type field holds the name of the rule.
There are keywords and notations to describe mapping to the external database. This lesson only covers
parts of the syntax; see the Developer Help Connect SQL form Data mapping for a complete overview.
The Open tab is used to retrieve a single row in the database and copy its column values as properties
onto the clipboard page.
Lets fetch a city and region for a postal code. We can map the columns in the select to properties in the
clipboard page using the keyword as for the select.
It is a best practice not to hardcode table names in the SQL statement. Instead we can use the class
keyword that uses the Database Table instance configured for the class to determine the table name.
In the where clause we can then reference the ID property in the step page.
Use the characters /* and */ to surround comments within the SQL statement.
To include SQL debugging and return status information from the database software, enter a line at the
top of the SQL code defining the name of the page on which to record the messages.
Use the Delete tab for DELETE, TRUNCATE, or DROP statements and the Save tab for INSERT,
UPDATE, or CREATE statements. The Browse tab is used for queries that return more than one result.
468
Here we are searching on the city. The Asis keyword is used to prevent the system form placing spaces
or quotes around the value, which it does for standard property references. This way we can use wildcard
characters.
In addition to SELECT it is also possible to enter EXECUTE or CALL statements for stored procedures in
the Browse tab.
Connect SQL rules can be invoked from a data page or alternatively from an activity using the RDBmethods.
Know when to use Obj-Methods vs Connect SQL

We can interact with an external database either by using the Obj-methods in combination with an
external class or by using the Connect SQL rules.
If our application needs to perform simple SQL statements against a single external database table, it is a
best practice to configure access to the database table as an external class. This can be done using the
External Database Class Mapping tool.
When such external access is configured for an external class the Obj-methods can be used to interact
with that table through the class. It is not necessary to create Connect SQL rules.
We use Connect SQL rules if our application needs to run complex SQL statements such as joins or
stored procedures to update or extract information from an external database.
The Obj-methods are included in Pega 7s transaction handling while SQL statements in Connect SQL
rules are committed as they are executed.
Connect SQL rules Implement a custom error handling.
In certain situations it might be worth considering using a combination of Obj-methods and Connect SQL
rules. For example, when a complex search only supported by Connect SQL is needed but the rest of the
operations can be covered by the Obj-methods.
469
Conclusion
In this lesson, we explained features and tools available to accelerate the integration with external
databases.
Now, we understand the options for interacting with an external database and when which approach is
appropriate. We also understand the characteristics of external classes and know how to configure
Connect SQL rules.
470
Module 09: Architecture
Standard Agents
Controlling Access to an Application
Authentication Using LDAP
471
Authentication Using LDAP

Introduction
Welcome to the lesson on LDAP authentication using PRPC. Before diving into the details lets review
what authentication is.
Authentication is the process of verifying if a user has access to an application and is who they say they
are. This is often accomplished by verifying a user ID and password. In PRPC, by default, the user ID
and password is verified against PRPC operator ID instances.
However, in many cases enterprises have corporate directories, sometimes stored in LDAP, which they
wish to validate against. PRPC can be configured to use the LDAP directory to authenticate users
instead of its own operator instances.
LDAP is short for Lightweight Directory Access Protocol. It is a directory service designed to represent
large complex organizations. It is extremely flexible but at its core its a list of records, usually
representing people and their passwords.
Each entry can have attributes; some common ones are DN (Distinguished Name), CN (Common Name),
O (Organization) and OU (Organization unit).
These attributes can be used to determine where in an organization a person fits, what applications they
have access to and how to create/model their PRPC operator ID.
The process of authentication via LDAP and creating operator IDs is managed by the PRCustom
authentication scheme.
The PRCustom authentication scheme allows token-based authentication, and so it supports both LDAP
authentication and Single-SignOn (SSO) approaches. Note that we will focus on LDAP which is NOT a
Single SignOn approach in that users do enter their ID and password into the PRPC signon screen.
The video in this lesson was recorded in Pega 6.X. However, the Authentication Wizard and configuration
has not changed in Pega 7. In Pega 7 the Authentication Wizard can be started by selecting
DesignerStudio > Integration > Tools > Authentication Wizard.
Describe LDAP authentication
Describe PRCustom authentication type
Use Authentication Accelerator to implement LDAP authentication
472
Use Authentication Accelerator to implement LDAP authentication

Describe LDAP Authentication
Welcome to the lesson on LDAP authentication using PRPC. Before diving into the details lets review
what authentication is.
Authentication is the process of verifying if a user has access to an application and is who they say they
are. This is often accomplished by verifying a user ID and password.
In PRPC, by default, the user ID and password is verified against PRPC operator ID instances.
However, in many cases enterprises have corporate directories, sometimes stored in LDAP, that they
wish to validate against. PRPC can be configured to use the LDAP directory to authenticate users
instead of its own operator instances.
Lets briefly discuss what LDAP is. LDAP is short for Lightweight Directory Access Protocol.
It is a directory service designed to represent large complex organizations.
It is extremely flexible but at its core its a list of records, usually representing people and their passwords.
Each entry can have attributes; some common ones are DN, CN, O and OU.
These attributes can be used by PRPC to determine where in an organization a person fits, what
applications they have access to and how to create/model their PRPC operator ID.
The process of authentication via LDAP and creating operator IDs is managed by the PRCustom
authentication scheme.
The PRCustom authentication scheme is used for both LDAP authentication and single-signon (SSO)
approaches. Note that we will focus today on LDAP which is NOT a Single SignOn approach in that
users do enter their ID and password into the PRPC signon screen.
Other lessons will cover SSO.
Describe Authorization Model

The PRCustom authentication starts when a user requests a special URL. The URL is mapped via a
servlet mapping to a servlet defined in the applications web.xml.
Here the authentication type parameter is set to PRCustom telling PRPC that users coming to this URL
will use the PRCustom authentication scheme.
The web.xml also specifies the name of the authentication service that PRPC is going to use to define the
rest of the authentication process.
The authentication service itself defines the location of the LDAP server and other LDAP specific settings
as well as the names of the activities that are responsible for handling the authentication and the
timeouts.
Luckily, PRPC provides a wizard that handles most of this for us so we do not need to create a new
servlet nor change our web.xml.
There are two activities defined by an authentication service; the timeout activity and the authentication
activity.
The authentication activity is called when users submit the login form and is responsible for verifying the
users credentials.
473
If the users credentials pass the activity is responsible for creating or updating a Data-Admin-Operator-ID
to represent the user. Even though the operator ID is not used for authentication it is still required as it is
used by PRPC for work routing, reporting and other functionality.
We may need to customize this activity to add additional business logic such as mapping the LDAP
attributes to those known by our application.
By default the operator is created using the model operator defined on the organization unit as a
template. To use this approach weu must map the appropriate org unit fields.
The timeout activity is used to display the authentication challenge screen and re-authenticate the user.
The sample activity can often be used with little modification.
Again, the authentication wizard handles a lot of this for us. Lets look at an example.
Use Authentication Accelerator to Implement LDAP Authentication
To get started lets review some information about the LDAP system to which we are going to connect..
We need the LDAP server URL for PRPC to connect to.
We also need the Bind Distinguished Name and corresponding password. This is the account we initial
connect to LDAP with, not the account of the user being authentication.
The LDAP administrator also needs to provide the search context, which is the location in the directory to
search for this user as well as the Search Filter used to find the user.
Finally, it is good to have the ID of a test account that is representative of the users of the application.
This test accounts attributes are used by the wizard in the data mapping step. It is also important to
understand the attributes of each entry and how they map to our application.
Here we see an example entry for a test user and their attributes.
Now we are ready to run the wizard.
We can start the wizard by clicking the Pega button and selecting Integration > Tools > Authentication
wizard.
The Authentication wizard creates an authentication service already configured to one of three predefined
servlet definitions. This eliminates the need for us to create a new servlet or modify web.xml.
Next we select the LDAP server type. For anything but the Websphere and Weblogic built in server the
Sun option is safe choice. This sets the context factory for us.
Next we set the directory URL which was provided.
Since we are not using SSL we can skip the trust store.
Next we complete the bind name and password, also values that would be provided by our LDAP
administrator
The search context defines where we look in our sample LDAP directory. The search filter is UID as that
is the field that has the email address for which we are authenticating.
Finally, we enter the test user ID which is used to help us in the mapping step.
The mapping screen has two columns the attributes found for our test user and the PRPC properties, on
the operator ID, to map to.
474
The wizard initially shows the org, division and unit properties as these properties must be mapped when
using the default activities. This is because the orgunit is where the model operator is defined.
We can select the attributes that map to our properties. If these properties dont map exactly we can
perform additional mapping by customizing the authentication activity.
We can also add additional mappings to set things like the user name and user identifier. These
mappings overwrite the values in the model operator.
We can now click Next and fill in any of the additional descriptions we want to set and then click Finish to
generate our authentication service.
On the confirmation screen we can see the name of the AuthService that was generated, WebLDAP2.
We can also see the URL for users who are going to use this authentication service.
Note that running the wizard doesnt disable other authentication services or servlets. It is possible to
have LDAP and PRBasic authentication running at the same time. If you wish to disable PRBasic
authentication you may do so via web.xml.
We can click the open button to see the generated authentication service.
Here we can see the values we entered as well as the names of the default authentication and timeout
activities being used.
We can also see the mapping values we entered.
Now lets see our LDAP authentication in action.
First we must connect to our LDAP URL.
We can see that this URL is using our PRWebLDAP2 servlet rather than the standard PRServlet. This
causes PRPC to use the WebLDAP2 authentication service.
Lets see what happens if we try to login as a user who is not in our directory.
We can see that an appropriate error messages is shown.
Now well try a valid user with an invalid password.
Again we see the appropriate error message
Now we can enter the valid user ID and password.
At this point PRPC has validated the user ID against LDAP and automatically created the operator ID
instance using the model operator.
By clicking the profile we can see that this user was assigned to the sales orgunit based on their LDAP
attributes.
Now lets logout and go back to our standard PRServlet URL
From our PRServlet URL we can try to login as our newly created operator.
PRPC prevents users created via external authentication from logging in via PRBasic authentication.
This is a good thing as we can still keep PRBasic authentication for developers or administrators.
Now well login as an architect to see what was created.
First well look at our operator list. Here we can see that we now have a user test.user1@les.com
475
On the operator form we can see that some fields, for example full name, were mapped from LDAP.
Other fields, such as the access group, did not come from LDAP but from the model operator.
The model operator comes from the organization unit that was mapped from LDAP.
This test operator was part of the sales unit. We can see that the sales org unit has a model operator
defined. This model operators data is merged with the data from LDAP to create the new operator ID.
The data from LDAP takes precedence over the model operator. So in our case the Full name was
replaced with the LDAP data but the access group was not since it was not mapped in our authentication
service.
Now that weve seen the standard behavior of the authentication activity its important to understand that
this activity is a sample and is often customized in some way.
Some common customizations include changing the messages shown to the user when authentication
fails. Perhaps even localizing the messages.
Another common customization is to add additional mapping logic to use decision rules to determine the
proper model operator or access group using a number of different LDAP attributes.
Or to add logic that uses LDAP attributes to explicitly to deny access to certain users.
Conclusion
Using LDAP as an authentication service for PRPC is straight forward and can be accomplished quickly
by using the accelerator to get started. This speed does not come at the cost of flexibility as the
authentication activities are designed to be overwritten and extended to meet our applications
requirements.
7.1.6 Course Update

In the previous video, a sample URL for accessing the login screen for PRPC was listed
as http://10.61.8.14:9080/prweb/PRServlet. As of Pega 7.1.6, specifying the PRServlet authentication
servlet is no longer required at login.
Developers and users may log in to PRPC without specifying PRServlet for authentication for
example, http://10.61.8.14:9080/prweb/ and the system automatically assumes PRBasic authentication.
For other forms of authentication, use of the authentication servlet in the URL is still required.
Conclusion
Using LDAP as an authentication service for PRPC is straight forward and can be accomplished quickly
by using the accelerator to get started. This speed does not come at the cost of flexibility as the
authentication activities are designed to be overwritten and extended to meet our applications
requirements.
Now, we understand the underlying custom authentication model and how it can be used with LDAP. We
also know how to use the Authentication Wizard to implement LDAP authentication.
476
Controlling Access to an Application

Introduction
Welcome to the lesson on Controlling Access to an Application. It is important to keep the concepts of
authentication and authorization separate so lets start by reviewing these two key terms. Authentication
determines if we are allowed access to an application. In essence authentication verifies we are who we
say we are and that we are allowed into the application.
Authorization on the other hand determines what we are allowed to do and what data we can see. For
example both a call center representative and a senior vice president may both authenticate against an
application but their authorization is different.
In this lesson we look at authorization. We begin with a recap of the authorization model. Then well have
a look how we can use the Access Manager to configure control to an application.
It is important to understand that the underlying authorization model has not changed in Pega 7. What
has changed in Pega 7 with the introduction of the Access Manager is the way the rules are configured.
Describe the Authorization Model
Interpret access control settings in the Access Manager
Manage access control with the Access Manager
Describe how the Access manager configures underlying rules
Explain when to use the Access Manager
477
Access Control in Pega Applications

To understand access control in a Pega application, we need to understand the relationship between the
records that identify users and the records that describe the elements of an application. So lets start by
reviewing how the system identifies users and provides access to applications and application features.
When users attempt to access an application, the system performs two important tasks: authentication
and authorization. Authentication verifies that the user is who he or she says they are. Authorization
ensures that the user is allowed to perform tasks on the system itself. Both of these tasks authentication
and authorization are important in determining the capabilities granted to a user.
When a user logs in to an application, the system authenticates the user to verify their identity and
determine the corresponding operator ID record. This operator ID record an instance of Data-AdminOperator-ID identifies a named user on the system.
Once the user has been authenticated the system determines that the user is who they say they are
the system determines what work the user is authorized to perform.
Each operator ID record lists one or more access groups. An access group defines an application the
operator can access and, by extension, its rulesets and describes the capabilities allowed to that user.
For example, an operator ID record might list the access group PurchaseFW:PurchaseRequestor. This
means that the user can access the PurchaseFW application with the capabilities provided to a Purchase
Requestor. An operator ID may list several access groups, but only one access group is active at any
time. A user can switch between access groups by selecting a different application in the Application
menu each entry in the menu corresponds to an access group listed on the users operator ID.
Each access group also lists a series of roles. A role lists a set of allowed capabilities, and is an instance
of Rule-Access-Role-Name. Unlike the access groups listed on an operator ID, all of the roles listed on an
access group are in effect at the same time. The ability to divide capabilities into multiple roles improves
reusability an access group for managers can include both a User role and a Manager role, thus
granting the capabilities assigned to each role to managers, without copying the user role capabilities to
the manager role. By combining the capabilities of each role, the access group describes a composite
role for its constituent users.
478
The access controls and permissions listed in a role are managed at a class level by the access of role to
object rule, commonly referred to as an ARO. Each ARO is an instance of a Rule-Access-Role-Obj rule,
and applies to a specific class. The ARO defines the capabilities that apply to that class and the
instances of that class. For example, an ARO might allow a specific role to open cases, but not to run
reports.
Each ARO can also include a set of privileges, which allows an application to permit or deny access to
specific rules and tools. Think of a privilege as a token. By itself, the token doesnt do anything, but other
rules can require that a user possess the token to allow an action. For example, the flow action Approve
may require a user to be granted the privilege CanApprove. So, if a user has been granted the
CanApprove privilege, they can access the Approve flow action rule to perform an approval, while a
user who lacks the privilege cannot perform an approval.
Privileges can be added to many rule types, and can be checked programmatically by utility functions.
Privileges can also be conditionally granted by system level or through the use of Access When rules.
By combining all of these types of rules, an application developer can model complex application
requirements to create a powerful authorization model.
479
480
Review an Authorization Model with the Access Manager

To help understand the permissions provided or denied to a group of users, we can use the Access
Manager to start any review of a security model.
The Access Manager available from the Designer Studio menu by selecting Org & Security > Access
Manager consists of three tabs: Work and Process, Tools, and Privileges.
The Work and Process Tab

The Work and Process tab configures access controls for cases. This tab lists the operations available
to the selected access group for each case type, and allows control over the actions available to a
specific role defined for the access group.
Each action can be set to either full availability (Full Access), no availability (No Access), or conditional
availability (Conditional Access).
Open, Modify, and Delete indicate whether an operator can open, edit, and delete instances of the case
type. Perform indicates if the operator can perform other operators assignments for the case type. That
is, if No Access is specified, the worklist for each operator in that role contains only his or her own
assignments. Run Report indicates if the role can run reports defined for the case type. View History
indicates if users can view the history for the case. Most actions can be governed for each case type, but
View History is specified at the class group so the setting is same for all case types in a class group.
In this example, the PurchaseFW:Managers access group consists of three roles: Purchase Requestor,
Purchase Manager, and PegaRULES:Feedback. For each operation, the Access Manager displays the
access rights for each role. In some cases, the permissions for an operation differ between the roles. For
example, the Purchase Requestor role has permission to open a Program Fund case, while the
PegaRules:Feedback role does not. When this occurs, the system uses the most permissive role in the
481
access group to determine the level of authorization for the operation. Since the Purchase Requestor
role has full access, this permission governs the operation for the access group, overriding the no
access setting for the PegaRules:Feedback role.
Conditional access the yellow circle generally indicates the use of an access when rule to determine
the circumstances in which a role is to be granted access. In the following example, an access when rule
named RequestedByOrForMe has been added to the Delete operation for the Purchase Request case
type, to ensure that requestors can only delete their own purchase requests, but not requests for other
operators.
The Process Flows and Flow Actions sections indicate the flows and flow actions that an operator can
access and therefore perform. By default, the Access Manager only lists the starting flow for the case
type, and the flow actions referenced by that flow. To configure permissions for flows and flow actions
along with any other rule type that allows permissions we can create and apply the permissions
ourselves.
When the yellow circle appears next to the case type, it means that more than one permission level is
applied to the actions listed for that case type. So, if the permission level for Run Reports is set to No
Access, and all other actions are set to Full Access, the indicator applied to the case type is the yellow
circle, to indicate that a mix of permission levels is in effect for the case type.
The Tools Tab

The Tools tab configures access controls for Designer Studio features and capabilities, such as the
Clipboard and Tracer. Access control configuration on the Tools tab behaves the same way as access
control on the Work and Processes tab. The only difference is that the list of case operations is replaced
with a list of application development tools available in the Designer Studio.
The Privileges Tab

The Privileges tab lists all of the privileges configured for a specified role and case type or data type. The
contents of this tab summarize the contents of the other two tabs. By entering the name of a role and the
name of a case type or data type, we can quickly review the current privilege customizations, and add
new privileges or remove existing ones.
482
Configure Access Control using the Access Manager

Lets see how we can use the Access Manager to customize permissions for different roles.
When Application Express creates an application either in the framework layer or the implementation
layer it creates two default roles and access groups: one of each for managers and users. We can
create additional roles or access groups as needed.
In our demo application, these roles have been renamed Purchase Requestor and Purchase Manager,
and the user access group has been renamed PurchaseRequestors.
We need to configure privileges for the Purchase Requestor role so that users with this role cannot
modify any purchase request, and can only delete those requests made by or for themselves. To prevent
members of the department from modifying existing purchase requests, we can set the Modify action to
No Access. For the Delete action, we can apply an Access When rule to configure conditional access. In
our example, we can create an Access When rule named RequestedByOrForMe to test both the Create
Operator and Requested For properties. If either one matches the current operator, the rule returns a
true result and the system grants access.
Also, members of the Purchasing department create purchase orders as part of the process of fulfilling
purchase requests. We want to ensure that members of the Purchasing department can complete
purchase request tasks assigned to their coworkers. A department is modeled as a workgroup, so we can
apply the standard Access When rule pxAssignedToMyWorkGroup to configure conditional access to
the Perform action.
483
If we look at the AROs, we can see how the Access Manager performed its configuration.
On the Purchase Request ARO for the Purchase Requestor role, Modify instances has been set to a
permission level of 0, which means no access. Also, Delete instances has been configured for
conditional access by adding the Access When rule RequestedByOrForMe.
On the Purchase Orders ARO for the Purchasing role, a Perform privilege was added to the Privileges
tab, and used the Access When rule pxAssignedToMyWorkGroup to provide access conditionally. The
L: prefix indicates conditional, or limited, access.
484
Whenever possible, the permissions for one role should not overlap those for other roles. This best
practice simplifies maintenance of the authorization model. Remember that by combining roles, we can
use conditional permissions and override permissions on a different role to customize the resulting
composite model.
Configure Access Control without the Access Manager

The Access Manager makes managing access control significantly easier for system architects and
administrators. However, some access control needs cannot be configured using the Access Manager.
Some situations do not support use of the Access Manager, such as controlling access to workbaskets
and attachments.
We can control access to a workbasket by adding specific roles to a workbasket record. This access is a
binary event: either workbasket is limited to a specific role, or it isnt. If no role is specified, assignments in
the workbasket are available to any member of the work group that owns the workbasket.
Access control for attachments can be configured on the attachment category rule form. The access
control model for attachment category rules uses privilege rules and when rules (rather than access when
rules) to determine whether users can create, edit, view, or delete attachments from a case. In addition,
the Enable attachment-level security option allows an operator to identify one or more workgroups that
can access the attachment.
485
Control Run-Time Access to Individual Rules

Pegas access control model can be extended to individual rules as well. This allows an application
developer to grant or deny access to specific rules, such as flows, flow actions, and activities, and affects
the actions that an operator may perform during case processing.
Access control for a flow, flow action, or activity is configured by adding a privilege to an access role, and
applying that privilege. This process involves three changes:
1. Create a privilege rule.
2. Add the privilege to the ARO.
3. Add the privilege to the controlled rule.
In our application, we want to make sure that purchase requestors cannot approve purchase requests,
and that managers cannot approve their own requests. To accomplish this objective, we can limit access
to the pyCascadingApprove flow action for the PurchaseRequestors role.
First, to configure access for a rule, that rule must be saved to an unlocked ruleset. This allows us to
apply the privilege to the rule itself.
Next we want to create the privilege. By convention, the name of a privilege should specify the type and
name of the rule to which it applies. This helps other application developers understand how to use the
privilege. In this case, we would create a privilege named Rule-Obj-FlowAction:pyCascadingApprove.
To further clarify its usage, we can also include the name of the class that contains the rule, although this
results in a privilege name that exceeds the 64-character limit on rule names.
Then, we want to add the privilege to the purchase requestor role. We can open the
PurchaseFW:PurchaseRequestor ARO for the Purchase Request class. On the Privilege tab, we can
add the privilege we just created, and set the level to match our desired permission level. A level of five
indicates full access, while a level of zero indicates no access. To prevent access for users, we set the
level to 0.
486
Next, we need to configure the Purchase Manager role to allow conditional access to the flow action.
Remember that the roles are combined at the access group level, and the most permissive authorization
is applied. So far, we have denied access for requestors. Since we havent applied any privilege for
managers, the Managers access group can only apply the permission setting from the Purchase
Requestors role. To ensure that managers can approve purchase requests other than their own, we must
add the privilege to the manager ARO and configure conditional access with an Access When rule,
prefixing the rule name with an L:. In our example, we can create an Access When rule named
NotRequestedByOrForMe and apply it to the ARO. This rule tests both the Create Operator and
Requested For properties. If neither one matches the current operator, the rule returns a true result and
the system grants access.
Finally, we can open the flow action and apply the privilege on the Security tab.
This successfully secures access to the approval flow action. When the application calls the flow action,
the system checks the Security tab for any necessary privileges. If a privilege is required, the system
checks the appropriate ARO to determine the level for the privilege, evaluating any Access When rule to
do so. For users with the Purchase Manager role, the more permissive conditional access setting
overrides the permission specified for the Purchase Requestor role (no access).
487
Conclusion
The Access Manager provides a great overview of who can do what in the application. Consider the
Access Manager a view to your authorization model, rather than a means to construct it. We need to
create access roles and access groups, and define privileges independently of the Access Manager.
Remember that only the application scope is shown. Always review the underlying roles to ensure that
the system meets the security requirements.
Now, we understand the underlying authorization model. We know when and how to use the Access
Manager to configure access to our application. We also understand how to configure privileges for
specific rules.
488
Module 10: Administration
System Debugging
Designing for Performance
System Tuning and Maintenance
Migrating an Application
489
System Debugging
Introduction
Welcome to the lesson on System Debugging. Lets face it, every system is going to have bugs so its
imperative to know how to track them down and get rid of them. This lesson focuses on the tools
available for locating bugs and tracking them down to a root cause.
Explain the available debugging tools
Access the system logs
Read stack traces
Use the Clipboard to Review Session Data

Process Commander always associates a temporary memory area on the server to every requestor
including browser-based users and even unauthenticated guest users. This memory area is known as
Clipboard. The Clipboard tool provides a requestor a way to review and act upon the contents of the
clipboard to which they are associated.
Before discussing the structure of the Clipboard, lets see how one can access the Clipboard tool.
Accessing the clipboard
To access the clipboard, click on Clipboard in the tools area at the bottom of the Designer Studio. This
launches the clipboard in a second window.
The clipboard is one of the most useful tools for debugging the system. It allows us to access the entire
page structure for the system, one thread at a time. Typically, the clipboard tool is used when developing
and debugging to examine property values and messages associated with them and to find the
information necessary to reference a property, such as the page names and the property name.
Now that we know how to access it, lets discuss the structure of the Clipboard tool.
The Structure of the Clipboard

The first thing to mention here is that clipboard pages are defined in a specific name space context or
scope called a PRThread, which is sometimes referred to as a Thread with a capital T. PRThreads are a
data structure used in the system to allow a requestor to have separate clipboard page name spaces that
do not interact with each other. It is what allows a single requestor to run multiple copies of a workflow
simultaneously in the user's perspective, so users can process more than one work object on a single
workstation, like the parent case and its subcases. Were not going to cover how a PRThread functions
at this time, but it is important to point out that these PRThreads exist and well need to switch between
them to see all the possible clipboard pages.
490
In order to switch to a different PRThread, we click the name of the current PRThread in the upper left
corner of the clipboard tool. This shows us a list of other PRThreads we can select. Once we select one,
the clipboard tool refreshes to show us the pages associated with that PRThread.
The next thing to point out is that the clipboard tool is divided into two panels. The left panel displays the
entire clipboard for the currently selected PRThread as a tree. The first pages in the tree are the top-level
pages. In this screen, pyPortal would be a top level page. Selecting any one of these pages refreshes
the right panel, where we can see all Single Value properties, sorted by property name.
Within a top level page can be additional embedded pages, lists or groups, as shown in the tree by a
slight indent. These are labeled with one of these icons:
represents a property with mode Page.
represents properties with modes Page List, Page Group, Value List or Value Group.
Properties of mode Java Object, Java Object List and Java Object Group are not shown on the clipboard.
When we select any of these pages, the clipboard displays the properties of that page in the right panel.
Note, that in the case of a Value List or Value Group, the values of all the elements in that list or group
are shown instead, as seen here.
491
The clipboard tool arranges the top level pages into four categories.
User Pages this contains the top-level pages created by the requestor during normal
processing, sorted alphabetically by page name. For example, an execution of a Page-New
method in an activity results in a new page being added to this category.
Data Pages this contains all the data pages instantiated in the system. See the lessons on
data pages for information on their usage.
Linked Property Pages this contains all the pages created by a linked property. See the
lesson on properties for information on their usage.
System Pages this contains special, reserved pages the system relies on to function. Within
this category, three pages are always present.
o
pxThread this contains the information about the current PRThread.
pxRequestor this contains the information about the requestor and HTTP protocol
parameters.
pxProcess this contains information about the servers Java Virtual Machine and the
operating system.
Additional pages that contain information on the access group, application rule, operator ID,
organization, org division and org unit may appear as required. Guest users do not have these
pages as theyre part of the authentication for a named user.
Working with the Clipboard

The clipboard provides us a menu through which pages can quickly be manipulated.
The menu provides the commonly used options of Edit and Refresh as separate buttons. The rest of the
options are available by clicking on the Actions button.
Edit - allows us to update values on the page. This is useful to prepopulate data during testing
that the system might not currently process. For example, if were calculating a full name out of
the users first and last names, we can enter those values here to test our calculation instead of
492
waiting for the screen to be built that lets the user enter them. Of course, our testing shouldnt
end here. Dont forget to also test once the screen has been created!
Refresh - gets the latest values from the system. Since the clipboard opens in a separate
screen, it is possible for the system to continue processing even though the local copy we have
on our desktop does not match the one at the server. As a best practice, if the clipboard is left
open and the system has moved screens, we should use the refresh button to update our view of
the clipboard before examining any values.
Show XML - provides a raw XML view of the entire page. This is useful to see the entire page,
including the embedded pages, on one screen. It also has the added benefit of displaying any of
the properties that start with pz which are reserved by the system and therefore not shown on
the clipboard.
Execute Activity - allows us to run an activity using this page as its step page. This provides the
same functionality as the run button available when an activity is open in the designer studio.
Above the menu we find the clipboards toolbar.
This toolbar provides us a search box to locate values on any clipboard page, a tools menu with the
options Analyze and Collect Details. These are advanced tools used to track approximate sizes of pages
on the clipboard.
Securing the Clipboard

PRPC requires users to have access to the @baseclass.clipboardViewer privilege in order to be allowed
to access the Clipboard tool. The Action menu items that update the clipboard contents are available only
to users who hold the @baseclass.clipboardViewerUpdate privilege. The standard access roles are listed
below and all provide access to these privileges:
PegaRULES:SysAdm4
PegaRULES:SysArch4
PegaRULES:ProArch4
any <application name>:Administrator access roles created when we run Application Express
. Generic users should not be granted any of these roles if they do not require access to the clipboard.
493
Use the Tracer to Debug Applications

The tracer is tool that is useful in identifying how the how the system behaves during processing. It
allows us to view exceptions, look at SQL queries, and examine the properties of pages at each step.
Accessing the tracer
To access the tracer, we click on the Tracer in the tools area at the bottom of the Designer Studio. This
launches the tracer in a second window.
The tracer displays an area for the results and a toolbar. Were going to take a look at the toolbar first.
Pause/Play this icon starts or stops the tracer. Pause displays when the tracer is currently
capturing events and play is displayed when the tracer is not.
Clear this icon removes the results visible in the window. This is useful when restarting the
tracer.
Settings this icon allows us to configure the options for the tracer. Well review the options a
little later in this lesson.
Breakpoints this icon allows us to define a breakpoint for the tracer. This is useful when we
want to automatically pause the execution at a predefined point in the process to closely examine
the system.
Watch similar to breakpoints, this allows us to define when to automatically pause the tracer.
With watch we define to pause when the value of a property changes, instead of a predefined
point. This is useful to track down where a value gets set if we are unfamiliar with the process
setting that value.
Remote Tracer this allows us to select other requestors to trace. This is useful for debugging
from one system while logged in as a test user in another system. Well discuss more about this
option a little later in this lesson.
Save this saves a copy of the tracer results for analysis in a separate application called Tracer
Viewer. This application will be discussed later in this lesson.
494
Viewing the results
The results displayed in the tracer can be overwhelming. But once we understand how the tracer
displays its data, it becomes quite easy to read through a process. One of the first things to realize is that
the most recent event is at the top of the tracer. So working from top to bottom were working backwards
in time, from the most recent to earlier events. The line numbers also indicated this backwards nature and
serve to remind us of this fact.
Most events in a tracer have both a Begin and an End. These two lines form the box around the event,
with the lines in-between representing sub-events that took place during this event. Take a look at the
screen above and identify the Activity Begin in line 21 and the Activity End in line 44. So, between lines
21 and line 44 we were running the same activity.
When tracing Data Transforms and Activities, we will also see a Step Begin and a Step End for each step
in the data transform or activity. These steps indicate the method being executed, provide a link to the
step page of that step, identify the status of that step, and much more. The help files contain information
about each one of these elements in detail.
Clicking directly on the step page opens a view to the properties on that page, similar to the clipboard.
495
Clicking directly on the rule name is a link that opens the rule instance in the developer studio
Otherwise, clicking anywhere else on the row opens a screen that shows more information for that event.
496
This screen provides a few additional details, such as the full timestamp and the workpool that is not
visible in single row. The real benefit to this screen though is the ability to view the parameter page.
Clicking on the name of the parameter page, which is often =unnamed=, opens a similar view as the
step page, where we can view the parameters and their associated values.
Configuring Tracer
The tracer provides us with many options to control the output to the tracer. The first thing to note is that
the Tracer Settings are broken into several categories. These are all described in detail in the help files,
but lets take a high level look at some of the more commonly used ones.
497
The events to trace and break conditions category provides us with the ability to select some of the more
critical events, such as data transforms and when rules. Unless we need the data, we recommend using
the defaults as selected.
The next set of options is the Break Conditions. This causes the tracer to automatically pause if one of
these is encountered. Again, unless needed, it is recommended that we use the defaults as selected.
The last set of options can affect the performance of the tracer. Tracer by itself can greatly impact the
system performance.
Abbreviate Events this option reduces the performance impact, but sacrifices keeping the
clipboard detail. When this is selected the step pages are not available and we cannot view the
values associated with their properties.
Expand Java Pages this is only useful if the system contains any properties of mode Java
Page. This option should be turned off if such properties are not in use.
Local Variables this option provides the means to view the local variables which are not
available from the parameter page. This option should only be turned on when we specifically
need to debug an issue with a local variable.
498
The next category is event types. This category provides additional, optional events that we can trace.
These events can be things like Flow, Declare Expression or DB Query. By selecting one of these
anytime the associated rule type is executed an event is written to the tracer. The event type Stream
Rules encompasses all UI rules, such as a Harness or a Section.
At the top of the list, we have the option to add additional event types. Since the most common types are
already provided, we should not need to use this capability except as directed by your Lead System
Architect.
The next big category is the rulesets to trace. This category allows us to eliminate some rulesets from the
tracer output, to improve its performance. The entire ruleset stack is available to us, but as a general rule
we shouldnt need to trace any of the Pega* rulesets. Our primary concern with debugging is our rules,
so by removing these rulesets we can potentially save thousands of lines of results.
499
The tracer only provides the step page and the parameter page by default for each event it traces. We
have the option of tracking additional named pages when necessary. This capability is very powerful, but
comes at the cost to performance. When one of these is enabled the system requires much more
memory to keep a record of this additional page at every step of every event. It should only be used
when there is interactions between multiple pages that cannot be traced separately. This option is not
available if Abbreviate Events is selected.
The last option is for the number of lines visible in the tracer window. By default the system displays 500
lines. This can be increased (or decreased) as necessary. Its important to note that increasing this
value affects the tracers performance, as it requires a larger amount of memory.
Using the Tracer Viewer

Tracer viewer is an external standalone installation that can be installed in the local system. It is useful in
interpreting the tracers output. To obtain the Tracer viewer, see the PDN article Use the Tracer viewer
tool to summarize Tracer XML output.
Before we can use the Tracer viewer, we first need to save the tracers output. We do this by clicking the
Save icon in the tracers toolbar.
This downloads an XML file of all the tracer events captured during this tracer session. Once the file has
completed downloading, we can launch the Tracer viewer tool. The tool by default is a blank screen so
well need to open the file we downloaded.
Once weve selected a file, the Tracer viewer processes the file and presents the results in a tree view
500
Note that processing the file may take some time, depending on the number of events traced. More
information about this tool can be found in the same PDN article we used to download the tool.
501
Use the UI Inspector to Identify User Interface Elements

Our final debugging tool is the UI Inspector. The UI inspector is used to discover, view and edit the user
interface elements in our application.
Accessing the UI Inspector

The UI Inspector can be accessed in the Developer Studio from the toolbar.
But this will be used for identifying parts of the developer studio and is only useful to us when previewing
a UI rule. The real power to the UI Inspector comes from running it in the user portal.
502
To run the UI Inspector in a user portal, we need to launch the users portal from the launch button in the
developer studio. After the user portal opens, there is a floating button that allows us to toggle the UI
Inspector on or off.
While the UI Inspector is active, as our mouse hovers over any user interface element, the selected
element is highlighted in red and an information panel is displayed about that element.
The information panel displays the type, name and name of the immediate container of this element on
the left panel. The right panel displays the entire UI structure showing all the parent containers for this
element.
In this case, we can see were inspecting a section named pxDeadlineTime that is an element of the
section pyUserWorkList. We can also see that this section is contained in another section, which is
contained in another section, which is contained in another section, which is contained in another section
that is finally contained in a harness.
Hovering over any of these parent sections outlines that element with a blue dashed line.
Securing the UI Inspector

PRPC requires users to have access to the @baseclass.pxUIInspector privilege in order to be allowed to
access the UI Inspector.
503
The standard access roles are listed below and all provide access to this privileges
PegaRULES:SysAdm4
PegaRULES:SysArch4
any <application name>:Administrator access roles created when we run Application Express
Generic users should not be granted any of these roles if they do not require access to the UI Inspector.
504
Access the system logs

One important aspect of debugging is to keep an eye on the system logs. These logs track when
exceptions and other events occur and provide valuable insight into their cause. Ideally, at the end of
development there should be no log entries being recorded so it is important to periodically monitor these
logs.
Accessing from within Designer Studio
To access the logs, we select Designer Studio > System > Tools > Logs and Log Files. Note that Logs
files can also be obtained from the System Management Application.
Opening this displays a new window displaying all the available logs.
505
There are several logs available to us, but the important one for debugging is the one called PEGA.
The other logs apply more to performance and are addressed in that lesson.
Each of the logs gives us the option to download a zip or the raw text of the log. Downloaded files can be
opened in any text editor. Clicking on the name of the file directly opens the log.
By default, the log is filtered to entries that match our current operator ID. To view other entries, expand
the Options and change or remove the filter by option.
Remote Logging
Via the System Management Application, we have the ability to perform remote logging. Remote logging
establishes a connection between the server and a standalone application running on our desktop. To
run the remote logger, first access the SMA and select Remote Logging under the Logging and Tracing
category.
506
From this page, download and extract the log4j socket server, available at the bottom of the page. Once
this has been extracted and run, were presented with the remote logger user interface.
Once this is running, we can establish the connection by returning the SMA and specifying the host as
our system, the port as shown in the first line of the logger (default is 8887) and any filters. The filters
work the same way as the Log File tool in the developer studio.
A really nice feature of the remote logger is that it is updated near real-time, without having to constantly
download the log files. This allows us to watch the log files as were stepping through a process and
identify when certain exceptions or events occur. Remember that this is only near real-time as the log4j
appenders work in the background, so its important not to jump through our steps too fast and allow the
remote logger to keep up with us.
507
Read Stack Traces

When were dealing with log files, tracer files and other debugging tools were going to encounter a stack
trace. Much like the tracer, stack traces provide us a look at all the processes weve stepped through on
the way to the current exception. Its important to know how these are laid out in order to get the most
benefit out of them.
If you want to see a sample log file, please download the log file from the Stack Trace Sample Log link
in the related content section.
Lets take a look at this sample stack trace. In this trace, the first two lines tell us about the exception.
Breaking these lines down, we can identify the following information
2014-03-12 09:41:36,186 this is the timestamp of when this exception occurred
STANDARD this is the name of the PRThread
HRServices:01:02:01 this is the application
ERROR this is the log level. Other log levels as defined in the help might be displayed instead.
Activity name not specified - this is the cause of the exception
Java.lang.illegalArgumentException this is the type of the exception
This is then followed by a series of lines starting with at. Each of these lines walks us backwards
through the calling process. The very first at is the line of code that was executing when the exception
occurred. Note that even though this is the point when the exception occurred, this may not be the point
where the exception was caused. To determine that, lets walk through the whole trace.
1. The first line indicates it was executing doActivity.
2. doActivity was called from the CallActivity method.
3. This was called by invoke
4. Which was called by resolveAndinvokeFunctionViaReflection
508
5. Which was called by .

Well, you get the picture. The key here is to look for information that paints a picture of what was
occurring when this exception occurred. Looking through the entire stack trace, I can pick out the
discerning lines:
executesla_3f878d06811a288900aafea845f0efb1.step19_circum0
processevent
BatchRequestorTask.run
AgentQueue.run
Putting these items together with our knowledge of agents we can see determine that the SLA agent ran,
which runs on a batch requestor, was processing events from the agent queue, one of them was
executing its SLA and the system threw the exception at step19. We could open the executesla activity
and look at step 19, but our knowledge of SLAs tells us the fact this SLA was calling an activity it was
most likely an undefined exception path that caused the Activity name not specified.
This was a relatively simple stack trace, but applying this same logic to any encountered exceptions we
should be able to determine the root cause and subsequently debug any issue.
509
Conclusion
So what did we all learn? First off, its important to note that debugging is essential. Were always going
to encounter bugs as a byproduct of development but by using the tools available to us we can stay on
top of them and repair them early during development.
510
Designing for Performance

Introduction
Welcome to the lesson on designing for performance. We all know that performance is an important
aspect of any system. User satisfaction and business value are often measured by the perceived
quickness of the system. In this lesson we will discuss different tools to measure performance and some
best practices to ensure were building with performance in mind.
Describe the different performance tools
Ensure the system is following the guardrails
Discuss best practices for performance
Describe the Different Performance Tools

PRPC provides us with a full suite of tools to monitor and address performance. While were developing
we should constantly be using these tools to ensure our system has a minimal impact to performance.
Each of these tools is described in detail in the help files, but lets take a high level look at what each one
offers.
Performance Analyzer (PAL)

The performance analyzer, also known as PAL, is one of the most important tools in this suite. This tool
provides a view to all the performance statistics that PRPC captures.
Launching PAL
There are a few ways to launch PAL. We can select to launch it from the Performance option in toolbar in
developer studio.
This opens the Performance Analyzer in a separate window.
Or we can select to open PAL on a landing page. To do this we select PAL from the Performance submenu of the System Menu.
511
This opens PAL on a Landing page.
The last approach is to access the PAL readings through the System Management Application (SMA).
This can be done from the Requestor Management screen by selecting a requestor and clicking
Performance Details.
It is important to note that viewing the results through the SMA is only a current summary and does not
allow us to add incremental readings.
Taking Readings
No matter which approach we use to launch PAL, the way we gather performance statistics is the same.
For the sake of this demonstration, Ill be using the PAL Landing Page.
512
The first step to taking measurements is to click Reset Data. Since the system is constantly monitoring
performance, by clicking this button were eliminating any previously recorded entries from our results.
Next, we need to take some readings. We have two options to add a reading, with or without the
clipboard size. There is no difference between the two readings other than the addition of the clipboard
size, which takes a bit of extra time to calculate. When adding a reading, its a good practice to have
defined points that identify what occurred during that reading. I prefer to use one reading per flow action
or screen render, depending on what process Im measuring.
Lets go add a couple of readings now so that we have some details to analyze.
Heres our performance analyzer with readings added. Note that each reading added is shown as a
delta. This is indicates its the change from a previous reading. At the top of the list, above the column
labels, is a reading shown as full. The full reading is the total sum of all the statistics from the last time
the data was reset. Note that this can differ from the sum of all the individual deltas as this is the reading
from Reset to current.
In the readings shown, we can see the top delta has a reading that shows 3.42s for RA Elapsed. RA
Elapsed represents the time spent in rule assembly. These results can skew performance readings as
rule assembly, also known as first use assembly or FUA, is very expensive but only occurs once. This is
evidenced by the results we see here. The total elapsed time was 5.95s of which 3.42s was spent in rule
assembly. If we didnt have the additional 3.42s our total time would be less than half the measured
number. It also affects the other readings such as the total rules executed, the reads from the database
and various I/O counts.
In order to obtain good results, we should run through the process once to ensure all rules have been
assembled. I did not do that here in order to demonstrate the impact this has on performance readings.
513
Clicking on either delta or full will show us more details about this reading. There are many different
results available to us for analyzing the performance. Theres no magic number when it comes to these
results. In one situation a result of 10 minutes may be acceptable where in another anything over 100
milliseconds is considered too slow. It is up to us to work with the LSA and the business to determine
what is an acceptable result for each step of the process.
514
DB Trace
The DB trace tool is useful in tuning the application if there are any database performance issues. DB
Tracer must be run if PAL readings indicate performance issues in the Database operations. DB tracer
can trace all the SQL operations like queries or commits that are performed in PRPC.
Accessing the DB Trace tool
Like the performance analyzer, the DB tracer is available from the performance button the developer
studio toolbar, the system management application and the performance landing pages. Well do this
demonstration using the performance landing pages.
Configuring the Options

To configure the DB Trace tool, click on the Trace Options button.
515
This opens a window that lists all the possible events to trace. By default, all of them are selected. If an
event does not apply to a situation, it should be removed from the list to streamline the results. We also
have the option to generate a stack trace. Generating the stack trace is an expensive process and
should only be used when required. In most situations, well want to accept these defaults as their
shown.
Running DB Trace
To run the tracer, we just need to click the green play button. After performing our steps, we can click the
red stop button to complete the trace.
After stopping the tool, the table is updated with the results for all the PRThreads it traced. Well want to
identify the results for the thread corresponding to process where we performed our work. In this case,
the first item PS1. When in doubt, look for the largest size. It is most likely the one we want.
The results are a tab delimited file so they can be opened using any spreadsheet program, such as Excel
to then review the DB Trace findings.
516
Performance Profiler
The third tool in our Performance landing pages, the Performance Profiler is like a hybrid between the
tracer and PAL.
We run the Performance Profiler the same way we run DB Trace, by clicking on the green play icon,
performing some actions and then clicking the red stop.
Just like DB Trace, we want the record that matches the one where we did work. Again, this is most likely
the largest one. The difference here is when we open the file, unlike the DB Trace, which was stored as
a tab delimited TXT file, the data associated with the profiler is stored as a simple CSV.
The profiler can show us the CPU time and wall time across a series of transactions. It is useful when
determining which part of the process might be having performance issues, or identifying the particular
step of a Data Transform that might have a performance issue. This should be run in conjunction with
PAL to narrow down both the specific step (profiler) and the cause (PAL).
517
Pega Log Analyzer

The Pega Log Analyzer, also known as PLA, is a standalone application that can combine and format the
PRPC logs. This allows for easier insight into the behavior of the system. PLA can be downloaded from
the Pega Exchange area on the PDN.
Once PLA is launched, we need to upload the Pega, Alert and GC log files from the system. PLA will
format these logs and provide us a summary table separates out each day. We have the options to
export a single day to Excel or, using the buttons above, export the entire result set.
The copy in Excel provides us with summaries for each of the alert, exception and garbage collections.
Using these summaries we can identify the critical events that cause poor performance and address
them.
518
Log Usage
Unlike the PAL tool, which shows data for one requestor only, the Log-Usage reports shows overall
system activity. Log Usage reports are normally accessed in SMA.
Based on the number of interactions, the Log Usage shows various Performance Analyzer counts of
system usage. This enables the system administrator to see what activities are going on from a systemlevel perspective.
For example, if a user complains that the system is slow at 1 p.m., the system administrator can choose
Start and Stop parameters to highlight that time and see whether there was a sudden spike in the number
of users, or in activities run by existing users, or some other occurrence that might cause a system
slowdown.
519
Autonomic Event Services (AES)

Autonomic Event Services, also known as AES, is a standalone application that can be used to monitor
the performance status of one or more PRPC instances running in an enterprise deployment. AES works
with any version of PRPC (5.x, 6.x, 7.x) and can even monitor a combination of versions.
The AES Enterprise Health console provides the current status on key system functions indicating
normal, warning, and critical conditions for the following:
1. Number of active requestors
2. Number of agents running
3. Percentage of JVM Memory being used
In order to accomplish this, PRPC sends data to AES through a series of SOAP calls. AES picks up this
data and can perform various functions with it.
Consolidates and summarizes all the Pega log files.
Formats the alerts and errors.
Produces a scorecard.
Sends emails.
Suggests recommended actions.
Provides reports for performance patterns and trends.
AES aggregates the most serious alerts and exceptions into work items for use in a work flow and
assigns them for diagnosis and resolution. Each work item can be transferred to a different operator, has
SLAs defined for the work item and provides reports for tracking the work items.
AES is covered in detail in another course.
520
Ensure the System is Following the Guardrails

We already know the guardrails are designed to help us produce an easy to maintain system, but they
also help with performance. This is one of the reasons the guardrails are so important. By adhering to
the guardrails, we ensure were building an efficient system.
PRPC provides several means to monitor how well were adhering to the guardrails. Lets review each of
them now.
Compliance Score
The compliance score is a new feature available in Pega 7 and is available to be installed in previous
PRPC versions. The compliance score is a weighted measure that provides transparency to how well a
system is adhering to the guardrails.
To access the compliance score, we select it from the Guardrails sub-menu of the Application menu. This
provides us with the compliance score landing page.
521
The first section of the landing page allows us to apply filters to the results, so that we can narrow down
the possible trending situations. In most cases we shouldnt need to use these and can just leave the
filters wide open to see the score across all possible rules.
Similarly, the last section of the landing page contains a view to how alerts have trended over the last four
weeks. These can be helpful in identifying the impact of correcting warnings and how the system is
trending overall. In this section, we should see the number of alerts reduce as the warnings get
corrected.
The most important part of this landing page is the compliance score (identified with a 1). The
compliance score is a calculation of the total number of rules in the system with warnings, weighted by
their severity and justification state, as compared to the overall total number of rules. This score is based
on all the rules available to this application, except the properties and any rules in Pega provided rulesets.
This is because the number of properties or Pega provided rules in comparison to the rest of the rules in
the system can greatly skew the percentages. By eliminating these rules, the system focuses on rules
that have warnings only compared to rules that could have had warnings.
The row of results below the compliance score displays the data used to generate the compliance score
(identified with a 2). This represents the total number of rules in the system as they compare to the
subset of them that have warnings. Here we can see the percentage of rules without warnings, the total
number of rules used to provide that percentage, and two sets of numbers that represent how many rules
have warnings and how many have unjustified warnings. These later two are links to reports that list the
rules, providing us an easy way to access these rules and repair the cause of their warnings.
We wont go into the exact formula used, but it is important to point out that both justified and unjustified
rules affect this score. So the only way to ever get a full 100 is to have no rules with warnings. Among
the rules that do have warnings, our best option is to fix the rule and remove the warning. Otherwise we
should provide a good justification why this rule requires breaking the guardrails. This provides future
developers with information about the reason this rule was written outside the guardrails, as well has
having the added benefit of improving our compliance score.
If the system does not already have this new feature available, it can be obtained from the Pega
Exchange area of the PDN.
522
Guardrail Reports
Aside from the compliance score, the system also provides a series of reports that can be used to narrow
down rules that have warnings, and therefore are outside the guardrails. The reports are accessed from
the same landing pages as the other guardrails. The help files provide details on each of these reports,
but lets take a high level look at their uses.
Summary
The summary report provides at a glance the state of the system. With this report we can see the total
number of rules with warnings as well as the total number of warnings. In this example, we can see there
are 32 rules with warnings, but there are 37 warnings total. This means some of the rules have more
than one warning. This report uses a color coding system to indicate the severity of the warnings. Red
indicates the most severe. Orange are moderate warnings and Yellow are cautionary. At an absolute
minimum well want to correct the severe warnings, but we should review all the warnings in the system to
see how many of the moderate and cautionary warnings can also be removed.
Expanding any of the rows in the report allows us to drill down into the individual rules that contain these
warnings.
All Warnings
The all warnings report provides the same information as the Summary report, but in an easy to read
tabular form. This report provides us the means to sort on any of the column headers, such as by
severity or by rule type so that we can group together the warnings we want to address.
523
Charts
Just like the other reports, the charts report provides the same information. By using the charts report we
can provide visual comparisons of different warning types. This gives us another means to organize the
approach to addressing these warnings.
Alternative Reports
The guardrails landing page is not the only place in the system to obtain a view of the warnings in the
system. The Application Inventory landing page contains another report that can be used to identify rules
with warnings and address them.
524
Heat Map
The heat map report also provides us the means to view rules with warnings. First we need to switch the
shading option to number of warnings. Once this has been selected, the system displays the categories
with warnings, shaded according to the percentage of rules in that category that have warnings. Ideally,
we would like to see all white here, indicating there are no warnings, but that is not our case.
Hovering over any shaded category, we can see the number of rules with warnings, as well as rightclicking on the category brings up a detailed report drilled down to the list of rules with warnings. This
report is very useful for identifying categories of rules that are outside the guardrails. In this case, flows
are our most non-compliant so we should focus our concentration on repairing the 16 warnings in flows
first.
525
Best Practices for Performance

Theres no magic formula for performance. Every system needs its own unique blend of tuning to
achieve the best possible performance. However, there are some best practices we can follow to
improve the performance of any system.
Cleanup the Clipboard

The size of the clipboard directly represents the memory footprint of the user. By making sure we clean
up unused pages we can help keep the memory lean which in turn reduces the risk of out of memory
errors. As we develop the processes and rules of the system, we need to be aware of every page we
create, what its used for, and when its usefulness is complete.
Examples of these types of pages are temporary ones used for interfaces, temporary pages used for data
mapping, and temporary pages used to power controls on the user interface.
Minimize the Number of Rules

Having too many, unnecessary rules in the system not only has an impact on maintenance, but can also
have an impact on the systems performance. Having a large number of inflight rules has the potential to
exceed the rule cache, causing constant cache pruning to occur. We should always look for ways to
reuse existing rules and specializing only as needed to keep our rules lean. This allows us to tune the
cache for the rules that are necessary to run the system.
As an additional bonus, by eliminating unnecessary rules, we minimally reduce the size of the rules
database. This may not seem like much, but when it comes to performance, every little bit helps.
Minimize the Number of Ruleset Stacks

Similar to reducing the number of rules overall, by minimizing the number of ruleset stacks we help to
keep the rule cache clean. In PRPC, every unique ruleset stack receives its own copy of the rule cache.
In most cases, this is desired, but there is one unique ruleset that often does not need to exist. This is the
personal ruleset.
In PRPC, every operator who has Rule Check-out enabled in their operator record, as shown here,
receives a personal ruleset. This personal ruleset is what holds the copy of a rule when its checked out.
526
We can identify a personal ruleset if the operator has a ruleset with the same name as their operator ID
followed by the @ symbol. Since these rulesets sit at the top of the ruleset stack, this creates a unique
rule cache applicable to only this one operator.
So, as a best practice, this should be disabled for every operator who is not actively checking out rules.
In most cases, this applies to every operator, even developers, outside of the development system.
This reduces the number of unique ruleset stacks, thereby reducing the number of unique rule caches
which in turn reduces the overall size of the rule cache.
527
Dedicate a Back-end Processing Node

Whenever possible, one or more separate nodes in the cluster should be set aside for back end
processing. Both agents and listeners can be dedicated to only a few nodes in the system. This allows
the other nodes, where users log in, to devote nearly 100% of their processing to the user experience.
The dedicated nodes are then able to process their work without impacting the end users.
If it is not possible to dedicate a separate node, then any back end processing should be delayed to run in
the non-working hours if it is not required to be near real time. Examples of back end processes that can
often be delayed are updates to external systems or pulling daily refreshes of information.
If We Dont Use it, Turn it Off

On the same topic of agents and listeners, we should also look to eliminate any of them that are unused.
PRPC has several agents and listeners that ship out of the box as starting points, if a project requires
them. The key part there is the if required. Ive often encountered systems where every agent and
listener was enabled, just because it was available.
If were not using a feature, it should be disabled. For example, let say our system doesnt send any
correspondence. In that case, the agent that sends correspondence, SendCorr, should be disabled.
By eliminating these unused agents, we may not notice a large improvement, as agents are fairly
performant when there is nothing in their queue. But as with everything with performance, its the little
things that add up.
Different Performance Needs for Development, QA and Production

While our primary target for performance is production, after all, it is the only system the end users will
interact with, we shouldnt ignore our own needs for performance in development and QA. All the best
practices throughout this lesson need to be applied to every environment in order to ensure we have the
best possible system. Only by ensuring the development system has good performance can we ensure
the production system will have great performance.
Conclusion
So what did we all learn? We already knew that performance is key to the success of any project. In this
lesson, we covered different tools we could use to identify and measure the performance of the system.
We discussed various reports we have in the system to identify how closely were adhering to best
practices, and we outlined a few best practices that can be applied to any system to improve its
performance.
528
System Tuning and Maintenance

Introduction
PRPC systems are fairly robust and are relatively self-maintaining. However, with a little tuning and some
occasional maintenance we can make great systems. In this lesson, well discover how to tune some of
the various caches in the system, how to archive old work and some recommended tasks that should be
performed on a regular basis.
Tune the rule cache
Setup the purge and archive agent
Tune the Rule Cache

The size of the rule cache directly relates to the amount of memory used on the system. Having too small
of a cache results in the cache needing to prune itself. This results in poor performance as the system
constantly needs to remove one cache entry for every new one it needs.
Viewing the cache details
From the System Management Application, we can view the current rule cache from the Rule Cache
Management page under the Administrations category. There is a lot of good information here, all of
which is explained in the help files, but what were interested in is the values for items that have been
pruned. Having pruned values indicates that the rule cache has been exceeded at some point. This
doesnt necessarily mean there is a problem just that we need to do more investigations. This is
especially true in development environments where there is a high turnover in the number of rules
instances.
529
In order to determine if this is a one-time occurrence or an ongoing problem, we will need to clear the
cache by clicking the Clear Cache button and then thoroughly run the system. A good time to do this
test is during load testing as the load test will ensure the system has been thoroughly executed.
Once the system has been fully run, with multiple scenarios representing the current business case, we
can review this report a second time and validate if instances are still being pruned.
If there are still instances being pruned, our next task is to see if we can reduce the overall rules in the
system. The lesson on designing for performance and reuse and specializations lessons both provide
information on how to reduce the overall number of rules in the system. This should be done and the
process of clearing the cache should also be done. Then we should re-run the system in order to evaluate
if the rule cache still needs to be tuned.
If all of these actions have taken place and we still are encountering pruned records, it may be necessary
to increase the cache. Increasing the cache has its own impact on performance by increasing the
systems possible memory footprint, which is why this approach should only be taken once all other
possible solutions to reduce the overall number of rules have been exhausted.
Tuning the rule cache involves setting the instancecountlimit settings in prconfig.xml. There is information
on how to achieve this in the help file topic Understanding caches.
530
Setup the Purge and Archive Agent

One of the important tasks for maintenance is to ensure we archive old work objects out of the system.
Most businesses only need to keep old work around for anywhere between one to seven years. By
cleaning out the old work objects that exceed this limit, we can keep the work tables lean and allow the
system to achieve optimal performance.
Configuring the Purge and Archive wizard
PRPC provides an easy to setup wizard for establishing an archival strategy called the Purge and Archive
wizard. To launch this wizard, we select Configuration from the Purge/Archive sub-menu of the tools submenu under the system menu.
The first step of the wizard requests for the work pool that we want archived. Remember that work tables
are mapped to work pool entries, so this is why individual classes are not listed here. After we select a
work pool, well provide a name for this configuration and select next.
531
The next screen allows us to specify specific classes within that work pool. In most cases, well want to
select all the classes of the work pool. Rarely do we require archiving the classes at different intervals.
Selecting next brings us to the next step of the configuration.
On the third step, we specify how many days old an object needs to be in order to get archived. In this
case, were going to specify 365 days since were setting up to archive anything over one year old.
Selecting next brings us to the last step of configuration.
At this point, we can review what weve configured and if its acceptable, click finish. Its that easy to
setup an archival strategy.
One thing Id like to point out is the word resolved. Its important to note that this tool only archives work
that has been seen through to completion and does not impact any inflight work. This is fine in
production, but often we wont find objects to archive in development or QA as these are rarely worked
through to completion. Work objects used in these environments for testing should be either completed
or cancelled so that the archive wizard can clean them up too.
532
Scheduling the purge and archive agent

Now that weve configured what were going to archive, we now need to establish when we want to
archive it. Scheduling the wizard can be achieved from the same Purge/Archive sub-menu as the
configuration.
This landing page allows us to set up how we want the archive agent to behave. An important item to
note here is the option to either Archive and Purge, or just Purge the identified work objects. In most
cases, we will only need to use Archive in production. In Development, QA and other lower environments
we can often just select Purge to avoid the overhead of producing the archive files.
Other information we set up deals with the number of items to process during each run and how often to
process. In most cases, it is sufficient to retain the default 30 day cycle. However, check with the
business to confirm their requirements before implementing.
More information on the Purge and Archive wizard, including the details on accessing the archive files,
can be found in the help files.
Conclusion
Weve just covered two of the most important maintenance tasks, keeping the caches trimmed and
purging old work. But theres still other things processes we can implement to achieve a clean, lean
system.
Every project needs at least one person who acts as the system administrator. This person should be
responsible for these additional tasks and the overall maintenance of the system. The kinds of tasks
expected of this person include:
Working with the database administrator to identify database indices to be tuned for this specific
application.
Using the performance tools available and making sure developers are adhering to the
performance best practices.
Installing hot fixes and updates in the system.
Monitoring AES (if installed) and addressing any alerts.
Rolling log files off the server to keep the physical disk space lean.
533
Migrating an Application
Introduction
Welcome to the lesson on application migration. In this lesson we will look at the features and tools
available to package, export, and import applications.
An application is typically packaged or exported when we want to move it to another system, for example
when migrating among development, testing and production environments.
The package, export, and import features can be found under distribution in the application menu.
Associate Data Instances to Rulesets
Use the Application Packaging Wizard
Configure a Product (RAP)
Use the Export Gadget
Use the Import Landing Page
534
Associate Data Instances to Rulesets

By definition, a ruleset corresponds to a collection of rules and does not include data instances. However,
to assist in application packaging and migration it is possible to associate data instances with a ruleset.
As we create data instances of certain classes, they are automatically associated with the ruleset in which
the current application is defined. The same is true if that data instance is created by a wizard.
It is possible to change the associated ruleset or clear it so that the data instance is not associated with
any ruleset. Clearing the associated ruleset results in a warning since it is a best practice to always have
an associated ruleset for each data instance.
Associating a ruleset with a data instance does not affect or restrict any runtime behavior. The data
instance remains available to all applications regardless of the associated ruleset. If the data instance
was imported from another system, it might even reference a ruleset that doesnt exist on the current
system.
535
Use the Application Packaging Wizard

The output of the Application Packaging wizard is a Product rule. The Product rule is an instance of the
Rule-Application-Product and is therefore sometimes called a RAP. Lets start the wizard by selecting
DesignerStudio > Application > Distribution > Package.
First we need to select the application we want to package and the ruleset with version we want to create
the product rule in. The drop-down contains the applications visible to us on the current system.
This page lists the application selected and the chain of built-on applications ending with the base
PegaRULES application.
Depending on the applications present on the target system, we may not need to include the entire stack
in our package.
The next page lists all Organizational elements associated with our application.
536
This page lists the Access Groups associated with our application.
The next page lists the Operators associated with the application. We want to include all so we leave it as
is and click the Next button.
537
This page lists the Workbaskets associated with the application.
The next page lists the Work Groups associated with the application.
This page lists the Data Tables associated with the application. We can uncheck any that we want to
exclude from the application package.
538
This page lists java code archives that are used by our application.
The next page lists Database and Database Table instances associated with the application in the
system.
This page lists all the Integration Resources defined in the system. By default, the ones associated with
one of the application rulesets are selected.
539
Click the Finish button to create the Product rule. The final page of the wizard provides the following
options.
Preview shows the content of the archive that is created by the Product file.
Modify opens the Product rule to manually add or remove instances.
Export exports the Product rule to our local computer as an archive.
Migrate starts the Product Migration wizard. The Product Migration wizard lets us automatically
archive, migrate, and import a Product rule to one or more destination systems. See Pega 7 help
for more information on the Product Migration wizard.
If we want to generate the archive as we go through this wizard we need to lock the rulesets that are
referenced directly or indirectly in the Product rule before using the Export button. Typically the Product
rule itself resides in a referenced ruleset and at least that ruleset was open up to this point. The archive
can be exported at any point from the Product rule form.
The wizard names the file after the application, in our case Purchasing. The version is set to the date and
time it was created.
540
Configure a Product (RAP)

The Product rule identifies the components that make up an application. Product rules can be found in the
SysAdmin category in the Records explorer.
The Product has a version and must be placed in a ruleset which has direct or indirect prerequisites
which includes the rulesets and versions that we want included in the Product.
The Contents tab identifies the applications, rulesets, data instances and other objects that make up the
application.
The Applications to Include section specifies the application rules that identify the rulesets and versions
to be included in the archive. Using this option eliminates the need to specify the individual rulesets and
versions in the Rulesets to Include section. The order of the applications in the array is not important.
Select Include Associated Data to include the data instances associated with the rulesets in this
application. Selecting this prevents us from having to include the data instances as individual instances
below.
Specify rulesets that are not part of an application. The rulesets can be entered in any order. During
import the system determines a valid order to load the rules.
Use the Minimum Ruleset Version and Maximum Ruleset Version fields to define a range within a major
version that we want to include in the product. Leave both fields blank to include all versions. Select
Exclude Non Rule Resolved Rules to exclude rule types that are associated with a Ruleset but not with a
version, for example, class and application rules.
It is possible to include instances from any class. During upload, data instances already present are by
default not overwritten. However, we have the option to overwrite existing instances if desired. In addition
to concrete classes, it is also possible to enter an abstract class that has concrete subclasses.
Use the ListView Filter and When Filter fields to specify a list view or when rule to filter the class instances
to include. It is not possible to use both a list view and a when rule in one row of this array. Leave the
fields blank to include all instances of the class.
Use a list view if the filter criteria depends only on single value properties that are exposed in the
database and the when rule if the filter criteria involves calculations or properties that are not exposed as
database columns.
541
Select Include Descendants to include instances in classes that are subclasses of the class entered in the
class field. If this option is selected the ListView Filter and When Filter are ignored.
By default, all descendant classes are included when we select Include Descendants. Use the Exclude
Classes field to enter the names of decedent classes you do not want to include. It is possible to enter
more than one class using a comma (,) to delimit the names.
Add specific class instances to include in the Individual Instances to Include section. We can specify any
class that contains instances to be included as part of our Product.
Complete the next section to include JAR files within the product archive.
Click the Query Jars button to list available JARs to include. Add JARs files to include in the product.
The date in the Creation Date field displays on the destination system before the archive is imported. The
date value entered persists even when the file is copied or renamed. Enter a text description of the
contents of this file in the Short Description field. This value also appears on the destination system
before the archive is imported.
Select 5.4 Compatibility to create an archive that can be imported into a v5.4 system or earlier-than-v5.4
system. This setting affects only the format of the output file. It does not assure backward compatibility of
the contents of the file.
542
Select Allow Unlocked Ruleset Versions if we want to be able to include unlocked ruleset versions.
Click the Preview Product File to review the contents of the product definition before exporting or
migrating it.
Click the Create Product File button to create an archive in the ServiceExport directory on the current
application server node. Typically the Product rule itself is in a ruleset included in the product, which
means that the ruleset needs to be locked before the archive can be created.
On the Installation tab we can identify an HTML rule to be displayed at the end of the import operation for
this product rule. For example, it may display further post-import instructions to the person who imported
the archive.
543
Use the Export Gadget

Use the Export gadget found under Pega > Application > Import and Export > Export to export an
application or part of an application.
The user must have the @baseclass.zipMoveExport privilege to use the Export tab. The privilege is part
of the SysAdm4 role.
Select Export Mode to define the scope of the contents of the exported archive.
By RuleSet/Version creates an archive containing all the rules in a ruleset and version or all
versions.
By Product creates an archive containing rules and data defined by an existing product rule.
By Patch creates an archive containing rules and data defined by an existing Product Patch rule.
Note that the Product Patch rule is deprecated, use Product rule instead.
Archive On Server allows us to select download a file already on the server.
Enter a file name for the archive in the File Name field. Many special characters are allowed, but we cant
include spaces or equal signs.
Click the Perform Export button to create the file.
The Zip file created link provides access to the new file. The file is typically placed in the ServiceExport
subdirectory of the server.
If errors are reported, click the Total Number of Errors link to see the error messages.
544
Use the Import Landing Page

The Import gadget found under Pega > Application > Import and Export > Import let us import the
contents of an archive on the destination system.
The user must have the @baseclass.zipMoveImport privilege to use the Import tab.
Select the archive to upload. By default, it is not possible to upload a file larger than 25 MB. For larger
files, use FTP or another means to place the file in the ServiceExport directory. The maximum file upload
size is defined in the Initialization/MaxiumumFileUploadSizeMB in the prconfig.xml file. This field can be
left empty if the file to import already exists on the server. Click next.
Select a file from the server to import. If a file was uploaded it will be selected by default.
It is possible to view the contents of the file by using the Show Content Details button.
Select Enable advanced mode to provide more granular control over the import process if we want to be
able to select individual instances in the archive.
Click next to start the import. The system attempts to upload the rules in an order that minimizes
processing.
After processing completes, adjust access groups or application rules to provide access to the new
rulesets, versions, and class groups as needed.
545
If we import rules in a ruleset version that users already can access, they may begin executing them
immediately, possibly before other rules in the same archive are present. Similarly, declarative rules begin
executing immediately, which means that they might fail if the elements or properties they reference
havent been uploaded yet. This needs to be planned for when an archiveis imported on a system with
active users.
Conclusion
In this lesson, we explained features and tools available to simplify the packaging, exporting, and
importing of an application and components of an application.
Now, we should understand the impact of associating a data instance to a ruleset and how the Product
rule, also known as RAP, is configured. We should also know how to use the Application Packaging
Wizard, Export and Import gadgets.
546

SSA 716 StudentGuide 20150211

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

SSA 716 StudentGuide 20150211

Enviado por

Direitos autorais:

Formatos disponíveis

Senior System Architect

STUDENT GUIDE (v. 7.1)

Completing the Exercises...................................................................................................

Working with Branches......................................................................................................

Enterprise Class Structure.docx........................................................................................

Reuse and Specialization....................................................................................................

Case Management Under the Hood.................................................................................

Case Lifecycle Management..............................................................................................

Creating and Editing Flows.................................................................................................

Advanced Flow Processing.................................................................................................

Building a Solid Foundation...............................................................................................

Controlling Data with Properties.......................................................................................

Source Your Data With Data Pages...................................................................................

Introduction to User Experience.......................................................................................

Building the User Interface................................................................................................

Building Responsive User Interfaces................................................................................

Understanding Available Controls....................................................................................

Dynamic User Interface......................................................................................................

Automating Business Policies.........................................................................

Get Next Work.....................................................................................................................

Delegating Rules to the Business User.............................................................................

Creating Business User Reports........................................................................................

Data Modeling in Reports..................................................................................................

Data Visualization using Charts.........................................................................................

Error Handling and Debugging..........................................................................................

Configuring a SOAP Connector.........................................................................................

Setup a SOAP Service..........................................................................................................

Setup a File Service and Listener.......................................................................................

Interacting with an External Database.............................................................................

Controlling Access to an Application................................................................................

Authentication Using LDAP................................................................................................

Designing for Performance................................................................................................

System Tuning and Maintenance......................................................................................

Module 01: Orientation

Completing the Exercises

Loading the Exercise Solution

Module 02: Application Design

This lesson group includes the following lessons:

Starting a Pega 7 Application

Working with Branches

Enterprise Class Structure

Reusability and Specialization

Starting a Pega 7 Application

Describe the purpose of the Application Express

Decide on an appropriate Application Structure

Use the Advanced Configuration

Add Case Types and Data Definitions

Describe the Purpose of the Application Express

Decide on Appropriate Application Structure

Use the Advanced Configuration Options

Add Case Types and Data Definitions to an Application

01 is the major version number

02 is the minor version number

03 is the patch number

Ruleset and Ruleset Version

Access of Role to Object

Utilize the Check-out and Private Edit Feature

Use the Development

If we want to delete a check

Explain Ruleset Prerequisites

All ruleset versions on this list

All ruleset versions listed as prerequisites for those ruleset versions

Explain Ruleset Lists

Explore Best Practices