c1791 Exercise Guide

Lead System Architect 8.
3
8.3.1
Exercise Guide
© 2019
Pegasystems Inc., Cambridge, MA
All rights reserved.
Trademarks
For Pegasystems Inc. trademarks and registered trademarks, all rights reserved. All other trademarks or service marks are
property of their respective holders.
For information about the third-party software that is delivered with the product, refer to the third-party license file on
your installation media that is specific to your release.
Notices
This publication describes and/or represents products and services of Pegasystems Inc. It may contain trade secrets and
proprietary information that are protected by various federal, state, and international laws, and distributed under
licenses restricting their use, copying, modification, distribution, or transmittal in any form without prior written
authorization of Pegasystems Inc.
This publication is current as of the date of publication only. Changes to the publication may be made from time to time
at the discretion of Pegasystems Inc. This publication remains the property of Pegasystems Inc. and must be returned to
it upon request. This publication does not imply any commitment to offer or deliver the products or services described
herein.
This publication may include references to Pegasystems Inc. product features that have not been licensed by you or
your company. If you have questions about whether a particular capability is included in your installation, please
consult your Pegasystems Inc. services consultant.
Although Pegasystems Inc. strives for accuracy in its publications, any publication may contain inaccuracies or
typographical errors, as well as technical inaccuracies. Pegasystems Inc. shall not be liable for technical or editorial errors
or omissions contained herein. Pegasystems Inc. may make improvements and/or changes to the publication at any time
without notice.
Any references in this publication to non-Pegasystems websites are provided for convenience only and do not serve as
an endorsement of these websites. The materials at these websites are not part of the material for Pegasystems
products, and use of those websites is at your own risk.
Information concerning non-Pegasystems products was obtained from the suppliers of those products, their
publications, or other publicly available sources. Address questions about non-Pegasystems products to the suppliers of
those products.
This publication may contain examples used in daily business operations that include the names of people, companies,
products, and other third-party publications. Such examples are fictitious and any similarity to the names or other data
used by an actual business enterprise or individual is coincidental.
This document is the property of:
Pegasystems Inc.
One Rogers Street
Cambridge, MA 02142-1209
USA
Phone: 617-374-9600
Fax: (617) 374-9620
www.pega.com
DOCUMENT: Lead System Architect 8.3 Exercise Guide
SOFTWARE VERSION: Pega 8
UPDATED: 12 2019
CONTENTS
Exercise: Designing Pega for high availability 1

Exercise: Recognizing Pega application opportunities 5
Exercise: Designing the case hierarchy 7
Exercise: Designing the subcase hierarchy 10
Exercise: Initializing the Event Booking Application 13
Exercise: Implementing the Case Type life-cycles 16
Exercise: Promoting Reuse With Relevant Records 24
Exercise: Case specialization and extensibility 26
Exercise: Designing an email application 28
Exercise: Leveraging the email component application 29
Exercise: The Hotel and Hotel Proxy applications 36
Exercise: Creating the REST integration interface 46
Exercise: Adding a built on application 55
Exercise: Implementing an effective data model 65
Exercise: Data driven behavior 71
Exercise: Enhancing the Pricing Data Model 73
Exercise: Exposing integration using a data type 77
Exercise: Extending an industry foundation data model 91
Exercise: Routing weather cases to facility coordinators 92
Exercise: Designing Get Next Work 100
Exercise: Defining the authorization scheme 104
Exercise: Identifying and mitigating security risks 128
Exercise: Analyzing Security Event Logs 130
Exercise: Defining a reporting strategy 135
Exercise: Optimizing properties for report performance 137
i
©2019 Pegasystems
Exercise: Using a database index for report performance 141
Ex: Contact Hotels not contacted recently 146
Exercise: Background processing 155
Exercise: Designing Pega for the enterprise 169
Exercise: Defining a release pipeline 171
Exercise: Monitoring the guardrail compliance score 173
Exercise: Estimating hardware requirements 176
Exercise: Handling flow changes for cases in flight 177
Exercise: Extending applications to other areas of the business 185
Exercise: Leveraging AI and robotic automation 196
ii
©2019 Pegasystems
Completing the exercises
When learning new concepts or skills, there is no substitute for learning by doing.
This course includes exercises that provide practical, hands-on experience to help you apply your new
skills immediately.
The exercises help reinforce the learning objectives of each lesson. They include a scenario that
describes a business problem that needs to be solved and an overview of the tasks you need to
perform to complete the exercise.
To help you complete the exercises, two levels of support are provided:
l Your Assignment — specifies the high level steps you need to perform to solve the business
problem provided in the scenario.
l Detailed Steps — shows the series of steps needed to complete the exercise.
It is our goal that you can complete the exercises using the scenario and the tasks noted in your
assignment. Use the detailed steps to check your work, or as a last resort to complete the exercise.
Exercise environment
The exercise system for this course is available online and accessed through the Open Exercise
System link on each exercise page. Use the credentials provided in each exercise scenario.
Click the Open Exercise System link to log in to your exercise environment. Enter the credentials
provided in the scenario. After you complete an exercise, log out of the exercise environment. Ensure
you use the correct credentials to log in for each exercise.
Note: The exercise environment provides a pre-built Pega Platform application configured specifically
for this course. This allows you to focus on the key tasks of each exercise without having to complete
ancillary tasks.
Exercise guide reference

While individual exercises are included for each lesson online, you may find it useful to download and
print out the complete exercise guide. This is available in the related content section on the right side
of this lesson.
iii
©2019 Pegasystems
Front Stage Event Booking business scenario
Front Stage Event Booking assists customers with booking large-scale, high-profile corporate and
musical events, hosting between 5,000 and 18,000 guests per event. Front Stage has been in business
for 30 years, and uses a range of technology. Some technology is old, such as the reservation system
that runs on a mainframe. Some technology is new, such as the most recent mobile application that
helps sales executives track leads.
Front Stage relies on the Information Technology (IT) department to maintain legacy applications, as
well as to support their highly mobile sales organization. In the past, IT created applications that were
difficult to use and did not meet the needs of the end users of these applications. In some cases, the
new application slowed the business instead of making the users more productive.
Front Stage is aware of several smaller event booking companies who are using newer technology to
gain a competitive edge. These smaller companies have started to cut into the corporate event booking
segment, and Front Stage sees a dip in sales in this segment as a result. Front Stage's CEO, Joe
Schofield, recognizes that if Front Stage avoids investing in technology to transform the way they
operate, then Front Stage will be out of business in two years.
Your mission: Architect a Pega solution for Front Stage

During this course, you create an event booking solution for Front Stage. Using the business scenario
document, you apply what you learn in each lesson to design the best technical solution to meet Front
Stage's vision of digital transformation.
Note: Each exercise includes a unique scenario and assignment that identify the specific business
problem to address. Before you attempt each exercise, review the scenario and assignment to
understand the goal of the exercise.
iv
©2019 Pegasystems
Exercise: Designing Pega for high availability
Scenario
Front Stage expects to provide users with 99.95 percent uptime of the application. Sales executives
need to be able to access event booking information at any time. Because events sometimes occur on
weekends, facilities coordinators need to initiate the weather prep case on a Friday or Saturday
evening. Even on the weekends, the number of active users in the application can be high. Front Stage
configured three application servers and a load balancer to handle failover.
Your assignment
Design the Front Stage application to support high availability (HA). This task includes:
l Describing configuration needed to manage HA settings from DEV Studio
l Describing required environment architecture
l Determine the method of shared storage
l Defining the mechanism to monitor nodes
In the Alternate approaches section, describe any differences for designing for HA in a Pega Cloud
environment.
Solution detail
A highly available application includes these components:
l One or more load balancers
l At least two physical or virtual machines associated with each load balancer
l One or more shared storage repositories
l One or more fault-tolerant, highly available clustered databases
Additionally, as a part of planning for future server maintenance, you decide whether to use the
default slow drain method or configure your system to use the immediate drain method for when you
perform the quiesce process on a node.
1
©2019 Pegasystems
Though not required, single sign on provides a seamless experience to the user in the event of a server
crash or redirection of a user session during a server quiesce.
DEV Studio configuration

To support HA configuration from DEV Studio from multiple nodes:
l Enable the HA dynamic system setting (session/ha/Enabled)
l Configure users with high availability roles and privileges to modify cluster settings and quiesce
nodes by adding the PegaRULES:HighAvailabilityAdministrator role to the access group for the
admin.booking operator
l Configure the settingsource in the prconfig file to "merged" (<env
name="initialization/settingsource" value="merged"/>)
2
©2019 Pegasystems
Note: The PegaRULES:HighAvailabilityAdministrator role grants access to HA cluster administration and
quiesce investigation. Cluster administration in this context is access to cluster management and HA
settings that are accessible from the corresponding Pega 8 Platform landing pages. This role has the
pxHighAvailabilityAdmin and pxHighAvailabilityAdminQuiesce privileges.
Environment architecture
To support HA, you need to define your application architecture to support your uptime requirements
and provide redundancy in the event of a server crash or failure.
You need:
l A load balancer that supports session affinity (also known as sticky sessions)
l Two or more physical or virtual machines
l A database that support high availability clustering
Note: Session affinity configuration is only applicable when using slow drain for quiesce.
Shared storage
You can store passivated user sessions by either using file storage or database storage.
Use the database to store passivated requestors. Because the number of active users can be high,
storing passivated requestors in a file could impact performance of the JVM.
Note: When HA is enabled, database passivation is used as the default passivation method, in which
the database handles all storage requirements.
Node monitoring
You can monitor the status of nodes in the cluster using:
l The HA Cluster Management page in Dev Studio
Operators with the following roles can access this page:
PegaRULES:HighAvailabilityAdministrator
PegaRULES:HighAvailabilityQuiesceInvestigator
l Autonomic Event Services (AES)
l Mbeans integrated into your Network Operations Center (NOC)
Alternate approach
In a Pega Cloud environment, the behavior of the highly available application is the same as an on-
premise application configured for high availability. The primary difference is the quiesce strategy. In
the Pega Cloud environment, autoscaling could take a node out of service. The policy of the
environment determines which node to take out of service. As a result, Pega Cloud must use the
ImmediateDrain quiesce strategy to ensure seamless transition of one node to another. To switch
between slow drain and immediate drain you update the value of the session/ha/quiesce/strategy
prconfig setting to be either "slowDrain" or "immediateDrain" and then restart the server.
3
©2019 Pegasystems
Note: For immediate drain, do not use the HA Cluster Management page to quiesce a node. Use the
System Management application (SMA) and the JMX APIs instead.
For more information on the HA configuration options, see the Deploying a highly available system
article on the Pega Community.
4
©2019 Pegasystems
Exercise: Recognizing Pega application
opportunities
Scenario
You are having lunch with Scott Smith, the Facilities VP, when you learn that Front Stage's campaign
management has yielded unpredictable results over the past several months. Some prospects and
existing customers complained to Front Stage about unsolicited calls and offers that are irrelevant to
their business. Scott thinks that the company is missing the opportunity to engage prospects in a more
personalized way, and asks if Pega offers a solution that can help.
Scott describes process of creating and tracking sales leads. Front Stage sales consultants track leads
in a complicated spreadsheet and even though the spreadsheet does some automated calculations,
the sales consultants find the spreadsheet difficult to use. All of the sales consultants do their jobs a
little differently, and sales managers have difficulty calculating bonuses once the sales executive
completes the deal. Scott explains that the process of bringing in new customers is tedious and can
take weeks. The process of collecting necessary documentation is a manual and time-consuming
process.
Scott explains that once the prospect becomes a customer, supporting customer requests can also be
time-consuming. Depending on the reason for the customer call, the customer service representative
logs in to a windows application and two separate web applications to resolve the issue. This process
can take several minutes, and NPS scores continue to drop as a result. Front Stage customers also
complain of rigid call center menu options and being transferred between multiple representatives to
get a simple question answered.
After seeing the work done so far on the Event Booking application, Scott hopes that you can
recommend a solution to help with other areas of the business.
Your assignment
Recommend one or more solutions to Scott that can address the business challenges he shared with
you and transform Front Stage's business.
Solution detail
You explain to Scott that Pega provides a solution for each of the problems he describes. You also offer
to demo any of these application for him.
Pega Marketing and Customer Decision Hub

You recommend Pega Marketing and Customer Decision Hub to improve interactions with prospects
and existing customers for upselling and cross selling new services. Based on previous interactions,
Pega Marketing coupled with the Customer Decision Hub allows marketing teams to have context-
based discussions with existing customers based on previous interactions with Front Stage. You tell
Scott that the Customer Decision Hub allows the marketing teams to have context when talking to the
customer, providing animproved experience for the customer.
5
©2019 Pegasystems
Sales and Onboarding
You recommend Pega Sales Automation as the solution for managing lead and opportunity
management. You explain to Scott that Sales Automation can transform how Front Stage tracks and
manages leads through the sales process, and represents a vast improvement over using
spreadsheets. Similarly, Pega Onboarding guides the onboarding specialists through the process of
signing on a new customer and ensuring a consistent journey for new customers. You explain to Scott
that both of these applications add the structure Front Stage needs to optimize its sales and
onboarding functions, and can give Front Stage the faster time to market it needs to be the clear choice
for event booking services.
Pega Customer Service and Robotics

Scott describes the perfect conditions to use the Pega Customer Service application coupled with
Robotic Automation to transform the customer service experience. Depending on the type of work that
needs to be done in the legacy applications, the solution could either be Robotic Desktop Automation
or Robotic Process Automation. In either case, automating the work performed in legacy applications
allows the customer service representative to focus on the customer interaction instead of spending
time in the legacy applications while the customer is on the phone. Customer Service web self-service,
routing capabilities, and the ability handle interactions through multiple channels results in an
intelligent solution for managing customer interactions.
Solution alternatives
You could build your own solution to perform campaign management, lead and opportunity
management, onboarding, and customer service. However, this would result in a missed opportunity to
leverage Pega's applications to shorten time to market and ability to quickly deliver business value.
6
©2019 Pegasystems
Exercise: Designing the case hierarchy
Scenario
Front Stage has analyzed their requirements regarding hosting outdoor events, a.k.a., “weather prep”,
as well as the need to issue requests to different hotels to have a block of rooms reserved for that
event. Weather monitoring is included in the price of an event. Hotel booking is offered as an optional
service.
Your assignment
Analyze the key requirements for this application . The key requirements to consider are:
Processes – The tweather prep, hotel rooms request, and parking services functionality must be able
to execute independently .
Extensibility – It must be possible to extend the booking application to support different types of
venues.
Reporting – Reports for events should be defined that display revenue, cost, and profit (profit by event
type)
Data – Facilities users must not be able to see financial information.
UI – Customer quotation, event manager review, and hotel booking screens.
Review any viable alternative designs listing the pros and cons of each to produce a recommendation
on the most appropriate case structure for the application. Make a list of questions to ask Front Stage.
This may help produce a design that satisfies the current requirements and accommodate future
requirements with minimal refactoring.
Solution detail
An Event case with subcases is preferred because it:
l Fully satisfies the application locking requirements
l Make it easier to satisfy the UI requirement
l Helps make the application more accommodating to future requirements because subcases offer
more specialization options
Alternative approaches
Single Case with subflows
A single Event Case does not satisfy the processes requirements due to locking issues. The extensibility
and reporting requirements are easily satisfied, and the UI requirement may be satisfied with
independent data objects tracking each hotel. However, extra work is required to update the status of
each hotel.
7
©2019 Pegasystems
The data requirement could be satisfied by obfuscating the data for the facilities users, but this is not
an optimum solution for securing data.
The processes requirement, however, could not be fully satisfied due to case locking since this
prevents two users from updating the cases at the same time. Optimistic locking could be
implemented in order to remedy the problem, but this may not be an optimum solution since it may
detract from the user experience during case processing. This problem may be exacerbated if
additional services are added.
Single Case with subcases

A viable alternative is an Event top level case with subcases for services (currently Weather, Hotel, and
Parking). Modifying the default locking scheme to lock subcases independently of their parent would
solve the locking problem and allow parallel processing without interruption. This also lends
extensibility of the design as it may be easy to handle additional services. Consider handling the
coordination of the subcase resolution with the main case using this solution. Hotel subcases should
complete prior to the event starting, and the Parking case is active during the actual event and possibly
after. Also consider the effect of adding additional services in the future.
Multiple cases (with subflows/processes)

An alternative to the single top level event case is having a separate quote case provide the initial
quote. If approved, a peer Event case is created. This provides the possibility of only creating an event
case if the event is approved by the customer and executives.
Conditionally creating top level case (with subflows/processes)

Another alternative is providing a quote to the customer on the first screen using the New harness. If
the customer approves the quote, a top level case is created and is routed for approval. If the quote is
not approved, the quote dies and is never persisted.
Pros/cons of each approach

Design Pros Cons
Single case with l Simple Design l Locking is an issue
l BLOB potentially larger l Data visible to all cases
subflows
l No data replication Extensible l UI requirement for hotels is more
challenging
l Specialization options limited
Single case with l No locking issues with reconfigured l More cases created to process an
locking event (more database)
subcases
l Selected data propagation copies l Coordination of subcases with
only required data to subcases parent case more complicated
l Finer grained reporting by case
l More options on cases and
subflows
l UI requirement for hotels easy to
implement
8
©2019 Pegasystems
Design Pros Cons
l Extensible
l Can leverage dependency
management
l More options for specialization
Multiple cases l Finer grained reporting of quote l More cases created to process an
and event cases event (more database)
Conditionally l Case created only when Event l No record of rejected quotes

approved by customer
creating top level
case
9
©2019 Pegasystems
Exercise: Designing the subcase hierarchy
Scenario
The Front Stage application will be constructed with a single event case and subcases for each process.
There are additional decisions to make regarding the subcases.
Your assignment
Analyze the key requirements for this application to determine the best design for the subcases and
how the subcases will be started. For each subcase, review any viable alternative designs listing the
pros and cons of each. Produce a recommendation for the most appropriate subcase structure for the
application. Key requirements to consider are:
l Processes — The weather prep, hotel rooms request, and parking functionality must be able to
execute independently.
l Extensibility — It must be possible to specialize or extend the booking application to support
different types of venues.
l Reporting – Reports for events should be defined that display revenue, cost, and profit (profit by
event type)
l Data — Users must not be able to see financial information.
l UI — Customer quotation, event manager review, and hotel booking screens.
Solution detail
Weather subcase
The amount of additional database storage required to support a weather subcase, even if never
accessed by a user, is inconsequential. In keeping with object-oriented programming encapsulation
principle, it is desirable for the event case to delegate every task that is weather-related to a weather
case. By implementing weather as a separate subcase the potential exists to create a weather
application on which any application, not just the the Booking application,could be built.
Hotel subcase
When a customer selects the Hotel Services option, multiple hotel subcases should be spun off as
opposed to a single hotel subcase. A subcase per per hotel, is preferred because:
l Application locking requirements are fully satisfied
l UI requirements are easier to satisfy
l A subcase per hotel design has greater specialization potential
10
©2019 Pegasystems
Parking subcase
When the Parking and Shuttle Services option is selected by the customer, a single parking subcase
should be spun off.
Alternative approach analysis

Weather
Two options for the weather process are (1) to always create the weather subcase, or (2) conditionally
create the subcase.
Option 1: Always create a weather subcase
In this option, a weather case is always created. The delay to wait for the weather check date-time is
implemented in the weather case.
Option 2: Conditionally create a weather subcase
In this option, the precipitation is checked by the Event case on the intended date-time. The weather
subcase is created only if weather preparation is required. This option could be implemented in one of
four ways:
l Pause the Event case using a Wait shape until the desired date-time. Check the weather.
Conditionally create the weather case if percipitation is forecast.
l Within a parallel or spun-off flow within the Event case, check the weather at the desired date-time.
Conditionally create the weather case if percipitation is forecast.
l Queue the check weather task to an agent. The agent performs the weather check at the desired
data-time and conditionally creates the weather subcase if precipitation is forecast.
l Have a delayed Queue Processor check the weather at the desired data-time. Conditionally create
the weather subcase if precipitation is forecast.
As shown in the following table, always creating a weather subcase is more advantageous than
conditionally creating a weather subcase.
Design Pros Cons

Always creating a l All weather data and logic l A weather case is created unnecessarily if
to obtain forecasts is weather preparation is not required
weather subcase contained in the weather
(Option 1) subcase
l Better delegation,
encapsulation, and
separation of concerns
strategy
l Simple case dependency
coordination using
AllCoveredResolved ticket
Conditionally l A weather subcase is l The history leading up to the decision to

created only when required create the weather subcase is associated
11
©2019 Pegasystems
Design Pros Cons
creating a weather to the event case instead of the weather
case.
subcase (Option 2)
l Coordination of other optional services
subcases may be complicated when the
weather subcase is not created
Parking
The parking case is straightforward and is only conditionally created when the option is parking service
is selected. Due to its simplicity, no other options are considered for this.
Hotel booking
Two options for the hotel case(s) are to create a single hotel case representing all hotels or single case
representing each hotel.
Option 1: Single hotel case
A single hotel case is created when the option is selected. Data objects representing each hotel are
contained in the hotel case.
Option 2: Hotel subcases for each hotel case
As shown in the following table, creating a hotel subcase for each hotel case is more advantageous
than creating a single hotel case.
Design Pros Cons

Single hotel case l All hotel data is contained in l Data security – Other hotels have
one case potential access to data
l Calculations may be easier l Locking is an issue
Hotel subcase for each l Locking is not an issue l Greater number of hotel case
l UI requirement for hotel instances to manage
hotel case
review is easily satisfied
l Security
12
©2019 Pegasystems
Exercise: Initializing the Event Booking
Application
Scenario
The Event Booking application requirements have been analyzed. It was determined that
implementing a subcase hierarchy is a better approach than implementing parallel processes within
the same event case.
The procedure for implementing subcases was also analyzed. It was decided that a single weather
subcase should be unconditionally created and a single parking subcase should be conditionally
created.
Rather than create a single hotel subcase, it was decided that for each hotel, a subcase should be
conditionally created for requesting rooms.
You want to allow facility coordinators, event managers, and hotel staff to be able to work on subcases
for a specific parent case concurrently.
The following table provides the credentials you need to complete the exercise.
Role Operator ID Password

Administrator Administrator@pega.com install
Administrator Admin@Booking rules
Your assignment
Create the Booking application. Create case types for Event Booking, Weather Preparation, Hotel Rooms
Requests, and Parking Services. Implement the Weather, Parking, and Hotel case types as subcases to
the Event Booking case type. Consider how to maximize maintainability for each new case type. Think
about the following questions, and make sure your design can handle them.
Do you want to freeze development?
Do you want to implement changes for a specific case type more quickly than other case types?
Do you have a requirement for the Weather case type that has to be implemented as a separate
application similar to the Hotel application upon which other applications can be built?
Detailed steps
Below is the targeted goal after the Event Booking application is implemented to accommodate
subcases.
13
©2019 Pegasystems
Build Ruleset Purpose
Phase
Subcase A. EventBooking A. A new Booking application rule and ruleset as well as Parking,
B. Parking Weather, and HotelBooking rulesets
hierarchy
C. Weather B. Contains parking case type rules
D. HotelBooking C. Contains weather preparation case type rules
D. Contains hotel case type rules at the Booking application level
Application A. Booking A. Contains Event Booking rules

B. FSG B. Organization-level rules
Create case type-specific rulesets

1. In the exercise system, log on as Admin.Booking.
2. Create the the following rulesets:
l Event
l WeatherBooking
l ParkingBooking
l HotelBooking
Add new Event, Weather, Parking and Hotel subcase types

1. Create the the following case types:
l Event
l Weather
l Parking
l Hotel
Note: Each case type is being saved to a dedicated ruleset to promote reuse.
Define stages and process steps for the case types

1. Define a life cycle for the new Event case type
2. Define a life cycle for the new Weather subcase type as shown in the following image:
14
©2019 Pegasystems
3. Define a life cycle for the new Parking subcase type as shown in the following image: (No Parking
Case)
In a subsequent exercise you will incorporate a Hotel Reservation built on application to support the
Hotel Rooms Request subcase. At this point, you do not need to define a case life cycle for the new
Hotel subcase type. If desired you can implement a single stage, step, and screen in which users
populate the number of confirmed rooms for the event.
Verify your work

Once completed, the case type hierarchy should appear as illustrated in the following image.
In addition, the class hierarchy should look like the following image.
Create a new Event Booking case and test the updated process.
You can import the Solution RAP file to review the Case Hierarchy and check your work.
15
©2019 Pegasystems
Exercise: Implementing the Case Type life-
cycles
Scenario
The Booking application has been created. Front Stage’s requirements have been discussed regarding
the customer quotation process and FSG’s internal approval process within what will be their “Book
Event” case. Requirements have also been discussed regarding weather preparation, and optional
parking and hotels reservation services for events.
Event case type stages, processes and steps:

The BookEvent case type stages, processes, and steps are:
• The customer chooses a venue that FSG offers while interacting with a Sales Executive
• The customer communicates the number of attendees to the Sales Executive who enters that number
as well as a discount percentage. A price is automatically computed for the event.
• The customer is asked to approve or reject the quotation. If rejected the case becomes Resolved-
Rejected. If approved, the case moves forward to FSG’s internal approval process starting with FSG’s
CEO.
• FSG’s CEO can reject the event, where it would become Resolved-Rejected, or approve the event which
forwards the case to the EventManagement@FSG workgroup manager.
• The workgroup manager can either accept the event or assign it to someone else in the workgroup.
• When routed to someone else in the workgroup that person can either accept the event or refuse it.
• If the event is refused, the case is returned to the workgroup manager.
Below is the targeted goal after the Event Booking application is implemented to accommodate
subcases.
WeatherPrep case type stages, processes, and steps:

The steps for the WeatherPrep case are:
• Wait until a certain number of days before the event to begin requesting forecasts for the venue’s
location
• If rain seems likely, Facility Coordinators should be presented a checklist of items such as tents,
umbrellas, etc.
• If weather preparation does occur, the same checklist should be presented to Facility Coordinators
after the event, this time items being unchecked when tents are torn down, umbrellas put away, etc.
There is no need to complete the WeatherPrep case currently. Spinning it off as a subcase and having
it wait is acceptable.
16
©2019 Pegasystems
Hotel case type stages, processes, and steps:
The steps for each Hotel case are undecided other than knowing that an email should be sent each
hotel’s contact within a certain number of days prior to the event. FSG COE has suggested hotel room
requests may be a good candidate for a reusable built-on application. Hence no need to define the
Hotel case currently.
Booking 01.01.01 Goals

An LSA should proactively “lay the groundwork” for the Booking application prior to the business
process logic being implemented. Ground work items should include:
1) Application layering
2) Minimum Data Model to support a “Book Event” case and “Weather Preparation” case
3) Ruleset usage
After the 01.01.01 version of the Booking application was defined, a Product rule was created in the
Booking 01-01-01 ruleset version then locked down, The application was then versioned to 01.01.02.
Booking 01.01.02 Goals

The goal of the 01.01.02 Booking application version is to leverage the case design, data model, and
application layerig supplied by Booking 01.01.01. Case processes are implemented such as the
Quotation stage and the FSG Approvals stage. A third “Manage Event” stage should spin off the
WeatherPrep case.

Your assignment
Discuss the Event, Weather, Parking and Hotel Case Type Stages, Processes, and Steps and ensure
version specific features have been implemented.
Discuss the goals of versions 01.01.01 and 01.01.02 of the of the Booking Application development
effort and ensure that version specific features have been implemented.
Summarize the following aspects of the proposed solution:
l Application Layering - Design
l Minimum Data Model
l Ruleset Usage
l Application Layering
l Other Key Features
17
©2019 Pegasystems
Detailed steps
Application layering - Design
Rulesets can be configured to use either Application Validation Mode or Ruleset Validation Mode.
Ruleset Validation mode is assigned to the Org and OrgInt rulesets by the New Application Wizard.
Ruleset-Validation-Mode rulesets are permitted to appear in multiple applications, whereas
Application Validation Mode rulesets can only be used within the different versions of same
application.
A simpler approach is to group Ruleset-Validation-Mode rulesets into the same “enterprise
application”, thereby every application would be the same, i.e., its rulesets can only be used within
different versions of same application. The enterprise application can advertise itself as a built-on
application candidate by checking the box within the Application Wizard tab. Unit test rules can be
defined specific to an enterprise application. Having a separate enterprise application facilitates
packaging and deployment as then there would be application version associated that that grouping of
rulesets. When significant changes are made, the enterprise application can and should be versioned
not unlike the way Pega versions its applications.
Minimum Data Model to support an Event case type - Design

If Data classes are created at the enterprise level they can be reused by other applications. In contrast,
if Data classes are created at the application level the only way those Data classes can be shared with
other applications is for them to be built on the Booking application.
If enterprise Data classes are included in rulesets configured as Ruleset Dependency Mode, those
classes could be added to any application. However, as stated above, there are number of benefits
when enterprise Data class rulesets are included in one and only one versioned enterprise application.
Looking at the requirements for the Event case type the need for the following enterprise-level Data
classes is apparent.
Event
• A case type’s primary purpose is to manage data, not be sole container of the data
• Numerous scalar case-level properties go against best practice
• Sections that display Event data can be used by any case type, not just a BookEvent case.
Venue
• Events are held at Venues.
Address
• Venues have at least one Address
Pricing
• The Event quotation process requires a price
• It is not known how many other items may be including in a quotation
• There are different ways to price items. Derive price not necessarily quantity multiplied by a unit
price. Other ways to price a quantity of items include volume pricing and tiered pricing.
18
©2019 Pegasystems
Ruleset Usage - Design
• The four Data classes identified thus far could be used by any Front Stage application, for example
one where the focus is billing. Hence the FSG ruleset itself can be used for core enterprise Data
classes. Likewise, the FSGInt ruleset can be used for any property generic to integration interfaces.
• Immediately after Booking application is generated by the New Application Wizard, its Booking ruleset
would contain the Booking application rule, the FSG-Booking-Data class, and the FSG-Booking-Work
work pool class. If case types such as BookEvent are also added to the Booking ruleset it would set a
precedence. If this were to continue, the Booking ruleset would become monolithic.
• The potential exists for case types to later be converted to a Component Application, i.e., an
application that includes a small number of case types, perhaps just one, that can be used by multiple
disparate applications. The conversion would be much more difficult if the case type class was placed
in the same ruleset as other unrelated case type classes and/or the application’s work pool class. An
“Event” ruleset could be created prior to the BookEvent case type being created, its class and case type
rule added to that Event ruleset.
Application layering - Implementation

1. Create an application named “Booking” using the New Application Wizard (NAW).
• Organization = “FSG”
• Do not create any case types or data types
2. Define a new FSG built on application by saving the Booking application to an application named
“FSG” in the FSG ruleset
• Remove the Booking ruleset from the FSG application
• Set the FSG application’s Skin rule to pyEndUser
• Check the box in the Application Wizard tab, fill out the information
• Clone the Booking:Administrators Access Group to FSG: Administrators, associated ruleset = FSG
•• Under Access Roles, change “Booking:Administrators” to “PegaRULES:SysAdm4”
• Clone the Admin@Booking Operator to Admin@FSG
•• Change the Access Group to FSG:Administrators
• Change the FSG Organization record’s Access Group to FSG:Administrators
• Save the FSG-Booking-UIPages class to FSG-Booking-UIPages in the FSG ruleset
• Configure the Associated Classes in the FSG Application rule as FSG-UIPages, FSG-Int, and FSG-Data
3. Modify the Booking application
• Set the Booking application’s built-on application to FSG
• Remove the FSG and FSGInt rulesets as well as the BookingInt ruleset
Minimum Data Model to support an Event case type - Implementation

FSG-Data-Address
19
©2019 Pegasystems
• Data structure is flat, can be stored in the CustomerData schema
• Key = pyGUID, Configure on the class rule
• Besides Street, City, State, PostalCode, and Country properties, this class should possess a Reference
property and eventually a Type property to indicate the type of object it references which could be a
Person or Location, e.g., Venue.
FSG-Data-Venue
• Should have an embedded Data-Party page named “Contact”
• Because it uses the BLOB, this class should be persisted in the PegaData schema, not the
CustomerData schema
• Scroll to the bottom of the Sources tab and choose PegaDATA
• Do not worry at this time how the embedded Contact page will be populated
• Key = pyGUID. Configure this on the class rule
• A Venue would have scalar properties such as Capacity and Name.
• It would also reference a List of FSG-Data-Address instances.
FSG-Data-Pricing
• Properties would include ItemID, Price, PricingModel, Quantity, DiscountFactor, VolumePriceIncludeQty
• Values for PricingModel include UNIT and VOLUME
• An Integer Property named “Bit” would either be 0 or 1. If selected the value would be 1, otherwise 0.
• Other Properties can be defined to contain derived values such as UnitPrice, VolumePrice, and
DiscountedPrice.
• The data structure is flat. Eventually the data can be stored in the CustomerData schema where it
would more easily be shared between different applications. For now, pricing can be implemented
using a Decision Table.
FSG-Data-Event
• Basic properties of an Event, per se, include Category, StartDT, EndDT
• Values for Category include Concert, Convention, Corporate, Show, Sport
FSG-Booking-Work-BookEvent
• Certain case-level properties are needed as inputs to pricing calculations such as NumAttendees and
DiscountPercentage
• A “Pricing” Field Group List of FSG-Data-Pricing instances should exist, those instances referencing
this case
• An “Event” Field Group of class FSG-Data-Event should also exist. Doing so promotes reuse of the Data
class, plus avoids creation of an excessive number of scalar properties which would complicate
maintenance.
• Certain properties are needed to support FSG-internal approvals and routing such as CEOApproved
and EventManagerWG.
20
©2019 Pegasystems
Minimum Data Model to support an Weather case type -
Implementation
FSG-Data-Weather
• A weather forecast can be requested for multiple days in succession, hence needs a StartDT and
EndDT
• A weather forecast has a central location, hence needs Latitude and Longitude
• A weather forecast returns a list of FSG-Data-Precipitation instance, each instance including a Date
and Probability, the Unit for Probability being Percent.
FSG-Data-Weather-Preparation
• Properties include Boolean properties such as RaincoatsProvided, TentsSetup, SeatingCovered
FSG-Booking-Work-WeatherPrep
• Case-level scalar properties should include PrepLSAGoal and PrepSLADeadline
• Non-scalar properties should include a WeatherPreparaton Field Group
Ruleset Usage - Implementation

Event
• Added to the Booking application’s ruleset stack
• Within the Cases view create a new case type named “Event” placing it in the Event ruleset.
• In the Data Model tab of the Event case type, add a Field Group property named “Event”, the class
being FSG-Data-Event.
• In the Data Model tab of the Event case type, add a Field Group property named “Venue”, the class
being FSG-Data-Venue.
• In the Data Model tab of the Event case type, add scalar properties such as DiscountPercentage
(Decimal) and NumAttendees (Integer).
• To support ease of UI construction for the quotation process, create an application-level class named
FSG-Booking-Data-PricingDisplay placing it in the Event ruleset.
• Add a Decimal property to the FSG-Booking-Data-PricingDisplay class named EventPriceplacing it in the
Event ruleset.
• Add a Field Group property named PricingDisplay to the Event case type, the class being FSG-Booking-
Data-PricingDisplay placing it in the Event ruleset.
• To support routing Event cases to the EventManagement@FSG workgroup manager, add an
EventManagerWG property to the Event case type placing it in the Event ruleset..
• The EventManagerWG property would reference the D_pxWorkgroup Data Page by suppling
“EventManagement@FSG” as the WorkGroup parameter to the data page. To accommodate someone
besides the workgroup manager being delegated to manage an Event, and that someone rejecting the
assignment, add a Boolean “CEOApproved” property. Everything to do with FSG-internal approvals can
be placed in the same stage; that stage can be restarted. The CEO should not be forced to approve the
21
©2019 Pegasystems
same Event multiple times. Only when “.CEOApproved == false” should an “Executive Review” process
execute.
Other Key Features

How the Venue search logic works is discussed in the Data Model lesson’s discussion of the Template
Pattern. At this early stage in the Booking application, FSG-Data-Hotel class exists but is not yet used.
While the FSG-Data-Venue does exist and is used, at this early stage in the Booking application FSG-
Data-Venue does not extend a FSG-Data-Location class, nor does FSG-Data-Hotel. The FSG-Data-Location
removes the redundancy present in the Venue and Hotel data classes.
Note: There is no validation if the venue contact’s email address is left blank. If not entered an error
will be thrown later within Data-Party Validate.
At this early stage in the Booking application the WeatherPrep case’s SetWeaatherCheckDate Data
Transform step arbitrarily hard-codes “-5” when updating the Preparation Field Group’s
WeatherCheckDate property.
.WeatherCheckDate = @DateTime.addToDate(.PrepSLADeadline, "-5", "0", "0",
"0")
The Event case propagates .Event.StartDT as the value for PrepSLADeadline. In a solution that follows
the hard-coding is replaced by a node-level Data Page property. The ability to set the value for that
property will be present in the Manager Portal.
No logic exists at this point to forecast the weather, simulated or not simulated. A “Track Preparation”
step appears before the Wait step but no “Track Teardown” step was added after the Wait step.
Verify your Work

Once completed, the case type hierarchy should appear as illustrated in the following image.
In addition, the class hierarchy should look like the following image.
22
©2019 Pegasystems
Create a new Event Booking case and test the updated process.
You can import the Solution RAP file to review the refactored Case Hierarchy and check your work.
23
©2019 Pegasystems
Exercise: Promoting Reuse With Relevant
Records
Scenario
Front Stage wants to see a demonstration proving that App Studio possesses the ability to accelerate
development and encourage the reuse of previously saved flows, flow actions, sections, and properties.

Admin Administrator@pega.com install
Author Author@Demos rules
Admin Admin@Demos rules
Your assignment
Create a small sample application and demonstrate how relevant record information is captured and
leveraged when using App Studio.
Detailed steps
Follow the steps below to complete your assignment:
1. Create the Demos application
2. Create the Reuse case type and case life cycle
Create the Demos application

1. From your exercise system, log on as Administrator@pega.com.
2. From the Application menu, launch the New Application wizard.
3. In the configuration panel, select Custom, Responsive UI, and then the Default color scheme.
4. In the Name your application field, enter Demos.
5. Select the Advanced configuration link.
6. In the Advanced configuration dialog, do the following:
a. Select Implementation as the application structure.
b. Select Create demonstration users
c. Click Save to save your updates and close the dialog
7. In the New Application wizard, click Create application.
8. After creating the new Demos application, log off.
24
©2019 Pegasystems
Adding the Reuse case type
1. Log on the Demos application as Author@Demos.
2. Click on Case Types then click New .
3. Enter Relevant Records as the case type name.
4. In the Data Model tab add Field1 and Field2 using different types such as Text and Decimal.
5. In the Workflow tab, add a Life Cycle and define two stages: Enter Data, and Resolve.
6. Configure the stage resolution for each stage as follows:
a. For the Enter Data stage select Automatically move to next stage.
b. For the Resolve stage select Resolve the case.
7. Add a step to the first process in the Enter Data stage.
a. Select Collect Information as the step type.
b. Label the step Enter data.
c. In the contextual properties panel, click Configure View .
d. Expand Fields. Observe Field1 and Field2 are visible to the case.
e. Drag Field1 and Field2 beneath Add field.
f. Click Submit.
8. Save the case type in Case Designer, click Close, then log out.
View Relevant Records verifying potential reuse

1. Log on the Demos application as Admin.Demos
2. Select Designer Studio > Application > Inventory > Relevant Records.
3. Either add -Reuse to the work pool class name or click the down arrow to select that class. Confirm
the following records are indicated as Relevant Records. These records are easily reusable for this
class group using App Studio.
4. View the Relevant Record instances created. Within the App view, enter Data-Tag-RelevantRecord.
a. Click on Data-Tag-RelevantRecord to list instances
b. Filter the Context Class class column using the word Reuse
25
©2019 Pegasystems
Exercise: Case specialization and extensibility
Scenario
Front Stage’s event booking needs are currently handled by a single application. Front Stage intends to
pursue additional venues in the future. Front Stage is concerned that each additional entertainment
venue could potentially require modifications to their current application.

Your assignment
Analyze the key requirements to determine if the current single application design will support these
requirements.
Prepare a list of questions that can be presented to the Front Page executives asking for clarification.
Recommend the most appropriate enterprise class structure for the application going forward.
Design considerations
The key requirement is the ability to implement business logic specific to an entertainment venue
when the need arises. No requirement was stated that each venue’s data should be stored in different
database tables.
Possible approaches
Three approaches are possible for this solution:
1. Represent the differences between venues as data. Implement rules that are able to process this
data.
2. Implement venue specialization within the current application.
3. Use the current application as a framework / model / template / blueprint. Create an
implementation application for each venue.
Data driven rules

In this approach an attempt is made to model the differences between venues as either data instances
or custom non-Pega rules that are treated as data. Rules are developed with the ability to react to this
data regardless the venue.
Pros
Maximum scalability.
26
©2019 Pegasystems
No need to create and maintain vendor-specific rules.
Cons
Highly complex to implement and maintain the data-driven rules required to satisfy each and every
specialization requirement.
Single application rule specialization

The single application approach would satisfy the current routing requirements leveraging the org
structure. If only a few differences are anticipated between venues, circumstancing would suffice. For
more complex differences, you can use pattern inheritance and utilize venue-specific classes that have
been defined. Then you can use Dynamic Class Reference (DCR ) to decide which class to create.
Pros
Single application for users to access.
Relatively simple to implement and maintain compared to data-driven rules.
Cons
Extra work required when a large number of venues are added.
Application per venue

The multiple application approach would also satisfy the current routing requirements leveraging the
org structure. An application would be created for each venue. Case types within each venue-specific
application would extend a case type class within the current application. Venue-specific business
logic differences would be handled by saving the rule from the current application to the
corresponding case type class in with the venue-specific application. Users must switch applications to
create and manage cases for different venues.
Pros
Simplest possible development since venue-specialized rules are defined in a venue-specific
application in venue specific rulesets and classes.
Cons
Switching between applications for each venue is required.
Reporting across multiple venue application is more difficult.
Recommended design approach

The single application approach is recommended since it:
1. Satisfies the requirement.
2. Does not require application-switching.
3. Simplifies reporting.
4. Supports a large number of venues when required.
27
©2019 Pegasystems
Exercise: Designing an email application
Scenario
Front Stage employees need to be able to generate, and if necessary edit, emails that can be
automatically or manually sent at a future date. It should be possible to incorporate this capability into
present and future applications generated for Front Stage.
Your assignment
Produce a design document for a solution that satisfies Front Stage's requirements for delayed email
editing and sending capabilities. The design document should describe the thought process and
include at least three (3) viable alternative solutions, a comparison of the Pros and Cons of each, and
the recommended solution.
Possible approaches
Three approaches are possible for this solution:
1. Spun-off Email process defined by a (pyMode=Component) component
2. Advanced Agent-processed Email data instances
3. Spun-off Email subcase defined by a (pyMode=Application) component application
Spun-off Email process Component

The functionality needed to send emails at a scheduled time could be defined in a process included in
a (pyMode=Component) component. Case types would reference this process within their Life Cycle.
The Component-defined process would spin-off a second process. The spun-off process would contain
an assignment with an SLA. The SLA would react to a datetime property defined by the Component,
one that any case type would inherit.
Pros
l Simple design - easy to implement
Cons
l Editing the email requires locking the case
l Specialization options limited
Advanced Agent-processed Email data instances

The Data-Corr-Email class would be extended to include scheduling information. Instances of that class
would be stored separately. Users would be able to open instances that are related to cases to which
they have access, An Advanced Agent would periodically query these Data instances looking for those
where the time-to-send is in the past, but the email has not been sent. When the Advanced Agent
successfully sends the email it updates the Data instance to flag it as having been sent.
28
©2019 Pegasystems
Pros
l Locking is independent of the case that created each instance
Cons
l More difficult to manage
Email subcase component application

Create a (pyMode=Application) component application with a single Email case which is always spun off
as a subcase. Data propagation would be used to tell the Email case when to send an email. The Email
case would assume that its cover's most recently attached Data-Corr-Email instance, prior to it being
spun off contains the email’s information. The case would support a UI to allow the email to be edited
prior to it being sent.
Pros
l Subcase can be configured as Do not lock parent or inherit Optimistic locking from its parent
l Has its own life cycle, data model, settings, and views
l Simplified reporting and security
l Could be configured to be self testable on its own
Cons
l If an event is canceled, email subcases need to be withdrawn
l More complex to implement

The Email subcase component application option is preferred because it:
l Fully satisfies the requirements
l More configurable
l Simplifies testing
Exercise: Leveraging the email component

application
Scenario
Front Stage would like to be able to send personalized emails to recipients at scheduled times and
dates. Front Stage wants to reuse this capability in multiple applications. This requirement was
analyzed by a Lead System Architect and the decision was made that the best solution was to build a
component Email application, one on which other applications can be built.
29
©2019 Pegasystems
Author Author@FSGEmail rules
Admin Admin@FSG rules
Important: Before starting this exercise, make sure that you have loaded the 02_Booking_Solution_
2.zipfile into your system if you have not completed all the prior exercises. This file is accessed
through the link available in the related content pane on the right side of this lesson.
Important: If this is the first import of Admin@FSG:
Administrator@pega.com may have to enable the Admin@FSG operator record then reset the
password to “rules”. Also add the FSGEmail:Administrators and FSGEmailAdmin:Solution2 Access
Groups to the Admin@FSG Operator record.
Important: If the Admin@FSG operator record already exists:
Use “advanced/granular” mode when importing the RAP. You will be shown the Operator records
included in the RAP, here only Admin@FSG. Permit the existing Admin@FSG Operator record to be
overridden.
Your assignment
Design and implement a component application that sends emails on a specific date and time. Emails
can be edited and personalized for each recipient before being sent. Emails can also be sent manually.
The Front Stage development team has provided you with an Email Editor component that implements
the email-editing functionality. Use the Email Editor component to create the Email application’s
reusable case type.
The Front Stage development team wants this capability to be self-testable. In Self-test mode, the Email
case must be able to attach a Data-Corr-Email instance prior to spinning off a second Email subcase.
The Email parent case should propogate to the email subcase the DateTime property indicating when
to send the email. It should also propagate who should own Email subcase assignments.
Design Analysis
Any parent case, including an Email case, should be able to spinoff an Email subcase.
30
©2019 Pegasystems
Application Configuration:
FSGEMail 01.01.02 is built on FSG 01.01.02. The EmailEditor_20170814T145312970 01.01.01 component
has been added. The checkbox in the Application Wizard tab has been checked.
The only ruleset in the FSGEmail application is FSGEmail:01-01-02. There is no need to include rulesets
that not used such as FSGEmailInt.
Email Case Stages:

The Email case contains the four stages listed below.
1. Enter Test Data
2. Prepare Email
3. Edit Send or Skip
4. Resolve
The processes used by the two middle stages, Prepare Email and Edit Send or Skip, were provided by
the Email Editor component. These two middle stages are only valid When DoesNotHaveCover=true.
Enter Test Data Stage:

The Enter Test Data stage in the solution consists of three back-to-back processes.
1. EnterTestData_Flow
2. SendEmail
3. Continue_Test
This stage is only entered When HasCover=true. The only test data needed is the WhenToSendEmail
property defined in the Email Editor component.
The EnterTestData_Flow process captures the WhenToSendEmail date-time value then adds
CurrentOperator as the Owner workparty.
31
©2019 Pegasystems
The SendEmail process creates a test PDF, later used as an email attachment, followed by a Utility that
calls CorrNew . CorrNew is configured to include all Attachments within the File category. The
Correspondence rule provided to CorrNew is configured as “Attach and Hold”. The SendMail shape is
not used as doing so would cause the email to be sent in the background as opposed to waiting to be
sent.
The first Review assignment in the Continue_Test process shows the generated PDF and Data-Corr-Email
having been attached. The Owner workparty is also visible. Click Submit.
Edit Send or Skip Stage:

The second Review assignment in the Continue_Test process shows the Email subcase having been
created. Click on “Edit Send or Skip” then Submit. Note the Email Editor screen. Click on “Download EML
File”. Open the generated EML file. Note the PDF attachment.
Detailed construction steps (optional)

1. Create the FSG Emails application.
2. Add the component to the application.
3. Create the Email case type and case life cycle.
4. Configure the supporting rules in Designer Studio.
5. Make the application available in the New Application wizard.
Create the email application

1. From your exercise system, log on as Administrator@pega.com.
2. From the Application menu, launch the New Application wizard.
3. In the configuration panels, select Custom, Responsive UI, and then the Default color scheme.
4. In the Name your application field, enter FSGEmail.
5. Select the Advanced configuration link.
6. In the Advanced configuration dialog, do the following:
a. Select Implementation as the application structure.
b. Enter FSG as the organization name.
c. Select Create demonstration users.
d. Enter Email as the class layers application.
7. Click Save to save your updates and close the dialog.
8. In the New Application wizard, click Create application.
9. After creating the new FSGEmail application, log off.
32
©2019 Pegasystems
Add the component to the application
1. Log on the email application as Author@FSGEmail.
2. At the bottom of the Explorer panel, click Switch to Designer Studio.
3. In the related content pane on the right side of this lesson, click the Email editor component link
to access the EmailEditor_20170814_010101.zip file. Then, import the file.
4. In the Application record, do the following:
a. Add the EmailEditor_20170814T145312970 version 01.01.01 component. You can do this
manually, or by selecting Manage components on the Definition tab of the Application record
and enabling Email Editor version 01.01.01.
b. Remove the FSGEmailInt:01-01 and FSGInt:01-01 rulesets from the application ruleset list.
Create the email case type and case life cycle

1. At the bottom of the Explorer panel, click Switch to Pega Express mode and add an Email case
type.
2. On the Case Designer Workflow tab, add an Email case type life cycle that includes the following
stages:
l Enter Test Data
l Prepare Email
l Edit, Send, or Skip
l Resolve Email
3. On the General tab in the Stage panel, set the first three stages to Automatically move to next
stage. Set the Resolve Email stage to Resolve the case.
4. In the Enter Test Data stage, add a Collect Information step named Enter Test Data.
5. On the General tab in the Step panel, select the Configure view button to open the views dialog.
Do the following on the Fields tab:
a. Expand the Fields section on the left
b. Drag and drop the When To Send Email property beneath the Add field link. This property is
part of the Email Editor component and is used to set a future date and time.
c. In the Options field, select Required.
d. Click Submit to save your updates.
6. On the Case Designer Workflow tab, select the Enter Test Data stage header and then add a
process named Send Email.
7. In the Send Email process, delete the default Collect Information step and add a standard Send
Email utility step.
Note: This Send Email step serves as a placeholder. The Send Email shape does not recognize
correspondence rules configured as Attach & Hold. Later in this exercise, you will replace the Send
Email shape with a Utility shape that calls the CorrNew activity to avoid a correspondence error.
8. Select the Enter Test Data stage header and add a process named Complete Testing.
33
©2019 Pegasystems
9. To the Complete Testing process, add the following three steps:
a. A Collect Information step named Review Email. Configure the view to show the provided When
To Send Email property in read-only mode.
b. A Create Case utility step named Create Email Child Case. In the Create the following case
field, select Email.
c. Another Review Email step by selecting +Step > More > User action > Review Email .
Note: You cannot use a Wait utility step since the case type is the same as the case type you
are testing.
10. In the Case Designer, open the Settings tab.
11. In the Availability field, select Show in 'New' menu. In the Behavior field, select the Skip
'Create' view when users create a new case.
When you are finished, the life cycle looks like the following:
Configure supporting rules in Designer Studio
1. Switch to Designer Studio and define the following When rules in the FSG:01-01-01 ruleset that
apply to Work-:
l HasCover using the condition .pxCoverInsKey exists and has a value.
l DoesNotHaveCover using the condition .pxCoverInsKey does not exist or has no value.
2. In the Email case Work Parties rule, select the VOE? check box for the Owner work party.
3. In the Cases Explorer, add the Email case type as a child case type of itself.
4. In the Cases Explorer, select the Email parent case type.
5. On the Case Designer Settings tab, select Data propagation.
6. In the Data propagation panel, propagate the following property values:
l .WhenToSendEmail to the property value .WhenToSendEmail.
l .pzInsKey to property value .EmailWorkKey.
l .pyWorkParty to property value .pyWorkParty.
Complete the case life cycle

1. On the Email case type life cycle on the Workflow tab, select the Enter Test Data stage and enter
HasCover for the Skip stage when condition.
2. In the Enter Test Data stage, open the Email process.
3. In the Email process, replace the Send Email shape with a Utility shape that references the CorrNew
activity.
4. In the Utility shape property panel, do the following:
a. In the CorrName field, enter the TestEmailDetails correspondence rule.
b. In the PartyRole field, enter Owner.
34
©2019 Pegasystems
c. In the EmailSubject field enter Test Email.
The step now looks like the following:
Note: You can update the step name to Send Email.

5. Save your updates.
6. On the Workflow tab, in the Complete Testing process, select Create email child case and specify
the Email case.
7. In the Cases Explorer, select the Email case type and click the Open menu to open the pyDefault
Email case type rule.
8. In the rule, open the Stages tab.
9. Select the Prepare Email stage.
10. In the Skip stage when field, specify DoesNotHaveCover.
11. In the Automatically launched process section, enter the provided PrepareEmail process.
12. Select the Edit, Send, or Skip stage.
13. In the Skip stage when field, specify DoesNotHaveCover.
14. In the Automatically launched process section, enter the provided EditSendOrSkip process.
When you are finished the case life cycle looks like the following:
Make the application available in the New Application wizard

1. In Designer Studio, from the Application menu, open the FSGEmail Application record.
2. On the Application wizard tab, select the Show this application in the New Application wizard
check box.
3. In the Short Description field, enter FSG Email. In the Application description field, enter Self-test-
capable reusable Email case. Pauses email for editing prior to being sent at designated time or can be
sent manually.
4. Open the Cases & data tab.
35
©2019 Pegasystems
5. Change the Work ID prefix for the Email Case type to FSGEMAIL-.
6. Save the rule.
Verify your work

1. Create an Email case.
2. On the Create view, enter a future date in the When to Send Email field and then click Submit.
3. On the Review view, note the attached Email correspondence and then click Submit.
4. On the view, under Open Assignments, note that the Email child case paused at the Edit, Send, or
Skip assignment.
Exercise: The Hotel and Hotel Proxy

applications
Scenario
Front Stage currently hosts outdoor events. Acquisition of a company that specializes in hosting indoor
event would round out FSG’s service offerings. The acquired company could utilize hotel room
reservation capability within its own application, not needing to extend or be built on the outdoor
event-hosting Booking application.
Similar to the FSGEmail application’s ability to be used by multiple applications, FSG would like its hotel
room reservation capability to also be used by multiple applications.
As opposed to external hotel contacts logging into the Booking application, or whatever application is
used, to indicate the number of rooms to reserve for an event, FSG wants those contacts to log into
Pega Cloud-hosted “Hotel Proxy” application, that does nothing else. The “Hotel Proxy” application’s
“rooms request” case would be created by the “SOR” application. The “Hotel Proxy” application’s “rooms
request” case would relay the number of reserved rooms to the “SOR” application.
Front Stage also wants the hotel room booking capability to leverage the FSGEmail application. Similar
to the FSGEmail application, the Front Stage development team wants the hotel room reservation
capability to be self-testable.
The following table provides the credentials you need to complete the exercise:

Author Author@Hotel rules
Admin Admin@Hotel rules
Admin Admin@HotelProxy rules
Admin Admin@HotelDevOnly rules
Note: Use Advanced/granular mode to import the RAP file.
36
©2019 Pegasystems
Your assignment
Build a Hotel application on the FSGEmail application. The number of rooms to request and who to
contact should be propagated to the Hotel application by its parent application.
The Hotel application should communicate the number of rooms to reserve to separate PegaCloud-
hostable Hotel Proxy application. An email should be sent to the hotel contact telling that contact about
the request and how to log into the Hotel Proxy application to respond. The Pega API should be
leveraged achieve this goal.
The Hotel and Hotel Proxy applications should pass the same “hotel rooms request” data structure back
and forth. It makes sense that this data structure be defined in a ruleset shared between the two
applications. To avoid a warning, the shared ruleset should be included in a Component that both
applications include.
We will also implement a third “Development Only” application that is built on the Hotel and Hotel
Proxy applications. This is done to simplify packaging and deployment, plus provide an additional way
to test the Hotel application.
In another exercise, you will create the Hotel Proxy interface to the Hotel application.
Tasks
Follow these steps to complete your assignment:
Building the Hotel and Hotel Proxy applications is optional. You will be instructed to leverage the
already built Hotel and Hotel Proxy Applications. However, if you need the practice, you are free to
construct them from scratch. If you choose to build the Hotel and Hotel Proxy applications from scratch
here is a suggested order of tasks to perfrom:
1. Create the Hotel application.
2. Configure the Hotel case type.
3. Create the Hotel case type life cycle.
4. Create the Proxy case type.
5. Create the Hotel Proxy application.
Solution Detail
HotelShared Component
A “HotelShared_20191202T192854184” component was created. Pattern-inheritance was applied to the
FSG ruleser’s FSG-Data-Hotel class to define the FSG-Data-Hotel-RoomsRequest class within the
HotelShared_20191202T192854184:01-01-01 ruleset. The RoomsRequest class does not contain Hotel
Field Group with a pyGUID property where that pyGUID is used to perforrm a SOR lookup. The reason
this is not done is because the HotelProxy does not have access to the SOR’s database, nor should it.
Instead inherited scalar properties can bet set as needed, for example the hotel’s name and brand.
The RoomRequestInt ruleset is included in the HotelShared component. This makes sense because the
same REST connector is used to communicate between the two Hotel and Hotel Proxy applications. The
37
©2019 Pegasystems
Hotel application uses the REST connector’s POST method. The Hotel Proxy application uses the REST
connector’s GET and PUT methods.
Hotel Application
The Hotel 01.01.01 application was generated using the New Applicaton Wizard. The FSGEmail 01.01.01
was selected as the built-on application. The Hotel application has a single case named
“RoomsRequest”.
RoomsRequest Case Type

The FSG-Hotel-Work-RoomRequest case has a Field Group named Hotel of class FSG-Data-Hotel. In self-
test mode it is desireable to define a new Hotel instance, save it to the database, then later be able to
retrieve the same Hotel instance. An embedded page (Field Group) makes it possible to copy that page
to the D_HotelSavable data page immediately prior to a “Save data page” step using the PreSaveHotel
Data Transform named.
The only other property used by the FSG-Hotel-Work-RoomRequest case type is a Field Group named
RoomsRequest of class FSG-Data-Hotel-RoomsRequest. The last step in the "Enter Test Data" stage
populates the RoomsRequest Field Group’s non-inherited properties. A parent case would propagate a
fully populated FSG-Data-Hotel-RoomsRequest page to a Room Request case when used as a child case.
The Rooms Request stages that are never skipped are:
• Create Proxy
• Email Hotel
• Wait for Response
• Resolve
Create Proxy Stage

The "Create Proxy" stage is a single Utility step that invokes the CreateProxyCase activity.
Step 2 within this activity ensures the .SORCaseKey property is set within the .RoomsRequest Field
Group. The to-be-created remote RoomsRequestProxy case would be not be able to respond to the
RoomsRequest case that created it if this was not done.
Step 3 uses the Interface step page of class FSG-Int-Hotel-RoomsRequestAPIand sets .request.body_
POST.content.RoomsRequest equal to Primary.RoomsRequest.
Afterward a REST connector named RoomsRequest is invoked. The URL passed to the REST connector
ends in "/api/v1/cases". The REST connector’s method is POST.
Then the REST connector is invoked the AutoMapAll Data Transform against a step page named PegaAPI
of class Pega-API.
Next the Primary.RoomsRequest.ProxyCaseKey property is set equal to the PegaAPI step page ID
property. This is important should the Hotel application ever need to issue a PUT request to update the
number of requested rooms.
Email Hotel Stage

The purpose of the Email Hotel stage is to send an email to a hotel contact at a scheduled date and
time. The event may be held far in the future. It is unlikely that a hotel would be able to predict its
38
©2019 Pegasystems
capacity far into the future. If notified too early a hotel may ignore the request. Plus the possibility
exists that the event could be canceled. Not sending the email immediately allows the email to be
edited prior to being sent.
The first step in the Email Hotel stage adds a Data-Party pyWorkParty(Contact) page to the
RoomsRequest case by leveraging the AddWorkObjectParty activity.
Immediately following this activity, two properties are set: .pyWorkParty(Contact).pyEmail1 and
.pyWorkParty(Contact).pyWorkPartyUri, both are set equal to = .RoomsRequest.Contact.pyEmail1.
Next, the CorrNew activity is used to Attach-and-Hold an Email Correspondence named RoomsRequest.
The party role for the email is set to “Contact”. The SendNow parameter is set to “No”.
It is important to ensure that the Data-Corr-Email attachment is persisted before an Email case is
created. Hence a third Utility shape labeled Commit Attachment is confgured. This Utility call the
commitWithErrorHandling activity.
Finally a Create Case shape is used to create a single Email child case. The Settings tab of the Hotel
case shows the three properties propagated to the Email case.
Hotel == > Email

.RoomsRequest.RequestSendDate .WhenToSendEmail
.pzInsKey .EmailWorkKey
.pyWorkParty .pyWorkParty
Wait for Response Stage

This stage consists of a single Timer step that waits until .RoomsRequest.ResponseDeadline to continue.
The step can be manually continued.
Resolve Stage
This step simply resolves the case setting the status to Resolved-Completed.
Hotel Proxy Application

The HotelProxy 01.01.01 application was generated using the New Applicaton Wizard. FSG 01.01.01 was
selected as the built-on application. The HotelProxy application has a single case type named “Rooms
Request Proxy”.
39
©2019 Pegasystems
RoomsRequest Proxy Case
The RoomsRequest Proxy case has two stages, Confirm Rooms and Resolve. The Resolve stage simply
resolves the case setting the status to Resolved-Completed.
The actor for the Confim Rooms stage is a hotel contact. The hotel contact must eventually become an
authenticate-able Data-Admin-Operator-ID instance.
As shown below, a placeholder Utility shape labeled “Create HotelProxy Operator” was placed at the
beginning of the ConfirmRooms_Flow process. This Utility simply calls UpdateStatus supplying “Pending-
Fulfillment” as the StatusWork parameter value. The Utility could instead do two things:
1) Create a PRBasic-authenticated Operator record.
2) Provision an Identity Provider (IdP) with the hotel contact’s information to support external
authentication.
The Confirm Rooms assignment is routed using ToWorklist. The value supplied for the Operator
parameter is .RoomsRequest.Contact.pyEmail1.
The Confirm Rooms assignment simply asks the hotel contact to enter the number of confirmed rooms.
On submit, the case is resolved.
40
©2019 Pegasystems
Alternatively some means could be devised where the assignment remains active until
.RoomsRequest.ResponseDeadline. Doing so would allow the hotel contact to submit the number of
confirmed rooms multiple times in effect allowing the number of confirmed rooms to be updated.
The ConfirmRooms Flow Action calls a ConfirmRooms activity on submit. The ConfirmRooms activity
makes two back-to-back Pega API REST service calls, a GET and a PUT. The purpose the GET request is
to capture an etag header value from the response. Then copying the value to a paramter named eTag
on the Clipboard. This parameter is not visible witin the ConfirmRooms activity since that activity
shared its parameter page with the REST connector. The .RoomRequest page is copied to the Interface
step page’s .request.body_PUT.content page prior to the PUT request. Within the REST connector’s
configuration for that PUT request, the If-Match header value is set equal to param.eTag.
After each Pega API REST service is called the FSGInt-defined RESTErrorDetected When rule is checked. If
the HTTP response code is >= 300, the ConfirmRooms activity jumps to the step labeled “ERR”.
Solution Tips
The REST Connector Wizard will ask for sample JSON text when configuring the POST and PUT
requests. As shown below, the requests are highly similar. A convenient way to obtain the content
portion, i.e., a RoomsRequest element, is to use the Hotel case’s Enter Test Data stage to populate a
RoomsRequest Field Group. Once this is done, open the Clipboard, navigate to the pyWorkPage’s
RoomsRequest child page, right click, and select “Show JSON”.
POST JSON PUT JSON

{"caseTypeID":"FSG-HotelProxy-Work- { "content":{ "RoomsRequest":{
RoomsRequest-Proxy" "FromDate":"20190331T130944.828 GMT"
,"processID":"pyStartCase" ,"HotelGUID":"d8825749-e2fb-46b3-
,"content":{ "RoomsRequest":{ 97aa-3ead12b89584"
"FromDate":"20190331T130944.828 GMT" ,"pxObjClass":"FSG-Data-Hotel-
,"HotelGUID":"d8825749-e2fb-46b3- RoomsRequest" ,"pyLabel":" "
97aa-3ead12b89584" ,"RequestSendDate":"20190325T130944.8
,"pxObjClass":"FSG-Data-Hotel- 29 GMT"
RoomsRequest" ,"pyLabel":" " ,"ResponseDeadline":"20190329T130944.
,"RequestSendDate":"20190325T130944.8 829 GMT" ,"RoomsRequested":"320"
29 GMT" ,"ToDate":"20190402T130944.829 GMT"
,"ResponseDeadline":"20190329T130944. ,"Contact":{ "pxObjClass":"Data-
829 GMT" ,"RoomsRequested":"320" Party"
,"ToDate":"20190402T130944.829 GMT" ,"pyEmail1":"rooms@gunter.sa.com"
,"Contact":{ "pxObjClass":"Data- ,"pyEmail1Type":"HTML"
Party" ,"pyFirstName":"Tony" ,"pyLabel":" "
,"pyEmail1":"rooms@gunter.sa.com" ,"pyLastName":"Parker" } } } }
,"pyEmail1Type":"HTML"
,"pyFirstName":"Tony" ,"pyLabel":" "
,"pyLastName":"Parker" } } } }
Note: The Access Group specified for the “api” Service Package, namely HotelDevOnlyAdmin:Solution2.
Since this is only an exercise, The “Requires authentication” checkbox is unchecked. If that checkbox
was checked, the PegAPI_Hotel Authentication Profile configured on the RoomsRequest REST connector
would be used. Regardless of the box being checked, because the PegAPI_Hotel Authentication profile is
specified on the RoomsRequest REST connector the profile must exist, otherwise an error will be
thrown.
Verify your work

1. Switch to the “Hotel Dev Only Solution 2” application
2. Click on the Rooms Request case within the Case Designer
3. Click the “Run” button
41
©2019 Pegasystems
4. Down-arrow with the Hotel Name field to select an existing FSG-Data-Hotel
5. Modify or Review the Hotel Contact information (an email address MUST be supplied)
42
©2019 Pegasystems
6. Modify or Review the Rooms Request information
7. Create an Operator record based on the hotel contact’s email address. If this is not done, an error
will occur when the RoomsRequestProxy case attempts to route to the Confirm Rooms assignment.
8. Advance the Hotel case to where the Email subcase is spun off
Note the attached Data-Corr-Email instance and the two workparties, Owner and Contact.
43
©2019 Pegasystems
9. VVerify that the RoomsRequestProxy case was created by entering class name FSG-HotelProxy-Work-
RoomsRequestProxy in the App Explorer followed by clicking on that class name.
a. Launch a RoomsRequestProxy case, open the Clipboard, then locate pyWorkPage. Note that
pxApplication = HotelDevOnly
b. Note how the Assign-Worklist pyUserWorkList Report Definition defined in the Pega-EndUserUI
ruleset filters on .pxApplication = pxThread.pxCurrentApplicationName
c. Note how HotelProxy ruleset overrides the Assign-Worklist pyUserWorkList Report Definition to
remove this filter condition
10. Using a different browser, log in as the hotel contact. A RoomsRequestProxy case should be present
in that contact’s worklist
11. Launch the case. enter the numnber of confirmed rooms, click Confirm
12. Locate the SOR case in the App Explorer using FSG-Hotel-Work-RoomsRequest as the class. Note
that the the number of confirmed rooms has been received from the RoomsRequestProxy case
44
©2019 Pegasystems
The number of confirmed rooms should have been communicated to the SOR Hotel case
45
©2019 Pegasystems
Exercise: Creating the REST integration
interface
Scenario
You have created the Hotel and Hotel Proxy applications in the Creating the Hotel application exercise.
Now, you will create a Hotel Proxy REST integration interface to the Hotel application. The interface
allows the hotel users to send the number of rooms being reserved to the Hotel application.

Author Author.Hotel rules
Your assignment
Create a REST integration interface that does the following:
l Allows users to enter the number of rooms to reserve for the event
l Displays the number of rooms that have been accepted, if the submission is successful
l Displays an error message, if the submission is not successful
Detailed steps
To support your requirements, you will do the following:
1. Create a REST connector for the interface.
2. Configure the REST connector.
3. Configure the rules required to configure the Confirm Rooms activity.
4. Create the Confirm Rooms activity.
5. Create the Create Proxy Case activity.
Create a REST connector for the interface

1. From your exercise system, log on to the Hotel application as Author.Hotel.
2. From the Records Explorer, navigate to Integration-Resources > Service Package and open the
api service package.
3. Update the Service access group to Hotel:Administrators and clear the Requires authentication
check box. Change the associated ruleset to FSGInt. Save the service package.
Note: For the purpose of packaging, you changed the service package's associated ruleset.
46
©2019 Pegasystems
4. From the Designer Studio menu, navigate to Integration > Connectors > Create REST Integration,
which opens the REST Integration wizard.
5. On the Connection panel, name the connector Rooms Request and enter the following endpoint
URL:
http://127.0.0.1/prweb/api/v1/cases/{CASE_KEY}
Note: The IP address in this example is never used.
6. Advance to the Resource methods panel and do the following:
a. Name the resource Rooms Request and select the GET, POST, and PUT check boxes.
b. Create PUT and POST JSON text files similar to the following examples:
POST file
{"caseTypeID":"FSG-Hotel-Work-Hotel-Proxy" ,"processID":"pyStartCase"
,"content":{"RoomsRequest":{"SORCaseKey":"FSG-HOTEL-WORK-HOTEL HOTEL-1"
,"ProxyCaseKey":"FSG-HOTEL-WORK-HOTEL-PROXY HPROXY-1"
,"ContactPerson":"Test Person" ,"Phone":"555-555-5555"
,"Email":"test@test.com" ,"Name":"Test Hotel"
,"EventStartDT":"20181217T181100.000 GMT" ,"NumRequested":"320"
,"pxObjClass":"FSG-Data-Hotel-RoomsRequest" ,"pyLabel":" "
,"NumConfirmed":"222" ,"ResponseDeadlineDT":"20181217T181100.000 GMT"
,"WhenToRequestDT":"20181217T181100.000 GMT"}}}
PUT file
{ "content": {"RoomsRequest":{"SORCaseKey":"FSG-HOTEL-WORK-HOTEL HOTEL-
1" ,"ProxyCaseKey":"FSG-HOTEL-WORK-HOTEL-PROXY HPROXY-1"
,"ContactPerson":"Test Person" ,"Phone":"555-555-5555"
,"Email":"test@test.com" ,"Name":"Test Hotel"
,"EventStartDT":"20181217T181100.000 GMT" ,"NumRequested":"320"
,"pxObjClass":"FSG-Data-Hotel-RoomsRequest" ,"pyLabel":" "
,"NumConfirmed":"222" ,"ResponseDeadlineDT":"20181217T181100.000 GMT"
,"WhenToRequestDT":"20181217T181100.000 GMT"}}}
7. Advance to the Data model panel.
8. Add the POST text file to the POST method Sample type Request and add the PUT text file to the
PUT method Sample type Request.
9. Advance to the Review panel. In the panel, do the following:
a. Specify Hotel Rooms Request as the Integration class, FSG-Int as the Parent class, and FSG-Int-
HotelRoomsReq as the Integration class ID.
b. Specify Hotel Rooms Request as the Connector Name, and RoomsReq as the ID.
c. Set the Context ruleset to a new RoomsReq ruleset.
d. In the Data Layer section, select Skip (I’ll do it later).
Note: You do not need to configure the data — you already have your data model for the room
requests.
10. Click Create to create the connector.
11. In the Hotel and the Hotel Proxy application rules, verify that the RoomReq:01-01 ruleset was added.
47
©2019 Pegasystems
Configure the REST Connector
1. From the Records Explorer, open the new Hotel Rooms Request (RoomsReq) REST Connector.
2. On the Methods tab, in the Get Response section, configure the header using the following values.
Name Description Map from Map from key
etag Entity value of the case Clipboard Param.eTag
3. In the Put Request section, configure the headers and query string parameters as shown in the
following tables.
Headers

Content- Type Constant application/json
If-Match Entity value of the case Clipboard Param.eTag
Query string parameters

actionID Local action to execute Clipboard Param.actionID
4. Save the connector for use by the interface.
Create the rules required to configure the ConfirmRooms activity

Note: In the Configuring the Hotel and Hotel Proxy applications exercise, you named the
ConfirmRooms activity for use in the Confirm Rooms process Integrator shape. To create and
configure the ConfirmRooms activity, complete the following steps and the steps in the next section,
Create the ConfirmRooms activity.
1. In the FSG-Data class (FSG:01-01-01 ruleset), create two Text type properties named SORCaseKey and
ProxyCaseKey.
2. Create a when rule named RESTErrorDetected that applies to FSG-Int with the following condition:
.pyHTTPResponseCode >= 300
Note: .pyHTTPResponseCode is the HTTP Response Code set by Rule-Connect-HTTP.
3. Create a NumRoomsConfirmed*SendError field value that applies to FSG-Hotel-Work-Hotel. On the
Localized label tab, specify this message: An error occurred. Please try again.
Create the (FSG-Hotel-Work-Hotel-Proxy) ConfirmRooms activity

1. From the App Explorer, create an activity named ConfirmRooms that applies to the FSG-Hotel-Work-
Hotel-Proxy class and Hotel ruleset.
48
©2019 Pegasystems
2. On the Steps tab for the activity, enter the following values.
Step Label Method Step page Description
1 Page-New Interface FSG-Int-HotelRoomsReq-
RoomsReqAPI
2 Property-Set .RoomsRequest Set Proxy Case Key in case SOR
case needs to contact again
3 Property-Set Interface.request Set CASE_KEY plus
param.EndPointURL
4 Connect- Interface GET eTag header value set into Jump
REST Param.eTag later used by PUT
5 Property-Set Interface.request.body_ Set .content.RoomRequest and
PUT Param
actionID=pyResolveAndCloseCase
6 Connect- interface PUT If-Match, actionID, and Jump
REST content = NumConfirmedRooms
7 ERR Page-Set- If error, output
Messages NumRoomsConfirmed SendError
Field Value text
8 CLN Page- interface Clean up
Remove
3. On the Pages & Classes tab for the activity, define Interface as a Page name and specify FSG-Int-
HotelRoomsReq-RoomsReqAPI as the Class .
4. On the Parameters tab for the activity, define three Out parameters of type String named eTag,
actionID, and EndPointURL.
Update the steps on the activity Steps tab

1. For Step 2 in the activity, set the method parameter .ProxyCaseKey = Primary.pzInsKey.
2. For Step 3, set the following method parameters.
PropertiesName PropertiesValue
.CASE_KEY Primary.RoomsRequest.SORCaseKey
Param.EndpointURL pxRequestor.pxReqContextURI+"/api/v1/cases/{CASE_Key}"
Note: This parameter is used with both Connect-REST steps.
3. For Step 4 set the Connect-Rest method and a Jump.

a. For the method parameters, set the following values.
Name Value
ServiceName RoomsReq
EndPointURL Param.EndPointURL
49
©2019 Pegasystems
Name Value
MethodName GET
ExecutionMode Run
b. Set a Jump in the event of an error using the FSG-Int RESTErrorDetected when rule. On exception,
Jump to Later StepERR (Step 7).
The configuration will look like the following image.
4. For Step 5, set the following method parameters.
Param.actionID "pyResolveAndCloseCase"
.content.RoomsRequest Primary.RoomsRequest
5. For Step 6, set the method and a jump.

a. For the method parameters, set the following values.
Name Value
MethodName PUT
ExecutionMode Run
c. Set a Jump in the event of an error using the FSG-Int RESTErrorDetected when rule. On exception,
Jump to Later Step ERR (Step 7) otherwise Jump to Later Step CLN (Step 8).
The configuration will look like the following image.
6. For Step 7 method parameters, set Category to NumRoomsConfirmed and Message to SendError.
50
©2019 Pegasystems
7. For Step 8, remove the Interface page.
When you are finished, the Steps tab will look like the following image.
8. Save the activity for use by the process.
51
©2019 Pegasystems
Create the (FSG-Hotel-Work-Hotel) CreateProxyCase activity
Note: In the Configuring the Hotel and Hotel Proxy applications exercise, you named the
CreateProxyCase activity for use in the Create Proxy Case process Integrator shape. To create the
activity, complete the following steps.
1. Save the ConfirmRooms activity as the CreateProxyCase activity that applies to the FSG-Hotel-Work-
Hotel class and Hotel ruleset.
2. On the CreateProxyCase activity rule Parameters tab, do the following
a. Delete the actionID and eTag parameters.
b. Add a parameter named PageName of data type String set to Out.
Update the steps on the activity Steps tab

1. For Step 2 on the Steps tab, do the following:
a. Update the Step to obtain the SOR Case Key.
b. Set the following method parameters.
Param.PageName @Default.PrimaryPageName(tools)
.SORCaseKey @GetInstanceHandle(param.PageName, tools)
The updated step will look like the following image.

a. Use Interface.request.body_POST.content as the Step page.
b. Copy the case's .RoomsRequest into the POST Request's .Content .
c. Set the following method parameter.
.RoomsRequest Primary.RoomsRequest

a. Use Interface.request.body_POST as the Step page.
b. Set Interface.request.body_POST.caseTypeID and process ID as shown in the following image.
c. Set the following method parameters:
.caseTypeID "FSG-Hotel-Work-Hotel-Proxy"
.processID "pyStartCase"
d. Remove the jump condition from Step 4.
52
©2019 Pegasystems

a. Use Interface.request as the Step page.
b. Set the following method parameter:
Param.EndPointURL pxRequestor.pxReqContextURI+"/api/v1/cases"
Note: Only set Param.EndPointURL. Do not set the CASE__KEY in the URL.

a. Issue a POST using the Connect-REST method and Step page Interface to create the Proxy case
by setting the following parameter values:
Name Value
MethodName POST
ExecutionMode Run
b. Do not change the Step 6 jump condition.

When you are finished, the Steps tab on the activity will look like the following image.
53
©2019 Pegasystems
6. Save the CreateProxyCase activity, which is used in the Integrator shape.
Verify your work

Verify your configuration.
54
©2019 Pegasystems
Exercise: Adding a built on application
Scenario
A reusable Hotel application has been constructed. The current case design has a Hotel subcase
"placeholder." The life cycle for the Hotel subcase was purposely left unfinished. You must finish the
life cycle.
The Hotel application now needs to be added to the Booking application as a built-on application.

Admin Admin@Booking rules
Admin Admin@Hotel rules
Admin Admin@HotelProxy rules
Admin Admin@HotelDevOnly rules
Your assignment
Add the Hotel application as a built-on application to the Booking application. Mirror the Hotel
application’s RoomsRequest case type within the Booking application. Provide the ability for the
Booking application to spin off multiple Hotel subcases. Ideally an Event Manager would be able to
select hotels within a reasonable distance of the event venue’s location.
After adding the Hotel application as a built on application replace and update the case type rule used
by the Booking application's Hotel subcase.
Solution Detail
Application-level modifications
The Booking application was previously built on the FSG:01-01-02 application. That configuration was
replaced with Hotel:01-01-02. Ultmately the Hotel application was versioned to 01-01-03 as was the
HotelProxy application and the Booking application, itself.
The Booking applicaton could have manually created a RoomsRequest case type, then deleted its case
type rule. The Booking application could have manaully copied the Hotel application’s RoomsRequest
case type to Booking application’s case type work pool. The direct-inheritance for the new
RoomsRequest case type could have beem manually set to the Hotel application’s RoomsRequest class
Instead, the process described in Pega Help’s Importing case types topic was followed. The first step in
this process is to temporarily change the direct inheritance for the Booking application’s work pool
class, FSG-Booking-Work, from Work-Cover- to the Hotel application’s work pool class, FSG-Hotel-Work.
55
©2019 Pegasystems
Before After
Next the Case Designer’s “Import case types” option was invoked.
The screen shown below was displayed. The Rooms Request case type was then selected, followed by
the Submit button being clicked.
At first the Rooms Request case appeared as a top-level case. It was then configured as a Book Event
subcase.
Before After
56
©2019 Pegasystems
UI Pages relatedmodifications
As when any case type is created, the “Import case types” option will generate “UI Pages” for that case
type. Below shows the RoomsRequestList section that was generated. Note that the section displays the
output of the D_RoomsRequestList list data page, each row in the list being an instance of FSG-Hotel-
Work-RoomsRequest.
The D_RoomsRequestList list data page, generated for the Hotel application’s Rooms Request case type,
is declared Final.
57
©2019 Pegasystems
The remedy is to create a new version of the sourced Report Definition to have it report on descendant
class instances.
58
©2019 Pegasystems
Application Management related modifications
The Data-Portal pyCaseManagerLinks Navigation rule contains two Landing Pages that are only visible
when IsEventManagementWG = true. One Landing Page is named “Rooms”; the other is named
“Weather Cases”. The former displays the FSG-Booking-UIPages RoomsRequest Harness; the latter
displays the FSG-Booking-UIPages WeatherPrep Harness
A Landing Page named “App Management” was also added to the Data-Portal pyCaseManagerLinks
Navigation rule.
The Data Model lesson’s “Template Pattern” discussion is behind the first two links shown above, i.e.,
“Create or Update Hotels” and “Create or Update Venues”. Refer to that lesson for further detail.
The “Create of Update Constants” link provides a way to create and update FSG-Data-Constant
instances. Below within the Weather Prep case discussion a property named “BookingConst” appears.
59
©2019 Pegasystems
The BookingConst property is inherited by any class that starts with “FSG”. This property references the
D_BookingConst Data Page, the class of which is FSG-Booking-Data-ConstProp. The BookingConst
property was created in the Booking ruleset, hence referencing a Data Page based on a class also
defined in the Booking ruleset, namely, FSG-Booking-Data-ConstProp, is perfectly acceptable. Other
applications can do the same thing. For example, the Hotel application is free to define an FSG
HotelConst property that references a D_HotelConst Data Page, the class of which is Hotel-Data-
ConstProp, each rule associated to Hotel application’s ruleset, i.e., Hotel.
The D_BookingConst load activity, LoadBookingConstDP, maps the value for each the FSG-Booking-Data-
ConstProp property from the database as opposed to using a delegated Data Transform. Java step 2.3
is used to perform this task.
ClipboardPage constantPage = tools.findPage("ConstantPage", false);

ClipboardPage primaryPage = tools.getPrimaryPage(); ClipboardProperty prop
= constantPage.getProperty("Value"); String value = prop.getStringValue();
primaryPage.putString(propName,value);
Case-level modifications
Book Event Case

The Manage Event stage was enhanced to add an optional Manage Hotel Service process, the condition
being .HotelService=true. The Crease Case step spins off a Hotel subcase for every page witin the
.RoomRequests Field Group List. The InitFromRoomsRequest data transform defined in the
RoomsRequest case type initializes itself from a Source page named RoomsRequest.
The EventEventDetails section was updated to add a checkbox for the optional hotel service.
60
©2019 Pegasystems
The VolumePricing decision table in the FSG-Data-Pricing class was updated to add ItemID =
“HotelService”. An activity named RecalculateHotel was added to compute the price for the hotel service.
Ideally a reusable activity, or better -- a function, would be developed to compute an item’s price as
well as to set the value of a property defined in the FSG-Booking-Data-PricingDisplay class. Within the
Data Model lesson that follows, the FSG-Data-Pricing class will be refactored to support additional
Pricing Models as well as to move away from reliance on decision tables which could become
cumbersome to maintain over time.
Rooms Request Case

The generated Rooms Request case needed a few updates to get it to work. In the last step of the Email
Hotel stage the Email case had to be selected from the drop down. In the Settings tab, Data
Propagation to the Email subcase was reviewed to ensure that it was configured in the exact same way
that the Hotel application spins off Email case in self-test mode.
61
©2019 Pegasystems
Weather Prep Case Type
An attempt was made to have the Weather Prep case type invoke a REST connector call the Pega API
“data” REST Service asking it to return the output of a D_Forecast data page that outputs an FSG-Data-
Weather-Forecast page. When the D_Forecast data page detects that it was “CalledBySevice”, defined as
@PageExists("MyServicePage"), it invokes the SimulateForecast data transform. At present this roundtrip
is short-circuited; the SimulateForecast data transform is called directly.
In Booking:01.01.02, the Weather case is very simplistic. The SetWeatherCheckDate data transform
invoked prior to the Forecasting stage’s Wait shape sets .WeatherCheckDate = @DateTime.addToDate
(.PrepSLADeadline,"-5","0","0","0"). Note how -5 (five) is hard-coded.
62
©2019 Pegasystems
The number could be -1, one day before the event where the forecast would be more accurate. Either
way, a single forecast is obtained before the case continues to the skippable Preparation stage. Also,
there is no tracking of preparation tear-down tasks, only set up tasks.
In Booking:01.01.03, the Weather case was enhanced. The SetWeatherCheckDate data transform now
sets .WeatherCheckDate = @DateTime.addToDate(.PrepSLADeadline, -1 *
.BookingConst.DaysInAdvanceToBeginForecasting,"0","0","0") when
param.RepeatCall==false. Note how the hard-coding has been eliminated.
The Preparation stage was modified to include a parallel Forecasting process.
63
©2019 Pegasystems
The Preparation process only runs When ShouldPrepForWeather is true. Initially, “false” would be
returned since the weather has yet to be checked. ShouldPrepForWeather will return true when the
ConcernDate on the Weather Prep case is in the future per the FutureConcernDate When rule and when
ConcernProbability >= 40.
The Forecasting process only runs when .PrepInitiated = false meaning forecasting is no longer
necessary once preparation has been initiated. The driver of the Forecasting flow is the GetForecast
activity. The GetForecast activity asks the GetForecast data transform to ask the D_Forecast data page to
return a “precipitation probability list” (.PrecipProbList). The PrecipProbList contains an FSG-Data-
Precipitation page for each day in the forecast’s date range. The forecast is also passed the latitude and
longitude of the event venue’s location. After the forecast is obtained, the GetForecast data transform
scans the PrecipProbList for the first day where the probability is >= 40 (ProbabilityIsConcern). If found,
that Precipitation page is copied to the Weather Prep case’s EarliestPrecipConcern Field Group.
Otherwise the first page in the PrecipProbList is copied.
Verify your work

1. Log into or switch to the “Booking Solution 3” application
2. Click on the Book Event case within the Case Designer then click the “Run” button
3. Select a Venue, proceed to quotation screen and fill it out including selection of the “Hotel Service”
option
a. Choose an Event start date at least 3 weeks in the future
b. Set the Event end date as 3 days after the Event start date
4. Proceed through the FSG Approvals stage
5. Within the Manage Hotel Service process select one hotel then click Submit
64
©2019 Pegasystems
6. After refreshing the screen perhaps twice, investigate the Weather Prep and Room Request
subcases starting with Rooms Request
7. Test the Rooms Request subcase the same way as the preceding “Constructing the Hotel and Hotel
Proxy applications” exercise. The difference here is that the Rooms Request case’s “Enter Test Data”
stage is skipped since HasCover returns true. Also, due to being logged into the Booking application
as Admin@Booking, and not the HotelDevOnly application as Admin@HotelDevOnly, it is not
possible to switch to the HotelProxy application directly. Instead, launch a new browser session,
enter the prweb URL, then log in as the hotel contact.
8. Test the Weather Prep case by continuing past the Timer at the beginning of the flow. Because the
event’s date range spans multiple days, the second day of the event will have Probability = 40. The
Preparation process is bypassed initially but the Forecasting process is not. The Forecasting process
should see that possibility of rain on the second day of the event is >= 40. The Forecasting process
will tell the stage to restart. This time the Preparation process will start but the Forecasting process
will not. Complete the weather preparation set up, wait, tear down steps. Note the Case Designer
changes the instructions for the tear down step.
9. Finally, go back to the Book Event case and resolve it..
Import the Solution RAP file to review the Event Booking application, which is built on the Hotel
application.
Exercise: Implementing an effective data

model
Scenario
The development team is preparing for the first sprint. Before starting, the team has been asked to
review the current data model to help establish a more robust enterprise class structure (ECS) that
encourages reuse and modularity.
65
©2019 Pegasystems

Your assignment
Analyze, review, and r-factor the current data model as necessary. Make sure data class names are
consistent with the FSG Organization layer and the Event Booking application to maximize reusability
and minimize the need for future refactoring.
Solution detail
Evaluate the data model
1. Review the data model and class hierarchy.
2. Evaluate current property placement and their structure(s).
l Which data classes are in the Implementation Layer?
l Which data classes are in the Enterprise Layer?
l Which data classes should be moved?
Possible calculations required by the Event Booking application

Consider the following possible calculations required by the Event Booking application and what
impact the data model has on calculation configurations:
l Base price
l Discounted parked car price
l Invoice due date
l Profit
l Qualified hotel reservation cost
l Qualified hotel reservation price
l Qualified parking and shuttle cost
l Qualified parking and shuttle price
l Total Event cost
l Total event price
Recommended Changes
Currently, the FSG-Booking-Data-Contact class and its related .Contact page are used to capture
customer contact information. After a careful analysis of the current data model you have determined
that this configuration can be improved. You will use the Pega Platform Data-Party-Com class and the
related pyWorkParty page group to store the customer contact information.
66
©2019 Pegasystems
Implement the recommended changes
To implement the changes, you must replace the current FSG-Booking-Data-Contact class with the Data-
Party-Com class. Then you must add data types to the Data Explorer. Do the following:
1. Update the pyCaseManagementDefault work parties record.
2. Update the EditEventDetailsContact section.
3. Update the pySetFieldDefaults data transform and Quotation process.
4. Refactor the classes.
5. Add the data types to the Data Explorer.
Update the pyCaseManagementDefault work parties record

1. In the App Explorer, open the (FSG-Booking-Work-Event) pyCaseManagementDefault work parties
record and add a new party by entering the following values.
Field Value
Label Customer Contact
Role Contact
Party class Data-Party-Com
Party prompt Customer Contact
Data transform NewParty
2. Enable the VOE? check box for both the Owner and Contact parties.
3. In the App Explorer, open the (Data-Party) Validate activity.
4. Copy the activity by changing the Apply to class to Data-Party-Com and the Add to ruleset value to
EventBooking. Keep the same Label and Identifier values.
5. To create a new (Data-Party-Com) Validate activity, click Create and open
6. In the activity record, in the activity Steps tab, comment out ("//") or delete every step in the activity.
7. Save the activity.
Update the EditEventDetailsContact section

1. In the App Explorer, open the (FSG-Booking-Data-Contact) EditEventDetails_Contact section.
2. Copy the section by changing the Apply to class to Data-Party-Com and the Add to ruleset value to
EventBooking. Keep the same Label, and Identifier.
3. Click Create and open to create the new section.
4. In the section record, replace .Name with .pyFullName, .Phone with .pyPhoneNumber, .Company with
.pyCompany, and .Email with .pyEmail1. Then save the section.
5. In the App Explorer, open the (FSG-Booking-Work-Event) EditEventDetails section and do the following:
a. In the Pages and Classes tab, add Page name .pyWorkParty(Contact) with Class Data-Party-
Com. Then, delete the Page name .Contact of Class FSG-Booking-Data-Contact.
67
©2019 Pegasystems
b. In the Design tab, open the Cell Properties dialog for the Contact section and change the
PageContext to Use clipboard Page .pyWorkParty(Contact).
c. Save the section.
Update the pySetFieldDefaults data transform and the Quotation process

1. In the App Explorer, open the (FSG-Booking-Work-Event) pySetFieldDefaults data transform record and
delete the row that sets .Contact.pyLabel = " " and then save the data transform.
2. In the App Explorer, open the (FSG-Booking-Work-Event) SetTestDataFields data transform record.
3. In the Definition tab, change the current Target values to new values as shown in this table. Then
save your updated data transform.
Current value New value
.Contact.Name .pyWorkParty(Contact).pyFullName
.Contact.Company .pyWorkParty(Contact).pyCompany,
.Contact.Email .pyWorkParty(Contact).pyEmail
.Contact.Phone .pyWorkParty(Contact).pyPhoneNumber.
4. Save the data transform

5. In the Cases Explorer, select the Event Booking case type.
6. In the Workflow tab, open the Quotation process.
7. In the connector before the Edit Event Details assignment shape, set properties by applying
SetTestDataFields.
8. Delete the (FSG-Booking-Work-Event) .Contact property.
Refactor the classes

From the Designer Studio menu, select System > Refactor > Classes and select Delete a Class. Then,
enter Class FSG-Booking-Data-Contact and select Next 3 times and then Finish and Done.
Add data types to the Data Explorer

1. From the drop-down list in the Data Explorer header, select Add data type.
2. Add the following existing data types
l (Booking) FSG-Data-Event
l (Hotel) FSG-Data-Hotel (this data type may have already been added)
l (Hotel) FSG-Data-Hotel-RoomsRequest
l (Parking) FSG-Data-ParkingLot
l (Parking) FSG-Data-Shuttle (this data type may have already been added)
l (Weather) FSG-Data-Weather
3. From the drop-down list in the Data Explorer header, select Show case types.
Verify your work

To verify your work, test your implementation and then review your data model.
68
©2019 Pegasystems
Test your implementation
Run an Event Booking case to test your implementation. Note that your Customer Contact now appears
as a participant (work party).
Review your refactored data model

l Review the data types and property relationships
l Review the data classes
l Discuss the your design and your approach
Examine the data types and their property relationships

Use the Data Visualizer tool to give you a visual depiction of the relationships between the selected
data type and its properties as follows:
1. In the Data Explorer, select a case type. This opens the data type record.
2. in the record header, select Visualize. For the Event Booking case type, you should see the
following relationship.
For the Parking case type, you should see the following relationship.
69
©2019 Pegasystems
Review the data classes
Review the data classes and their purpose as described in the following table.
Data class Purpose

Data-Party-Com Represents .pyWorkPage.pyWorkParty(Contact)
FSG-Data-Event Provides Event Booking Details
FSG-Data-Hotel Used to drive the number of Hotel Rooms Request subcases that
are generated.
FSG-Data-Hotel-RoomsRequest Provides Hotel Rooms Request Details
FSG-Data-ParkingLot Provides Parking Lot Details
FSG-Data-Shuttle Provides Shuttle Company Details
FSG-Data-Weather Provides Weather Details
FSG-Data-Weather-Preparation Provides Weather Preparation Details
70
©2019 Pegasystems
Exercise: Data driven behavior
Scenario
FSG wants to differentiate event handling behavior based on the event’s category and, if needed, the actual
venue. For example, a venue may be an indoor concert or, if a sport, the venue might be a domed stadium so
would not require weather preparation.
The FSG Event Booking design team does not want the case structure to test the existing Venue field group
property using numerous When rules, then respond appropriately whenever the When rules return true. Instead
FSG would like to “tell” the Venue instance the step that has just been entered within a certain case type and have
the Venue data object drive the case’s behavior.

Your assignment
Modify the Weather case type to allow the Venue instance to determine if weather preparation is necessary.
For example, at the beginning of the Weather case a VisitCaseStep data transform could be called and passed
three parameters:
l Step: ”Wait for Check Date”
l Case: ”Weather”
l Page: ”pyWorkPage”
If the Venue instance knows that it does not need to perform weather preparation, the Venue instance should
cause the Weather case to close. If the Venue data object knows that it does need to perfrom weather
preparation, then the Weather case should be allowed to continue processing and eventually stop at the time
dependant Wait shape. This processing should take place without adding a Fork shape to the Weather case’s
WaitForCheckDate flow.
Detailed steps
1. On your exercise system, log on as Admin@Booking.
2. Switch to DEV Studio mode.
3. In DEV Studio, modify the Weather Case Type case life cycle as follows:
a. Add an "intelligent" Venue data instance.
b. Configure the weather case to wait, check for precipitation, and prepare for precipitation only if the venue
indicates that weather preparation is necessary.
4. On the parameters tab, add the following properties:
l Step
l Case
l Page
5. At the bottom of the tab select and add a record using the following data and values.
Data Values
Step Wait for Check Date
Case Weather
Page pyWorkPage
6. In the Options column next to the right of the View type, select Create a New View and then click Submit.
This creates a new (FSG-Data-Precipitation-Forecast) GetWeatherForecast_Forecast section and embeds it in the
(FSG-Booking-Work-Weather) GetWeatherForecast section.
Modify the Weather case type to automatically resolve if Weather

preparation is not required by the Venue
Modify the Weather case. Do the following::
1. Complete step 1 as follows:
a. Complete step 1a,
b. Then complete step 1b.
Verify your work

1. Create an Event case. Continue until the subcases are spun off including a Weather subcase.
2. Open the Weather subcase and advance it to the Get Weather Forecast view.
Exercise: Enhancing the Pricing Data Model
Scenario
The FSG-Data-Pricing data model has met FSG’s needs thus far. Currently the Recalculate Data Transform
supports UNIT and VOLUME as values for the PricingModel property. FSG would like to see the tiered pricing
model supported as well.

Your assignment
Design a solution where the FSG-Data-Pricing Recalculate Data Transform implements a different pricing strategy
based on the value of the PricingModel property without using When/Other When/Otherwise logic. The solution
should be able to support a tiered pricing strategy.
There are two ways to perform Volume pricing. One way is for the returned pricing to include the quantity. The
unit price per item could be derived by dividing the returned pricing by the quantity. The second way to perform
Volume pricing is for the lookup to return the unit price per item. In this situation, the total price is the identified
unit price multiplied by the lookup quantity.
Tiered pricing always uses the unit price approach where there is a stated price per item. The unit price in the
range associated to the quantity is multiplied against (quantity – range_start). Then each lower range is priced
as: unit_price_in range * (range_end – range_start).
The table below shows that for an event with 12,000 attendees, FSG would be able to change an extra $10,000,
plus an extra $1500 for hotel service. FSG’s cost does not change; only the amount that it charges has changed.
As opposed to charging $6.67 per attendee within the 0-to-6000 attendees range, FSG would instead charge
$8.33.
Item Qty Qty Volume Unit Cost Unit Tier

ID From To Price Price Cost Price
Event 0 6000 50000 8.33 30000 5.00 50000
Event 6000 12000 80000 6.67 40000 3.33 90000
Event 12000 100000 5.95 50000 2.95
HotelService 0 6000 4000 0.67 2000 0.33 4000
HotelService 6000 12000 5000 0.42 3000 0.25 6500
HotelService 12000 6000 0.35 4000 0.20
Your solution should include a brief design analysis followed by description of the recommended solution.
Solution Design Analysis

To eliminate the need to use When/Other When/Otherwise logic, some form of specialization based on the
PricingModel property is required. For obvious reasons, ruleset specialization is not appropriate.
The FSG-Booking-Work-BookEvent case possesses a .Pricing Page List property that references D_PricingList using
the case pzInsKey. FSG-Data-Pricing records are persisted to the database, they are not held in the BookEvent
case’s BLOB (pzPvStream). The .Pricing Page List is not used by the Booking application as explained below.
Currently there are only two things that FSG charges for, event hosting and optional hotel service. When an Event
is created, both items are initialized within the FSG-Booking-Work-BookEvent case’s InitPricing activity before
being saved to the database. At this point, pricing had been calculated since the number of event attendees, and
whether hotel service is desired, is not yet known.
Once the value of those two properties are known, FSG-Booking-Work-BookEvent calls a Recalculate activity. The
Recalculate activity initializes TotalCost, TotalPrice, and Profit before calling RecalculateHotel. Afterward the
Recalculate activity retrieves the FSG-Data-Pricing record for the Event that was originally persisted by the
InitPricing activity. The Recalculate activity initializes the FSG-Data-Pricing “PricingSavable” page setting Quantity,
DiscountFactor, and Bit, the latter indicating whether or not the record is selected. Since the Event must always
be selected, the value for Bit is set to 1.
Currently the PricingModel for an FSG-Data-Pricing record is decided by the PricingModel Decision Table. In the
future this could be moved to an FSG-Data-PricingModel data type. The Decision Table is called in the first step
the FSG-Data-Pricing Recalculate Data Transform. In the future this step could be replaced by a D_PricingModel
lookup.
How to specialize a pricing record based on the value of its .PricingModel property boils down to two
approaches:
l Circumstancing
l Clas Specialization
At first the use of circumstancing seems the most appropriate since the number of different pricing models
would never grow large. The same argument though can be made for using class specialization. Maintaining a
small number of specialized classes would be easier than maintaining a large number.
An advantage that class specialization has over circumstancing is that a different number of rules can be
leveraged to derive each PricingModel-specific solution. With circumstancing, everything that is specialized must
have a base rule, even if that rule is never used. Circumstancing is ideal for situations where there is a single
rule that is applicable to the majority of situations and where specializations of that rule rarely needed.
Class Specialization would best satisfy the Build for Change guardrail. From an ease-of-maintenance perspective,
pattern-inheritance would be the best approach.
Tiered Pricing Solution

It is questionable whether computing a tiered price using an evaluate-all-rows Decision Table is possible. Even it
were possible, itis questionable whether that approach would be easy to maintain over time or would it, instead,
become cumbersome.
In the long run, it would be better to store price information in a database table. The information contained in
the UnitPricing and VolumePricing Decision Tables belongs in a separate Data class. The obvious name for that
Data type is FSG-Data-Price.
FSG-Data-Price
Property Name Description
ItemID Unique ID for a priced item
Price Price
Currency Unit of currency associated to the price, e.g., USD
QtyFrom Integer whole number start of a range
QtyTo Integer whole number end of a range
PricingModel UNIT, VOLUME, TIERED
IsUnitPrice Whether the price applies to each item or is the final price
The DerivePricing Data Transform defined in the FSG-Data-Pricing-Tiered class could ask the D_PriceList FSG-
Data-Price List Data Page to fetch every row associated to an Item ID where PricingModel = TIERED. An ascending
sort would be applied to the “QtyFrom” value. The DerivePricing Data Transform would then iterate the results
accumulating a tiered price. The iteration would end after QtyTo value is either greater than Quantity or the
QtyTo value is undefined.
Solution detail
Rather than the PricingModel Decision Table returning the value for the PricingModel property, it can set that
value directly and, instead, return a pxObjClass value for the Recalculate Data Transform to set. The Recalculate
Data Transform can subsequently apply a stubbed-out Data Transform named DerivePricing. The logic that
currently exists within the Recalculate Data Transform for Unit and Volume pricing would be moved to FSG-Data-
Pricing-Unit and FSG-Data-Pricing-Volume DerivePricing override transforms. The logic for the FSG-Data-Pricing-
Tiered DerivePricing override transform would then need to be developed.
FSG-Data-Pricing -Unit -Volume -Tiered

DerivePricing DerivePricing DerivePricing DerivePricing
PricingModel
Recalculate
It becomes apparent once the new pattern-inheriting classes are created, that the opportunity to use
encapsulation from the beginning had been missed. For example, the UnitPricing Decision Table belongs in the
FSG-Data-Pricing-Unit class, and the VolumePricing Decision Table belongs in the FSG-Data-Pricing-Volume class.
Similarly, The UnitPrice an UnitCost properties belong in FSG-Data-Pricing-Unit and VolumePrice, VolumeCost,
and VolumnPriceIncludeQty belong in FSG-Data-Pricing-Volume.
FSG-Data-Pricing -Unit -Volume
DeriveUnitPricing UnitPrice VolumePrice
DeriveVolumePricing UnitCost VolumeCost
UnitPricing UnitPricing VolumePriceIncludesQty
VolumePricing VolumePricing
UnitPrice
UnitCost
VolumePrice
VolumeCost
VolumePriceIncludesQty
Verify your work

1. Create an Event case.
2. Evaluate how pricing is calculated.
3. Review the configuration.
Exercise: Exposing integration using a data type
Scenario
Front Stage needs to know if the probability of precipitation equals or exceeds 40 percent during the an event. At
present, the weather forecast queries a data transorm. Front Stage now wants to query a true weather forecast
service the day before an event.
The forecast is performed for the location where the event is being held, as opposed to the user's browser
location. Given that the role of the user is Facility Coordinator, assume the browser user is in close proximity to
the event.

Your assignment
Using the existing data class FSG-Data-Precipitation-Forecast, simulate a weather forecast service query that
returns the probability of precipitation for each day of an event.
Create and interface a data page to pull the weather forecast. The parameters when querying the service are:
l StartDate
l EndDate
l Latitude
l Longitude
The response is a list of pages where each page resembles the FSG-Data-Precipitation class.
{ "forecast":[ { "Date":"20170731" ,"Probability":"35" ,"Unit":"Percent" }, {
"Date":"20170801" ,"Probability":"40" ,"Unit":"Percent" } ] }
Enable geolocation at the case type level and portal level. When enabled, the pxRequestor system page contains
the following location fields:
l pxRequestor.pyLatitude
l pxRequestor.pyLongitude
Use any weather URL for the simulated weather service (for example, http://weatherforecast.com). Develop a UI
to display the request parameters. The REST response contains as many elements as the number of days the
event is held. Post-process the response to identify the first day where the probability of precipitation equals or
exceeds 40 percent.
Detailed steps
To complete the assignment, you will:
1. Create a new RainForecast REST Connector.
2. Create a new D_ForecastService data page.
3. Configure the new D_ForecastService data page to use the REST Connector.
4. Create a Simulation Activity as the Web Service is not available.
5. Configure the RainForecast REST Connector to use the simulation activity.
6. Enable Geolocation tracking to capture the location of the operator.
7. Create and configure a ForecastService property to use the new D_Forecast data page.
8. Modify the Weather case life cycle to conditionally make precipitation preparations.
Create a new RainForecast REST Connector

1. From the Designer Studio menu, select Integration > Connectors > Create REST integration to start the
New REST Integration wizard.
2. On the Connection form, enter the following values.
Description Value
Name Rain Forecast
Endpoint URL http://weatherforecast.com
Query string parameters StartDate
EndDate
Latitude
Longitude
When you are finished, the completed tab will look like the following image.
3. Advance to the Resource methods form. in the Name field, enter Forecast . Use the default GET method as
shown in the following image.
4. Advance to the Data model form. Save the example response text to a file. Click + Add a file to add the text
file as shown in the following image.
5. Advance to the Review form. Change the parent class to FSG-Int. Change the generated class to FSG-Int-
RainForecast. Do not generate a Data layer and select Skip (I'll do it later. When finished, the form will look
like the following image.
6. Click Create to complete REST integration.
Create a new D_ForecastService data page
1. In the Data Explorer, expand Forecast and select the Forecast data page (D_Forecast).
2. Click Save As to save the D_Forecast data page to a new D_ForecastService. Enter the following values:
Field Value
Label Forecast Service
Identifier D_ForecastService
Apply to FSG-Data-Precipitation-Forecast
Add to ruleset Weather
3. Click Create and open to create the new D_ForecastService data page.
4. In the Parameters tab of the D_ForecastService data page, delete the pyGUID parameter.
5. In the Parameters tab of the D_ForecastService data page, add the following Required Yes, In/Out In
parameters:
l StartDate (String)
l EndDate (String)
l Latitude (Decimal)
l Longitude (Decimal)
Configure the new D_ForecastService data page to use the new RainForecast
REST Connector
1. In the Data sources section in the Definition tab of the D_ForecastService data page, update the following
values:
Field Value
Source Connector
Type REST
Name Forecast
Request Data Transform ForecastRequestGET
Response Data Transform ForecastResponseGET
2. Select the Parameters link under Request Data Transform and enable the Pass current parameter page
check box in the Parameters for ForecastRequestGET dialog.
3. Select the Parameters link under Response Data Transform. In the Parameters for
ForecastResponseGET dialog, enable the Pass current parameter page check box.
a. Create the Request Data Transform ForecastRequestGET using Add to ruleset RainForecast.
b. On the Parameters tab, require the same parameters as the D_ForecastListService data page.
c. On the Definition tab, select ActionUpdate Page for Target.request.query_GET and Set the properties as
d. Create the Response Data Transform ForecastResponseGET using Add to ruleset RainForecast. Click
Create and open and then Save to create and save the auto-generated ForecastResponseGET data
transform.
e. Save the D_ForecastListService data page.
Create a simulation activity for the RainForecast REST connector

Simulate the Forecast REST connector to return as many FSG-Int-RainForecast-Forecast pages as there are days
between StartDate and EndDate inclusive by doing the following:
1. Create an activity within the FSG-Int-RainForecast-ForecastAPI class and RainForecast ruleset named
SimulateRainForecast.
2. In the activity Parameters tab, define an Out parameter NumDays (Integer), an In parameter StartDateTime
(Date Time), and an In parameter EndDateTime (Date Time). The completed tab should look like the following:
3. In the Steps tab for activity step 1, enter Property-Set Param.NumDays = @DateTime.DateTimeDifference
(Param.StartDateTime, Param.EndDateTime, "D").
4. For activity step 2, enter Repeat For loop, Minimum Value = 0, Max Value = Param.NumDays, Increment =
1. Property-Set the following:
l .response_GET.forecast(<APPEND>).Date = @DateTime.addToDate( .request.query_
GET.StartDate,param.pyForEachCount,0,0,0)
l .response_GET.forecast(<LAST>).Probability = 40
l .response_GET.forecast(<LAST>).Units = “Percent"
The completed Steps tab should look like the following:
5. Save the activity for getting the forecast information.
Configure the RainForecast REST Connector to use the simulation activity

1. Open the Forecast REST connector record, click the Simulations button and add the SimulateRainForecast
activity.
2. Click one or both context radio buttons (Global and User Session)
The completed Simulations dialog should look like the following.
3. Click Submit to save your forecast simulation.
4. Return to the ForecastResponseGET response data transform and implement as the following:
a. In the Parameters tab, delete parameter pyGUID and add the following In parameters:
l StartDate (String)
l EndDate (String)
l Latitude (Decimal)
l Longitude (Decimal)
b. In the Definition tab, update step 1 as follows:
Field Value
Action Append To
Target Primary.pxResults
Relation each page in
Source DataSource.response_GET.forecast
c. Click Save to save the updated data transform.

5. Create a Post load processing activity for the D_ForecastService data page named PostRainForecastProc using
Add to ruleset Weather.
6. In the Security tab of the activity, set the PostRainForecastProc Activity type = Load Data Page.
7. In the Pages and Classes tab, declare a Page name D_ForecastService.pxResults using Class FSG-Data-
Precipitation-Forecast.
8. In the Parameters tab, define an Out parameter Name IndexToSave using Data type Integer with Default
value 0.
9. In the Steps tab, do the following:
a. In step 1, enter Property-Set where Param.IndexToSave = 0.
b. In step 2, set Loop Repeat to For each embedded page in Step page D_ForecastService.pxResults
capturing the first index where Probability >= 40%. To configure the loop, do the following:
i. Use Method Property-Set where Param.IndexToSave = Param.pyForEachCount.
ii. Click When and set the condition to Enable conditions before this action with When
.Probability>=40 if true Continue Whens if false Exit Iteration.
c. In step 3, use Method Exit-Activity and set When to Enable conditions before this action with When
Param.IndexToSave==0 if true Exit Activity if false Skip Step.
d. In step 4, use Method Page-Copy to CopyFrom D_ForecastService.pxResults (param.IndexToSave) to
CopyInto D_ForecastService.
e. In step 5, use Method Property-Set with Step page D_ForecastService.pxResults(param.IndexToSave) to
set Primary.Date = .Date, Primary.Probability = .Probability, and Primary.Unit = .Unit.
The completed Steps tab should look like the following.
Enable Geolocation tracking and capture the location of the operator.

1. From the Cases Explorer, open the Weather case type .
2. On the Settings tab in the General section, enable Enable geolocation tracking.
3. Create Whenever Used declare expressions for the (FSG-Booking-Work-Weather) Weather.Latitude and
Weather.Longitude properties in the Weather ruleset:
a. (FSG-Booking-Work-Weather) .Weather.Latitude = pxRequestor.pyLatitude
b. (FSG-Booking-Work-Weather) .Weather.Longitude = pxRequestor.pyLongitude
Create and configure a ForecastService property to use the new D_Forecast
data page
1. Copy the (FSG-Booking-Work-Weather) Forecast property to (FSG-Booking-Work-Weather) ForecastService.
2. For the new ForcastService property, change Data access from Refer to a data page to Copy from a data
page. Change the Data Page to D_ForecastService. Configure the parameter as shown below:
Modify the Weather case life cycle to conditionally prepare for precipitation
1. In Pega Express, open the Weather case type from the Cases Explorer.
2. Change the Start process (otherwise skip) to Custom condition.
3. For the Prepare for Weather process in the Preparing stage, use a When condition.
4. Next to the condition field, click the gear icon to add the condition as shown in the following image. If
.Forecast_service is not displayed, configure the condition as Rain probability is 40 or greater.
5. Save the life cycle to generate the When rule.
6. In Designer Studio modify the generated when rule to use .ForecastService.Probability or the
Forecast.Probability as shown in the following image.
Verify your work

1. Create an Event case and advance the case to where child cases are spun off.
2. Select Begin for a Weather Case.
3. If the case is paused at the Wait for Day before Event step, click Yes (continue). If necessary, click Begin.
The Get Weather Forecast view is displayed.
Exercise: Extending an industry foundation data

model
Scenario
The Human Resource department at Front Stage is working with the organization's healthcare insurance
provider, MyHealth. MyHealth offers a web service to enroll new employees into the health plan. MyHealth uses
an industry standard model for receiving requests.
Front Stage uses Pega's Healthcare Industry Foundation data model to build applications for employees to
manage changes to their coverage. The new enrollment application will be available from Front Stage's employee
portal. Only Front Stage HR has access to the desktop client that MyHealth provides to enroll new members. This
is a new area of application development for Front Stage. Front Stage does not have a center of excellence (COE)
in place yet, but plans to establish a COE within the year.
Your assignment is to map the MyHealth web service response elements to the Front Stage's data model. Once
you complete the analysis, you will assign a member of your team to add new properties, create the integration
rules, map the MyHealth web service properties to Front Stage, and test the round trip web service. The web
service must return a response within 1 second or less to meet the business service level agreement to enroll
1000 employees in one day.
Approach
Create a mapping document that you can hand off to a member of your team to implement. For the purpose of
this exercise, focus on mapping elements of the PegaHC-Data-Party-Member class. Download the MyHealth
member data dictionary spreadsheet to use as the system of record data model. Only map the entries from the
spreadsheet. You do not need to map all properties from the Member class.
Consider an alternative approach if during testing you find that the web service is not meeting the requirements
of the business service level agreement.
Solution Detail
Your first step is to identify the fields contained in the sample data spreadsheet . Next, go to Pega Community
and open the Pega Foundation for Healthcare 8.3 Data Model ERD and the Pega Foundation for Healthcare 8.3
Data Model. For each field in the sample data spreadsheet, look up the corresponding property in the data
model and record the property's name and class. If there is a new property name, highlight that property and
identify in which class the new property should reside.
The result of your analysis is a map of the system of record data elements to the industry data model properties
and any new fields that need to be added to the PegaHC-Data-Party-Member class in the organization ruleset of
your application. In the future, the Front Stage COE will manage the data model and integration rules.
Solution Alternatives
If the web service does not perform according to the business SLA, you could investigate the usage of robotic
desktop automation (RDA). Access to the MyHealth member enrollment application is restricted to HR, therefore,
RDA is not a viable solution. Robotic process automation (RPA) could also be used in conjunction with an
enrollment case type to invoke the process automation in the background, making RPA a viable option to
consider.
Exercise: Routing weather cases to facility

coordinators
Scenario
If the probability of precipitation is greater than 40 percent for any of the event days a process to make
arrangements is started. A facility coordinator with the least amount of urgent work that is specialized in
weather preparation is assigned the following tasks.
l Set up tents
l Provide disposable raincoats
l Cover seating area

Your assignment
Design and implement the routing for the weather preparation to satisfy the requirements. Consider viable
alternatives comparing the pros and cons to produce the best solution.
The sample facility coordinator users are specialized as shown in the following table.
Operator Specialization
FacilityCoordinator1@Booking Parking
FacilityCoordinator2@Booking Weather
FacilityCoordinator3@Booking Weather and Parking
Solution detail
Consider routing based on skills and work parties.
Skill-based routing
1. in your exercise system, log on as Admin@Booking.
2. In the Parking ruleset, create a new Parking skill using Create > Process > Skill .
3. In the Weather ruleset create a new Weather skill using Create > Process > Skill.
4. In the Facility Coordinator operator records, add the appropriate Parking and/or Weather skills as described in
the Your Assignment section of this exercise.
5. For all three Facility Coordinators, change the default work groups to Facilities@FSG.
6. Select Create > Organization > Work Group to create a new Facilities@FSG work group.. Set the Manager to
the provided Manager@Booking operator and the Default workbasket to the provided
Booking:FacilityCoordinator workbasket. As Authorized managers add the Admin@Booking operator.
Configure the Prepare for Precipitation Step

1. In the Cases Explorer, open the Weather case type.
2. In the General tab enable the Behavior Skip 'Create' view when users create a new case checkbox.
3. In the Data model tab ensure that the Tents Setup, Seating Area Covered, and Disposable Raincoats
Provided fields are of Type Boolean.
4. In the Workflow tab in the Preparing stage, select the Prepare for Precipitation step .
5. Select Configure view and add fields Tents Setup, Seating Area Covered, and Disposable Raincoats Provided
as shown in the following image.
6. Click Submit to create the Prepare for Precipitation section.

7. Use the ToLeveledGroup router to route the case to a user in Facilities@FSG work group with the designated
skill. In the following example, the Weather skill is specified.
Configure the Wait for Day Before Event step
1. In the Cases Explorer, open the Weather case type.
2. In the Workflow tab in the Forecasting stage, select the Wait for Day Before Event step.
3. Configure the Wait type as Timer.
4. Select the Reference date/time radio button and enter .Weather.DayBeforeStartDate as the Date/Time.
Work party routing

In the first assignment performed in the Prepare for Weather process, add the facility coordinator as a work
party using the standard addWorkObjectParty activity as a post activity.
1. Open the (FSG-Booking-Work-Event) pyCaseManagementDefault work parties record.
2. On the work party record, select Save As and save pyCaseManagementDefault using the Apply to FSG-Booking-
Work class and Add to EventBooking ruleset. Then click Create and open to create a new rule that shares the
pyCaseManagementDefault work parties rule by way of pattern inheritance.
3. In the new work parties rule, do the following:
a. In the Valid Parties tab on the new work parties rule, add a new FacilityCoordinator Role using Data-Party-
Operator as the Party class, Facility Coordinator as the Party label, Facility Coordinator as the Party
prompt, and CurrentOperator as the Data transform.
b. In the Data transform field for the Interested Role, add NewParty as shown in the following image.
4. Save the work parties rule.

5. Change the Availability to Withdrawn for the existing (FSG-Booking-Work-Parking) pyCaseManagementDefault
and the existing (FSG-Booking-Work-Parking) pyCaseManagementDefault work parties rules. Both the Parking
and Weather case types will now reuse the (FSG-Booking-Work) pyCaseManagementDefault work parties rule.
6. Open the (FSG-Booking-Work-Weather) PrepareForPrecipitation flow action.
7. In the flow action Action tab configure the Run activity field in the Post-Processing section to call the
addWorkObjectPartyactivity. Use PartyRole FacilityCoordinator, PartyClass Data-Party-Operator, and
PartyModel CurrentOperator as the Parameters.
Adding the facility coordinator as a work party allows users reviewing the case to easily see who is the facility
coordinator.
You can route subsequent assignments to the FacilityCoordinator work party. Do not route to the Current
operator because it can lead to problems. For example, if the previous assignment were processed by an SLA,
the ToCurrentOperator router results in an error. The following example shows routing for the Review
Preparations assignment.
Configure Parking case routing

Configure Parking cases to route to facility coordinators with the Parking skill and add that facility coordinator as
a work party to the Parking case.
1. In the Cases Explorer, open the Parking case type.
2. Use the ToLeveledGroup router to route the Reserve Shuttles step in the Preparation stage to a user in
Facilities@FSG work group with the designated skill. In the following example, the Parking skill is specified.
3. Open the (FSG-Booking-Work-Parking) ReserveShuttles flow action.

4. In the flow action Action tab configure the Run activity field in the Post-Processing section to call the
addWorkObjectPartyactivity. Use PartyRoleFacilityCoordinator, PartyClassData-Party-Operator, and
PartyModelCurrentOperator as the Parameters.
5. Select the Enter Number of Cars Parked step in the Collect Results step of the Execution stage of the Parking
case type.
6. In the General tab of the Enter Number of Cars Parked step configure Route to Custom, Assignment type
Worklist, Router ToWorkParty, and Party FacilityCoordinator as shown in the following image.
This ensures that the same facility coordinator that made the shuttle arrangements also enters the number of
cars parked during the event.
Verify your work

1. Create a Booking case.
2. Select Hotel Reservation and Parking and Shuttle Services.
3. Verify that the Reserve Shuttles step in the Parking sub-case was assigned to a Facility Coordinator with the
required Parking skill.
4. Advance the Weather subcase to the Prepare for Precipitation step.
5. Verify that the Prepare for Precipitation assignment in the Weather subcase was assigned to a Facility
Coordinator with the required Weather skill.
6. Import the Solution RAP to review the updated routing for Weather and Hotel subcases.
Two standard routers can be leveraged when using skilled based routing: ToLeveledGroup and ToSkilledGroup.
Both of these routing rules route to a user in a specified work group with the designated skill.
ToLeveledGroup is a valid option because it takes the users current workload into consideration. ToSkilledGroup is
not a valid option in this scenario because this router does not take workload into consideration.
Creating a custom routing activity is a valid option if the routing requirements are not covered by a standard
router. Since ToLeveledGroup takes both skills and workload into account, a custom router is not required.
Exercise: Designing Get Next Work
Scenario
Front Stage (FSG) wants its facility coordinators to collaborate with each other to help meet the goal of completing
work in eight hours. This goal time prevents escalation to the event manager.
FSG wants the most urgent work assigned to a facility coordinator, even if the work is already assigned to another
facility coordinator. When a facility coordinator finishes work on the current assignment, then clicks Next
Assignment, the application should be able to assign work from another facility coordinator according to the
following requirements:
l The originally assigned facility coordinator has not yet started the assignment.
l The application should select the oldest assignment from all the other facility coordinator’s worklists.
l The facility coordinator must have the skills to perform the assignment on the other facility coordinator's
worklist.
l This behavior should only apply to the facility coordinator work group.
The Weather case was created with stages and steps filled out by the business.

Author Admin@Booking rules
Your assignment
Design and configure the Get Next Work solution to satisfy the requirements. Consider alternatives and compare
the pros and cons to select the best approach.
Facilities coordinators possess the following skills, as do members of the same work group.
Department Role Operator ID

Facilities Facility Coordinator FacilityCoordinator1@Booking
specialized in Parking
specialized in Weather
Preparation
specialized in Weather
Preparation and Parking
Solution detail
Configure Booking:FacilityCoordinator access role
For any solution, you need to set up and configure a Booking:FacilityCoordinators access role definition as follows:
1. From your exercise system, log on as Admin.Booking
2. From Designer Studio > Org & Security > Tools > Security > Role Names open the existing Booking:User
access role.
3. Save the Booking:User access role to Booking:FacilityCoordinator and add the new access role to the
EventBooking ruleset.
4. Click Create and open to create the new Booking:FacilityCoordinator access role name.
5. In the Role tab on the access role name record, make sure Clone from displays PegaRULES:User4 and then
click Clone.
6. At the bottom of the table, click the add row icon to open the Add Access Role object dialog.
7. In the dialog, do the following:
a. In Access Class, enter Assign-Worklist. This creates a new Access of Role to Object instance.
b. In Read instances and Write instances, specify a new access when record named
AssignedToMyWorkgroup .
c. Next to either field, click the Create rule icon and create the new AssignedToMyWorkgroup access when
record with the condition .pxWorkGroup = OperatorID.pyWorkGroup.
d. In Delete instances, Read rules, Execute reports, and Execute activities fields, set the value to 5.
e. In the Write rules and Delete rules fields, leave them blank.
8. Click Save to create the new Assign-Worklist Access of Role to Object and close the dialog.
9. On the access role name record, click Save to save the Booking:FacilityCoordinator access role name.
10. Open the Booking:FacilityCoordinator access group, add the new Booking:FacilityCoordinator access role name,
and remove all the other Available roles.
11. Save the access group
Recommended approach
The recommended approach is to circumstance the Assign-Worklist GetNextWork list view. This option meets the
requirements and has the added benefit of extensibility.
For this approach to work, you add a property that is always visible within the requestor’s context. For example,
you can add the PrimaryRole property to the Data-Admin-Operator-ID class. To set the property value with a Rule-
Declare-Expression, follow these steps.
1. From the Records Explorer, create a new PrimaryRole single value text property. Set Apply to the Data-Admin-
Operator-ID class and the ruleset to EventBooking.
2. From the App Explorer, find the Data-Admin-Operator-ID class, right click the PrimaryRole property, and select
Define expression to create a new Declare Expression rule.
3. On the declare expression, do the following:
a. In the Expressions tab, set the Primary Role to the Value of @whatComesAfterLast
(AccessGroup.pyAccessGroup,':')
b. In the Change Tracking tab, set Calculate when to Whenever used and Execute this expression to
Regardless of any pages it is contained in.
4. Save the declare expression. You can use the property and declare expression later to circumstance
additional rules such as the GetNextWorkCriteria decision tree.
This approach mirrors, but does not hide, existing rules. Revealing the rules helps make application upgrades
easier.
Example configuration
This example describes how to circumstance the Assign-Worklist GetNextWork list view using the .PrimaryRole
property. The PrimaryRole property indicates that the user’s role is Facility Coordinator.
The configuration is as follows:
1. In the App Explorer, find and open the existing (Assign-Worklist) GetNextWork list view.
2. Specialize the list view using circumstance by property. Specify the property as OperatorID.PrimaryRole and
the value as FacilityCoordinator.
3. To create the new circumstanced (Assign-WorkList) GetNextWork list view, click Create and open.
4. In the Organize tab of the circumstanced list view, set Sort by column .pxCreateDateTime in Ascending Sort
order.
5. In the Content tab, do the following;
a. Change the existing filter condition from .pxAssignedOperatorID Is equal
pxRequestor.pyUserIdentifier to .pxAssignedOperatorID Is not equal
pxRequestor.pyUserIdentifier.
b. Add a second filter condition to allow every worklist assignment within the user’s work group to be
retrieved. This filter condition is .pxWorkGroup = OperatorID.pyWorkGroup.
Note: This is the same condition used for the AssignedToMyWorkgroup access when rule.
c. Update the Label for each Criteria to A, B, C, and D to accommodate the new condition.
d. Update the Logic field to A AND B AND C AND D to accommodate the new condition.
6. Save the circumstanced list view.
7. Circumstance Assign-.GetNextWorkCriteria decision tree the same way as documented in step 2 above. Add
the Assign-CurUserHasRequiredSkills when rule to the tree such that the decision rule returns true if the
when evaluates to true.
At least two alternative approaches can be used:
l Add a custom button that runs an Open Assignment action.
l Override Assign-Worklist GetNextWork related rules.
Add a custom button to run an Open Assignment action

In this approach, you add a button to the pyPortalHeader section and the application. When the user clicks the
button, the application runs the Open Assignment action. This action requires a key parameter. A non-list data
page provides the key, and then calls an activity that you defined.
To get the key:
l Your activity calls the pxRetrieveReportData activity to run your version of the pyWorkGroupWorkList Assign-
Worklist report definition.
l The report definition sorts the results by ascending pxCreateDateTime instead of pxDeadlineTime.
l The activity evaluates the Assign- GetNextWorkCriteria decision tree to ensure that the user’s skills match those
on the assignment.
l The application copies the assignment to the non-list data page if the decision tree returns a value of true.
l The application uses the pzInsKey of the assignment as the key parameter for the Open Assignment action.
Override Assign-Worklist GetNextWork related rules

In this approach, you override and customize behavior of the Assign- findAssignmentInWorklist activity in this way:
l Save the Assign-Worklist GetNextWork list view to a new name such as GetNextWorkFacilityCoord.
l Create a when rule called IsFacilityCoordinator. Use the selection criteria (@String.whatComesAfterLast
(AccessGroup.pyAccessGroup,’ :’) = “FacilityCoordinators”).
l Add the IsFacilityCoordinator when rule condition to the ShowView step. Set the when rule preconditions
actions to if true Skip step, if false Continue.
l Add a second ShowView step. This time, configure the IsFacilityCoordinator when rule precondition actions if
true Continue, if false Skip step.
l Modify the ShowView activity to run the GetNextWorkFacilityCoord list view. Configure the
GetNextWorkFacilityCoord list view in the same circumstanced GetNextWork list view.
Pros and cons of each approach

The following table describes the pros and cons of each approach.
Design choice Pros Cons

Circumstance Assign- Mirrors the existing Requires additional rules
Worklist GetNextWork Assign-Worklist such as the PrimaryRole
GetNextWork property and Rule Declare
implementation, hence Expression
easier to maintain
More easily extended
Add a custom button Solution not tightly l Need to add redundant
and Open Assignment coupled to Pega rules or custom error
action such as Assign-Worklist handling
GetNextWork ListView l Next Assignment needs
to be hidden for Facility
Coordinators
Override Assign- Fewest new rules needed Affects the Assign-Worklist
Worklist GetNextWork GetNextWork list view
behavior for every user
Exercise: Defining the authorization scheme

Scenario
Front Stage's organizational structure for event planning is displayed in the following image.
The following requirements are provided with regards to security:

l Only sales executives and executive managers are allowed to see financial information.
l A sales executive is able to work on cases created by other sales executives. However, a sales executive is not
able to access a peer’s case for an event larger than 10,000 attendees.
l Event managers are only able to work on cases assigned to them. However, the event manager's team lead
can work on cases assigned to any event manager.
l Facility coordinators can only see and work on cases assigned to them.
l Executive officers can view cases throughout the life cycle and create new custom reports.

The following table provides a list of sample users that are available for testing.
Department Role Operator ID Password

Executives Executive Officer and CEO CEO@Booking rules
Executives Executive Officer ExecutiveOfficer1@Booking rules
Executives Executive Officer ExecutiveOfficer2@Booking rules
Sales Sales Executive SalesExecutive1@Booking rules
Sales Sales Executive SalesExecutive2@Booking rules
Facility Facility Coordinator specialized in FacilityCoordinator1@Booking rules
Parking
Weather Preparation
Weather Preparation and Parking
Managers Event Manager and Team Lead EventManager1@Booking rules
Managers Event Manager EventManager2@Booking rules
Managers Event Manager EventManager3@Booking rules
Your assignment
Design and implement the authorization scheme to fulfill the requirements described earlier.
l Identify access groups and roles.
l Implement the above requirements.
Solution detail
Access groups and roles
Create and configure access groups and roles for each department since access is granted based on the
department.
Check the Booking access groups
When the Event Booking application was first developed the following access groups may have created. If so, the
access group names may not comply with our naming conventions, so you will rename them as needed as listed
in the following table.
POC access group name New access group name

Booking:Executive Booking:Executives
Booking:SalesPerson Booking:Sales
Booking:FacilityCoordinator Booking:Facilities
Booking:EventManager Booking:EventManagers
To rename the existing access groups, do the following:

1. From your exercise system, log on as Admin@Booking.
2. From the Designer Studio menu, go to System > Refactor > Rules and open the Search/Replace a String
wizard.
3. Select Search/Replace a String.
4. In the Original String Value field, enter Booking:Executive. In the New String Value field enter
Booking:Executives.
5. Set Limit search to RuleSets in my RuleSet list? to No.
6. In the Select RuleSet Scope section, select the Booking ruleset. Only select the Booking ruleset. We can do
this because all the affected rules we need to refactor are in the Booking ruleset.
7. Select Next. This page displays a report showing the number of Records with Occurrences and
Occurrences Found.
8. Select Next. This page displays a report showing the Selectable rules available which have references to
the class being refactored. Enable the check box next to Rule Type in the header of the report. This selects
all the records. Optionally, you can Export to Excel to keep a log of the affected records.
9. Select Finish. This page displays a confirmation that the refactoring process is complete and displays a report
of the rule and data instances that were not refactored. Optionally, you can Export Page to Excel and/or
Review Log.
10. Select Done.
11. Repeat steps 2 through 8 to rename the three remaining Access Groups. replace the Original String Value
and the New String Value fields in step 3 with the POC Access Group Name and the New Access Group
Names listed in the table.
System generated roles
The New Application wizard creates a Booking:Administrator role and two user roles: Booking:User and
Booking:Manager.
Users with the Booking:User role can open any case in the application and perform any assignment. The
Booking:Manager role provides the ability to create and update reports, delegated rules, and work groups.
Create Event Booking roles

Create the following roles for each department since permissions and privileges are granted based on the
department. Save the roles to the EventBooking ruleset.
Role name identifier Label Dependent on

Booking:Executive Executive PegaRULES:WorkMgr4
Booking:SalesPerson Sales Person PegaRULES:WorkMgr4
Booking:EventManager Event Manager PegaRULES:WorkMgr4
Booking:FacilityCoordinator Facility Coordinator Already exists
Assign roles to the Event Booking access groups

To the renamed access groups, assign the following roles. Remove all other roles.
Access group Roles

Booking:Executives Booking:Executive, Booking:Manager, Booking:User, PegaRULES:PegaAPI
Booking:Sales Booking:SalesPerson, Booking:User, PegaRULES:PegaAPI
Booking:Facilities Booking:FacilityCoordinator, Booking:User, PegaRULES:PegaAPI
Booking:EventManagers Booking:EventManager, Booking:User, PegaRULES:PegaAPI
Create Event Booking work groups

Create the following work groups for each department because work is often assigned to them. Save the work
groups to the EventBooking ruleset. Also add the authorized managers named Admin@Booking and
Author@Booking to each work group.
Work group identifier Description Manager Default workbasket

Executives@FSG FSG Executives CEO@Booking Booking:Executives
Sales@FSG FSG Sales SalesExecutive1@Booking Booking:Sales
EventManagers@FSG FSG Event Managers EventManager1@Booking Booking:EventManagers
Facilities@FSG FSG Facility Coordinators FacilityCoordinator1@Booking Booking:Facilities
Update Event Booking workbaskets
Update the following workbaskets.
Workbasket Organization unit Work group Role

Booking:Executives Executives Executives@FSG Booking:Executive
Booking:EventManagers Managers EventManagers@FSG Booking:EventManager
Booking:Facilities Facilities Facilities@FSG Booking:FacilityCoordinator
Booking:Sales Sales Sales@FSG Booking:SalesPerson
Assign default work groups to the operators

For each of the following operators, update the default work groups. Also, add the skills and ratings for the
operators defined in the table.
Operator ID Default work group Skill(s) and rating

CEO@Booking Executives@FSG CEO (5), TeamLead (5)
ExecutiveOfficer1@Booking Executives@FSG
ExecutiveOfficer2@Booking Executives@FSG
SalesExecutive1@Booking Sales@FSG
SalesExecutive2@Booking Sales@FSG
FacilityCoordinator1@Booking Facilities@FSG Parking (5)
FacilityCoordinator2@Booking Facilities@FSG Weather (5)
FacilityCoordinator3@Booking Facilities@FSG Parking (5), Weather (5)
EventManager1@Booking EventManagers@FSG TeamLead (5)
EventManager2@Booking EventManagers@FSG
EventManager3@Booking EventManagers@FSG
Allow Executive Officers access to cases throughout the Event Booking life
cycle
To allow Executive officers to view cases throughout the life cycle, edit their operator IDs and grant the operators
access to the following work groups: Executives@FSG (default), Sales@FSG, EventManagers@FSG, and Facilities@FSG.
Do the following:
1. Open the following operator ID records: CEO@Booking, ExecutiveOfficer1@Booking, and
ExecutiveOfficer2@Booking. In the Routing section of the Work tab, do the following:
a. Add the following work groups: Executives@FSG, Sales@FSG, EventManagers@FSG, and Facilities@FSG.
b. Specify Executives@FSG as the default.
c. Set the Reports to field to CEO@Booking.
The completed section looks like the following image.
2. Open the Booking:Executives access group.

3. In the Definition tab, add the following available roles: Booking:Executive, Booking:SalesPerson,
Booking:EventManager, Booking:FacilityCoordinator, and PegaRULES:PegaAPI.
The completed access group looks like the following image.
4. Save the Executive access group.
Update Event Booking case type routing

1. From the Cases Explorer, open the Event Booking case type.
2. In the Executive Review stage, open the Execute Review process. Open the Approve Event Quote smart shape
properties panel and check that Work queue is set to Booking:Executives as shown in the following image.
3. In the Assignment stage, open the Assignment process. In the Accept Event Assignment smart shape, verify
that Work queue is set to Booking:EventManagers as shown in the following image.
4. in the Preparations stage, open the Hotels process. Open the Select Hotels assignment properties panel and
verify that Specific user is set to .EventManager as shown in the following image.
5. In the Resolve stage, open the Resolve process. Open the Collect Feedback assignment properties panel and
verify that Specific user is set to .EventManager.
6. In the Reservations Problem alternate stage, open the Reservations Problem process. Open the Adjust Hotel
Reservation assignment properties panel and verify that Specific user is set to .EventManager.
Update Parking case type routing

1. From the Cases Explorer, open the Parking case type.
2. In the Preparation stage, open the Prepare for Parking process. Open the Reserve Shuttles assignment
properties panel and verify the following settings.
Field Setting
Route to Custom
Assignment type Worklist
Router ToLeveledGroup
Workgroup Facilities@FSG
Skill Parking
3. In the Execution stage, open the Collect Results process. Open the Enter Number of Cars Parked assignment
properties panel and check verify the following settings.
Field Setting
Route to Custom
Router ToWorkParty
Party FacilityCoordinator
4. In the Preparation stage, open the Prepare for Parking process. On the Reserve Shuttles connector, open the
ReserveShuttles flow action. On the flow action Action tab, in the Post-processing section, enter the following
settings.
Field Setting
Run activity addWorkObjectParty
PartyRole parameter Facility coordinator
PartyClass parameter Data-Party-Operator
PartyModel parameter CurrentOperator
The completed Run activity settings are shown in the following image.
Update Weather case type routing
1. In the Forecast Weather process of the Forecasting stage, open the Get Weather Forecast assignment
properties panel and verify that it is configured as followed.
Field Setting
Route to Custom
Skill Weather
2. In the Prepare for Weather process of the Preparing stage, open the Prepare for Precipitation assignment
properties panel and check that it is configured as follows.
Field Setting
Route to Custom
Skill Weather
3. In the Prepare for Weather process of the Preparing stage, open the Review Preparations assignment
properties panel and verify that it is configured as follows.
Field Setting
Custom Custom
Router ToWorkParty
Party FacilityCoordinator
Enable attribute based access control (ABAC) security

You will use ABAC to configure your authorization scheme. To enable ABAC, you must update a Dynamic System
Setting (DASS) as follows:
1. Open the Records Explorer.
2. Expand the SysAdmin category.
3. Select Dynamic System Settings record types.
4. Find and select the EnableAttributeBasedSecurity Setting Purpose.
5. In the Settings tab, set the value to true.
6. Save the updated EnableAttributeBasedSecurity DASS.
7. Log off and log back on as Admin@Booking.
Restrict access to financial information using ABAC

To restrict access to the financial information as described in the scenario, you will:
1. Create SalesExecutive and ExecutiveOfficer access when records to test if an operator belongs to the sales
executives or executive officers access group.
2. Create a SalesAndExecutives access control policy condition that references your new access when records.
3. Create a RestrictFinancialInformation read properties access control policy that references your new access
control policy condition. Users defined in the SalesAndExecutives access control policy condition can view the
.Event.DisBasePriceWOption .Event.DisCarParkPrice , and .Event.Discount properties.
Create Sales Executive and ExecutiveOfficer access when records

1. In the Records Explorer, expand the Security category.
2. Select Access When record type.
3. Click Create.
4. In the new record form, enter the following.
Field Setting
Label Sales Executive
Apply to FSG-Booking-Work-Event
Add to ruleset EventBooking
5. Click Create and open to create the new access when record.
6. On the Conditions tab, enter the following When... expression
OperatorID.pyAccessGroup = "Booking:Sales".
The completed Conditions tab looks like the following image.
7. Save the new (FSG-Booking-Work-Event) SalesExecutive access when record.

8. Repeat steps 1.a. through 1.c.
Field Setting
Label Executive Officer
10. Click Create and open to create the new access when record.
11. On the Conditions tab, enter the following When... expression:
OperatorID.pyAccessGroup = "Booking:Executives"
12. Save the new (FSG-Booking-Work-Event) ExecutiveOfficer access when record.
Note: You should also create an BookingAdministrator access when record with OperatorID.pyAccessGroup =
"Booking:Administrators" expression so you can continue editing and viewing the restricted properties as
Admin@Booking.
Create an SalesAndExecutives access control policy condition

2. Expand the Security category.
3. Select Access Control Policy Condition record types.
4. Click Create.
5. In the new record form, enter the following :
Field Setting
Label Sales And Executives
6. Click Create and open to create the new SalesAndExecutives access control policy condition.
7. In the access control policy condition Definition tab, in the Conditional Logic section, add the
ExecutiveOfficer and SalesExecutive access when records you created.
8. Although not required, in the Policy Conditions section, specify a condition that always returns false to
ensure that access is only provided if one of the access when rules evaluates to true.
The completed Definition tab looks like the following image.
9. Save the new (FSG-Booking-Work-Event) SalesAndExecutives access control policy condition record.
Note: You should also add a BookingAdministrator access when condition so you can continue editing and
viewing the restricted properties as Admin@Booking.
Create a RestrictFinancialInformation access control policy

3. Select Access Control Policy record types.
4. Click Create.
Field Setting
Label Restrict Financial Information
Action PropertyRead
6. Click Create and open to create the new RestrictFinancialInformation access control policy.
7. In the access control policy Definition tab, in the Permit access if field, enter the SalesAndExecutives policy
control policy condition you created.
8. Add the .Event.DisBasePriceWOptions, .Event.DisCarParkPrice, and .Event.Discount properties. For all of the
properties, use Mask with N digits as the Restriction Method.
9. Save the new (FSG-Booking-Work-Event) RestrictFinancialInformation access control policy record.
Restrict access to Event Booking cases using ABAC

To restrict access to the Event Booking cases as described in the scenario you will:
l Create the EventManager access when record to test whether an operator is in the event manager access
group.
l Create the TeamLeadEventManager access when record to test whether an operator is in the Event Manager
access group and has a Team Lead skill.
l Configure the properties used in the access control policy condition so that the properties can be used in
search and in reports.
l Create a HasEventReadAccess access control policy condition that references your new access when conditions
and includes policy conditions and access permissions.
l Create a RestrictEventAccess access control policy that references your new access control policy condition.
Create EventManager and TeamLeadEventManager access when records
1. Create the EventManager access when record to test whether an operator belongs to the EventManagers
access group. Do the following:
a. From the Records Explorer, expand the Security category.
b. Select Access When record types.
c. Click Create.
d. In the new rule form, enter the following settings.
Field Setting
Label Event Manager
e. Click Create and open to create the EventManager access when record.
f. In the Conditions tab, enter the following When... expression:
OperatorID.pyAccessGroup = "Booking:EventManagers".
g. Save the new EventManager access when record.

2. Create the TeamLeadEventManager access when record to test whether an operator belongs to the Event
Managers access group and has the TeamLead skill. Do the following:
a. Repeat steps 1.a. through 1.c.
b. In the new rule form, enter the following settings.
Field Setting
Label Team Lead Event Manager
c. Click Create and open to create the TeamleadEventManager access when record.
d. In the Conditions tab, use the following When... expression:
OperatorID.pyAccessGroup = "Booking:EventManagers" AND OperatorID.pySkills(1).pySkillName =
"TeamLead".
e. Save the new TeamLeadEventManager access when record.
Configure the access control policy condition properties

Before you can configure the new HasEventReadAccess access control policy condition, you must do the following;
l Expose the .Event.NumAttendees property at the event booking case level as a new .NumberOfAttendees
property and create a related declare expression so the property can be filtered for search.
l Optimize the .EventManager and .NumberOfAttendees properties for reporting.
Make NumberOfAttendees a filterable search property

1. In the App Explorer, create a new NumberOfAttendees property applied to the FSG-Booking-Work-Event class in
the EventBooking ruleset. Specify Integer as property type.
2. In the App Explorer, right click the new NumberofAttendees property and select Define expression to create a
new .NumberOfAttendees declare expression in the EventBooking ruleset.
3. In the declare expression Expressions tab, set Set Number of Attendees to the Value
of.Event.NumAttendees.
4. On the Change Tracking tab, set Execute this expression to Regardless of any pages it is contained in.
5. Save the .NumberOfAttendees declare expression.
6. In the Designer Studio header, select Create > SysAdmin > Custom Search Properties.
7. Enter FSG-Booking-Work-Event in the Class Name field and then click Create and open.
8. In the record header, set the Associated RuleSet to EventBooking.
9. In the custom search properties record Definition tab, select the FSG-Booking-Work-Event property and then
click the gear icon to open the Property Configurations dialog.
10. In the Property Configurations dialog, select the NumberOfAttendees property and then click Submit to save
your updates and close the dialog.
11. Expand FSG-Booking-Work-Event and select the Include in search results check box.
The completed Definition tab on the custom search properties record looks like the following image.
12. Save the FSG-Booking-Work-Event • pySearch custom search properties record.
Optimize the EventManager and NumberOfAttendee properties

In the App Explorer, right-click the following properties and select Optimize for reporting.
l (FSG-Booking-Work-Event) EventManager
l (FSG-Booking-Work-Event) NumberOfAttendees
Configure the HasEventReadAccess access control policy condition

1. In the Records Explorer, expand the Security category.
2. Select Access Control Policy Condition record types.
3. Click Create.
4. In the new rule form, enter the following.
Field Setting
Label Has Event Read Access
5. Click Create and open to create the HasEventReadAccess access control policy condition.
6. On the Pages & Classes tab, add Page name OperatorID using Class Data-Admin-Operator-ID.
7. On the Definition tab, do the following:
a. in the Conditional Logic section, add the TeamLeadEventManager, EventManager, and SalesExecutive access
when records you created as conditions.
b. In the Policy Conditions section, specify the following conditions. Condition D always returns true to
ensure that access is not prevented if none of the access when rules evaluates to true.
Condition Column source Relationship Value

A .NumberOfAttendees is less than 10000
B .pxCreateOperator Is equal OperatorID.pyUserIdentifier
C .EventManager Is equal OperatorID.pyUserIdentifier
D .pxCreateOperator Is not null
The completed Definition tab on the access control policy condition record looks like the following image.
8. Save the HasEventReadAccess access control policy condition.
Create the RestrictEventAccess access control policy

In the Event Booking case type, create an access control policy for Read to restrict access to the Event Booking
cases.
3. Select Access Control Policy record types.
4. Click Create.
5. In the new rule form, enter the following settings.
Field Setting
Label Restrict Event Access
Action Read
6. Click Create and open to open the new RestrictEventAccess access control policy.
7. In the Permit access if field, enter the HasEventReadAccess access control policy condition you created.
The completed Read • RestrictEventAccess access control policy is shown in the following image.
8. Save the RestrictEventAccess access control policy.
Restrict access to facility cases

You can restrict opening Facility cases using role based access control. To do so, open the Facility case type and
use the Access Manager to configure No Access for Perform.
Validate your work

1. Log off as Admin@Booking.
2. Log on as Author@Booking, and create a new Event Booking Case. Notice the Discount, Discounted Base
Price with Optional Services, and Discounted Additional Price per Parked Car fields are all masked and
are read-only. Log off.
3. Log on as SalesExecutive1@Booking, and create a new Event Booking Case. Notice the Discount, Discounted
Base Price with Optional Services, and Discounted Additional Price per Parked Car fields are not
masked and are editable.
4. Create two Event Booking cases one with under 10,000 attendees and another with more then 10,000
attendees. Do not complete the Log Customer Response step in either case. Log off.
5. Log on as SalesExecutive2@Booking, and switch to the Case Manager portal and do the following:
a. On the Dashboard select Sales Executive 1 in the Team members section to view
SalesExecutive1@Booking's open cases.
b. Select Log Customer Response for the case with under 10,000 attendees. As a result, you should be able
to work on the case.
c. Select Log Customer Response for the case with more than 10,000 attendees. As a result, you should
receive an error message to the effect that, "Access Control Policy denied access for class FSG-Booking-
Work-Event and action Open."
d. Log out.
6. Log on as EventManager2@Booking. Switch to the Case Manager portal and do the following:
a. On the Dashboard select Event Manager 1 in the Team members section to view
EventManager1@Booking's open cases.
b. Select Get Approval for any case listed. As a result, you should receive an error message to the effect that,
"Access Control Policy denied access for class FSG-Booking-Work-Event and action Open."
c. Log out.
7. Log on as EventManager1@Booking. Switch to the Case Manager portal and do the following.
a. On the Dashboard select Event Manager 2 in the Team members section to view
EventManager2@Booking's open cases.
b. Select Get Approval for any case listed. As a result, you should be able to work on the selected case.
The following alternative approaches are presented. They do not have to be developed. The detailed instructions
provided are a guide in case you would like to experiment using role-based access control (RBAC) to restrict
access to Event Booking cases or restrict access to Facilities assignments using ABAC.
Restrict access to financial information

There are no alternative approaches for restricting access to the financial information.
Restrict access to events cases using RBAC
Create a role for events and add it to appropriate access groups. Use the Access Manager to create an Access of
Role to Object record with an access when record defining the restrictions.
Restrict access to Event Booking cases: Comparing RBAC and ABAC

Design Pros Cons

Attribute based access control Easy to configure Not shown in Access Manager
Role based access control Shown in Access Manager Requires an additional role
Restrict access to Facilities assignments using ABAC (optional)
1. For the Assign-Worklist class, create an access when condition named FacilityCoordinator in the EventBooking
ruleset.
2. In the Conditions tab, use the following When... expression:
OperatorID.pyAccessGroup = "Booking:Facilities"
The Conditions tab should look like the following image.
3. For the Assign-Worklist class, create a new FacilityCaseAssignedToMe access control policy condition in the
EventBooking ruleset.
4. In the Pages & Classes tab on the access control policy condition record, enter OperatorID in the Page name
field and enter Data-Admin-Operator-ID in the Class field.
5. In the Definition tab, check if the user is a facility coordinator, and check if the case is assigned to that user.
For all others, grant access.
The Definition tab configuration is shown in the following image.
6. For the Assign-Worklist class, create a RestrictFacilityCases access control policy in the EventBooking ruleset. Set
the Action to Read to restrict other facility coordinators from opening the assignment and performing work.
7. In the Permit access if field, enter the FacilityCaseAssignedToMe access control policy condition you created.
The access control policy should look like the following image.
Restrict access to Facilities assignments: comparing RBAC and ABAC
Design Pros Cons

Attribute based access Easy to configure Not shown in Access Manager
control
Role based access control Shown in Access Requires an additional role
Manager
Solution RAP file

You can import the solution RAP file for this exercise to view the completed solution. The Read •
RestrictFacilityCases access control policy, described in the lesson as optional, is implemented in the solution. The
record availability is set to Blocked so you can experiment with the record.
The solution file does not contain a complete implementation of all the authorization requirements specified in
the Front Stage Scenario Requirements. As a challenge exercise, you can implement all the requirements using a
combination of RBAC and ABAC.
Exercise: Identifying and mitigating security risks

Scenario
Front Stage's Booking application is going live in the near future. Prior to promoting the application to
production, a security review is required. Any security risks found require a review.
Your assignment
Perform a security review of Front Stage's Booking application using the security checklist. Provide
recommendations to strengthen the security of the application.
Some changes can be implemented directly in the development environment, while others are configured when
the application has been promoted to the production environment. Create a list of configuration tasks that need
to be carried out when the application has been promoted to other environments for changes that cannot be
implemented in the develop environment.
Solution detail
Tasks to perform on the development environment include:
1. Disabling unneeded out-of-the-box operators
2. Changing passwords for used out-of-the-box operators used
3. Fixing any issues found by the security analyzer
4. Fixing any security issues in the Guardrail report
5. Ensuring that timeouts are set up at the application server level, requestor level, and Access Group level that
are of an appropriate length
6. Ensuring that the Unauthenticated Access Group has the minimum required access to rules
7. Adding the <env name="alerts/suppressalerts" value="true" /> setting to the prconfig.xml file to ensure that
sensitive property values, such as customer account numbers or Social Security numbers, do not appear in
the Alert log
8. In each ruleset version, selecting Lock this Version on the Security tab, and entering a password
9. In each ruleset rule, selecting Use checkout? on the Security tab, and entering three distinct passwords to
limit the ability to add versions, update versions, and update the ruleset rule itself
10. Applying the correct type for all properties
11. Applying privileges across all the relevant rules (flow actions, reports, flows)
12. Reviewing the Unauthenticated access group to make sure that it has the minimum required access to rules
Tasks to perform outside of the development environment:

1. Updating prconfig settings
2. Updating dynamic system settings
3. Removing any unnecessary resources/servlets from the web.xml, and renaming default servlets where
applicable, particularly PRServlet
4. If using https, ensuring that testing environments are available to test with SSL enabled
5. Ensuring that the system has been set up using a JDBC connection pool approach through the application
server, rather than the database being set up in the prconfig.xml
6. Renaming and deploying the prhelp.war once per environment (potentially on its own node to avoid being
able to pick up the endpoint URL from the pop-up window)
7. Renaming and deploying the prsysmgmt.war once per environment (potentially on its own node to avoid
being able to pick up the endpoint URL from the pop-up window)
8. Renaming and redeploying the prweb.war for each node
9. Renaming and securing the context root for prgateway.war
Exercise: Analyzing Security Event Logs
Scenario
Front Stage is concerned whether someone’s user name and password may have been comprised, perhaps
through a phishing attack. FSG has decided to enforce the restriction that everyone who accesses the Booking
application must enable geolocation. If not enabled, access to the Booking application would not be granted.
FSG wants to write out each user’s pxRequestor pxLatitude and pxLongitude when logging custom security
events. FSG also wants to record the timestamp for each event in a way that simplifies computation of velocity,
whether miles-per-hour (mph) or kilometers-per-hour (kph). If the speed at which the same user would have to
travel to have logged two security events exceeds the realm of possibility, FSG wants to know who that user is
and where the two events occurred.
Your assignment
It is not necessary to implement denial of access to the Booking application if geolocation is not enabled. Instead
devise a method to efficiently compute the velocity between two events recorded in a PegaRULES-
SecurityEvent.log file for the same user. If the velocity exceeds a reasonable value, output the two events.
Solution detail
The solution to this exercise requires the installation of Apache Spark and Rumble.
l The instructions to install Rumble can be found here: Installing Spark
l Apache Spark can be downloaded from here: Download Apache Spark
l Rumble itself, i.e., spark-rumble-1.0.jar, can be downloaded from here: Rumble
Installing Apache Spark and Rumble:

For simplicity download Apache Spark using a browser running inside the VM. Per instructions, move the
downloaded file to /usr/local/bin by executing a command like:
tar zxvf spark-2.4.4-bin-hadoop2.7.tgz
sudo mv spark-2.4.4-bin-hadoop2.7 /usr/local/bin
Add Apache Spark you PATH environment variable by executing:

export SPARK_HOME=/usr/local/bin/spark-2.4.4-bin-hadoop2.7
export PATH=$SPARK_HOME/bin:$PATH
To verify that you performed the steps above correctly execute:

cd $SPARK_HOME/bin
spark-submit –version
cd $HOME
spark-submit –version
Next, using a browser running inside the VM, download Rumble from here: Rumble
Create a directory from where Rumble would be executed, for example $HOME/pega8/rumble
Move the downloaded spark-rumble-1.0.jar into the directory you created in the previous step.
Define Rule-Obj-Functions in Library named “Security”
Security • LogCustomEventValueGroup() Void

l Parameters: eventType String, outcome String, message String, customFlds ClipboardProperty
l Description: customFlds must be a Text ValueGroup. Call this Function when wanting to log a custom Security
Event
Security • NumericTimestamp() String

l Parameters: unit String, allowed values = "h", "m", "s"
l Description: Returns the current timestamp in units of hours, minutes, or seconds as a String
Override FSG-Booking-Work OpenDefaults Extension Point
Enable Geo-Location and Custom Security Events logging

The Chrome browser will not support Geolocation requests unless the server is secured.
See: Geolocation API Removed from Unsecured Origins in Chrome 50 | Web | Google Developers.
Chrome will allow Geolocation requests within a Linux VM if its IP address is mapped to the name “localhost”.
Example:
pega8@Lubuntu1:~$ more /etc/hosts
192.168.118.145 localhost
127.0.0.1 localhost
127.0.1.1 Lubuntu1
As shown, enter the “ifconfig” IP address as the first entry for localhost. Test by executing “ping localhost”.
The When rule, pyGeolocationTrackingIsEnabled, must return “true”.
The When rule applied to Data-Portal will cause the popup window below to appear after logging in.
Click “Allow Location Access”. Afterward check for pxLatitiude and pxLongitude being set within the pxRequestor
page on your Clipboard.
For best results, use Firefox as your browser.
Launch the Security Event Configuration landing page using Security -> Tools -> Security -> Security Event
Configuration.
At the bottom of the landing page enable Custom Events, then click Submit.
After open an Event case for review, check pyWorkPage on the Clipboard or Trace OpenDefaults.
You should see the values for the customFlds Text Value Group displayed per example below.
Launch System > Operations > Logs. Click on Log Files, next click the Text link to the right of SECURITYEVENT.
If challenged use user id: admin, password: admin, then open the SecurityEvent.log file to see whether the
customFlds values have been recorded.
Remove Quotes Around Numeric Values (necessary for JSON format)

Below is the syntax needed to remove quotes around numeric values (click here for source).
1. Copy/paste the text you want the regular expression to examine
2. Replace each numeric value with (-?[0-9]*\.[0-9]*) if value can be negative, or ([0-9]*\.[0-9]*) if the
value cannot be negative
3. Use \1, \2, etc., to specify which parsed value goes where
Note: A slash does not need to separate the find clause from the replace clause. Whatever character appears
after initial "s" becomes statement's delimiter. The statement must end with that delimiter as well as be used in
the middle of the statement when separating find from replace
BEFORE text.txt
{"id":"25538d8d-2861-40a9-b6df-d289e4b73a7e","eventCategory":"Custom
event","eventType":"FooBla","appName":"Booking","tenantID":"shared","ipAddress":"12
7.0.0.1","timeStamp":"Mon 2019 Aug 05,
19:31:42:060","operatorID":"Admin@Booking","nodeID":"ff9ef7835fd4906aea82694c981938
d0","outcome":"Fail","message":"FooBla
failed","requestorIdentity":"20190805T192510","lon":"-
98.0315889","lat":"30.123275"}
cat text.txt | sed -r 's/"lon":"(-?[0-9]*\.[0-9]*)","lat":"(-?[0-9]*\.[0-9]*)"}

/"lon":\1,"lat":\2}/'
AFTER text.txt
{"id":"25538d8d-2861-40a9-b6df-d289e4b73a7e","eventCategory":"Custom
event","eventType":"FooBla","appName":"Booking","tenantID":"shared","ipAddress":"12
7.0.0.1","timeStamp":"Mon 2019 Aug 05,
19:31:42:060","operatorID":"Admin@Booking","nodeID":"ff9ef7835fd4906aea82694c981938
d0","outcome":"Fail","message":"FooBla
failed","requestorIdentity":"20190805T192510","lon":-98.0315889,"lat":30.123275}
Replace newlines within an entire file, not one line at a time

If new lines exist in a file read by a Unix script, normally each line would be processed individually. If is needed
is a way to treat the entire file as a single large String, then replace the new lines within that String (click here for
source).
The output of the newline-removing sed command is piped to sed again, this time to replace: }<space>{ with: }
<comma>{
sed -e ':a' -e 'N' -e '$!ba' -e 's/\n/ /g' PegaRULES-SecurityEvent.log | sed 's/}
{/},{/g'
Have one file be the start of the query including the JSON array left bracket: let $log := [
Have a second file that contains the end of the JSONiq query starting at the JSON array's right bracket.
1. The script would cat the first file to a new query file using > query_file
2. Then output the back-to-back sed commands using >> query_file
3. Then cat the second file using >> query_file
JSONLogToArray.sh
#!/usr/bin/env bash
set -x
echo "let \$log := [" > test2.jq
cat PegaRULES-SecurityEvent.log
| sed -r 's/"lon":"(-?[0-9]*\.[0-9]*)"/"lon":\1/' \
| sed -r 's/"lat":"(-?[0-9]*\.[0-9]*)"/"lat":\1/' \
| sed -r 's/"ts":"([0-9]*\.[0-9]*)"/"ts":\1/' \
| sed -e ':a' -e 'N' -e '$!ba' -e 's/\n/ /g' \ | sed 's/} {/},{/g' >> test2.jq
cat restof_test1.jq >> test2.jq
Next is the remainder of the JSONiq query (restof_test1.jq). The distance between two coordinates is computed in
miles (3958.8 is the radius of the earth in miles) then divided by the time difference between to the two log file
entries, the timestamp is computed as hours since 1-1-1970 GMT.
The filter condition ensures pairs of rows are only examined when:
1. The eventType is “Open Work” (see FSG-Booking-Work OpenDefaults override above)
2. The operatorID values within the two records are identical
3. The latitudes in both rows are > 20 (this is used to ensure that both rows contain geolocation coordinates. Any
comparison would suffice)
4. The timestamp in the second row is in the future of the timestamp in the first row (this avoids redundant
calculation where the velocity would end up negative)
restof_test1.jq
let $pi := 3.1415926
let $join :=
for $i in $log[], $j in $log[]
where $i.eventType = "Open Work"
and $i."id" != $j."id"
and $i."operatorID" = $j."operatorID"
and $i.lat>20 and $j.lat>20
and $j.ts>$i.ts
let $lat1 := $i.lat
let $lon1 := $i.lon
let $lat2 := $j.lat
let $lon2 := $j.lon
let $dlat := ($lat2 - $lat1) * $pi div 180
let $dlon := ($lon2 - $lon1) * $pi div 180
let $rlat1 := $lat1 * $pi div 180
let $rlat2 := $lat2 * $pi div 180
let $a := sin($dlat div 2) * sin($dlat div 2) + sin($dlon div 2) * sin($dlon div 2)
* cos($rlat1) * cos($rlat2)
let $c := 2 * atan2(sqrt($a), sqrt(1-$a))
let $distance := $c * 3958.8
let $tdiff := $j.ts - $i.ts
let $mph := $distance div $tdiff
return { "id" : $j.id, "eventType" : $j.eventType, "distance":$distance,
"mph":$mph}
return [$join]
Send the JSONiq query to Apache Spark as opposed to executing commands using shell
mode
Ideally there would be an easier way to send the the queryfile content to Apache Spark + Rumble than doing:
open file, select all, copy, paste into Rumble's command line (click here for source).
Instead of: --shell yes
use: --query-path file.jq --output-path results.out
In a directory where the rumble jar exists on a system where apache spark has been installed, execute:
pega8@Lubuntu1:~/rumble$ spark-submit --master local[*] --deploy-mode client spark-

rumble-1.0.jar --query-path "test2.jq" --output-path "test2.out"
Example test2.out
[ { "id" : "f5b07887-11ef-4f6f-9f0f-efb060bd3cd7", "eventType" : "Open Work",
"distance" : 31.6128421996284034764, "mph" : 2634.4035166357 }
The example test2.out can be interpreted as:

Two Security Events were recorded in close succession. To traverse the separation distance of 31.6 miles within
the time would require someone to have traveled at 2634 miles per hour.
Exercise: Defining a reporting strategy

Scenario
Front Stage has been experiencing issues tracking the equipment used to prepare for outdoor events.
Equipment that is not recovered such as umbrellas and seat covers affects the profit FSG makes on each event.
Over the past 18 months FSG has instituted bar codes on its equipment. When an event attendee is given an
umbrella, for example, that umbrella’s bar code is scanned as well as the bar code on the attendee’s wrist band.
Front Stage has been renting equipment for outdoor events from third parties. By using the equipment bar-
coding system's historical data, FSG is considering whether it could achieve greater profit if were to purchase
and house its own equipment.
After every event hosted by FSG, the bar-coding system’s data has been captured. FSG now wants that data
imported to their system to facilitate business intelligence. FSG does not want this analysis to affect its Booking
application’s web tier users.
FSG does have an existing Data Warehouse where reports can be created. That Data Warehouse lacks the ability
to be receive data from the bar-coding system. Fortunately, FSG has been able to devise a way to accept the data
using Pega.
Your assignment
Provide a recommendation how best to handle the imported information to allow FSG business personal access
to reports with minimal impact to the Booking application’s web tier users. Identify viable approaches to meet
the requirement and provide a recommended approach.
Solution detail
Data types can be defined in Pega that correspond to the information collected by the bar-coding system.
Instances of those data types can be persisted in an external database as opposed to the PegaDATA schema
include in the Pega database repository.
If reporting was performed using the PegaDATA schema, numerous rows from that schema would need to be
accessed to aggregate the data. Even if the database was tuned for quick retrieval of the data, putting large
amounts of data on the clipboard could impact JVM performance, thereby affecting web tier user who share the
same PegaRULES database.
The best option is to leverage BIX to publish data from the external database to theFSG data warehouse. The BIX
extract process would run on a dedicated type=BIX node to ensure no adverse impact to type=WebTier nodes.
The diagram below shows how the data is moved from the external database to the Front Stage data warehouse.
A link to reports created in that Data Warehouse can be added to the Dashboards viewed by FSG executives.
You could load the data into Pega and create reports. But, you know that retrieving several thousand rows and
aggregating the results over time could have a heavy performance cost.
Exercise: Optimizing properties for report

performance
Scenario
Front Stage wants to determine if they should outsource parking services to an external vendor. Jake Schofield,
the Senior Vice President of Operations, asks you to develop a report to track parking data for every event during
the last six months. The number of events can be large, especially during the summer months. Parking fees are a
big source of revenue for Front Stage. Depending on the size of the event, Front Stage supplies up to 50 parking
attendants for the event. These resources may be better allocated elsewhere in the organization.
Jake wants to have this information available as a line chart when he opens the Event Booking application each
morning. You assign the task of creating this report to Joe, a system architect on your team. You want to make
sure the parking report is not only accurate, but performs well so Jake can access the data he needs to make an
informed business decision. You review Joe's work when he completes the report.

Your assignment
Review the configuration of the Parking History report. Using a production sized data set, ensure the report is
displayed significantly faster after optimization. Provide a long-term recommendation on how to implement
these type of reporting requirements.
Detailed steps
Import the Parking Report branch ruleset
1. In your exercise system, log on as Admin@Booking.
2. From the Related Contents panel in this lesson, download the Parking Reports branch ruleset file.
3. Import the branch ruleset file.
4. Add the branch ruleset to the Booking application.
5. Save the Booking application rule.
Reset report data access defaults

For the purpose of the exercise, the report settings for the application allow the application to return up to 5000
records. The branch ruleset includes this change.
1. In the App Explorer, select FSG-Booking-Work-Event > Reports > Report Definition > ParkingHistory to
open the ParkingHistory report definition.
2. On the ParkingHistory report definition, click the Data Access tab.
3. Scroll to the General data access settings section.
4. Click Restore defaults. This resets the default according to the report settings configuration.
5. Save the report definition.
6. Log off to update the settings.
Create Event Booking cases
1. Log in as Admin.Booking.
2. In the App Explorer, select Event > Technical > Activity > CreateEventBookings. The application displays
the CreateEventBookings activity.
3. In the record header, click Actions > Run. The parameters for the activity are displayed.
4. For the maxRecords parameter, enter 2000 in the Value field.
5. Run the activity again. This may take 1-2 minutes to complete. The application displays a green check mark
when complete.
6. In the App Explorer, click the Event class. The application displays the newly created event cases.
Note: From the Related Contents panel in this lesson, download the Delete FSG cases .zip file. The file contains
SQL commands you can use to delete this data from your environment after you have completed this exercise.
Record performance of the Parking History report

1. From the App Explorer, open the ParkingHistory report.
2. At the bottom of Designer Studio, click the Performance icon. The application opens the Performance tool in
a new window.
3. In the Performance tool, click Reset. The application sets all readings to zero.
4. Return to the ParkingHistory report.
5. Click Actions > Run to display report results.
6. Return to the Performance tool.
7. Click the Add Reading.
A DELTA row is displayed. Note the RDB I/O Elapsed time.
Improve Parking History report performance

1. Review the ParkingHistory report definition configuration. Note the report contains two unjustified warnings.
2. Identify possible improvements to the report, such as optimizing columns included in the report.
3. Check out the ParkingHistory report to your local ruleset.
4. Implement improvements to this report.
5. Rerun the Performance tool to determine if the report is running more efficiently after making the
improvements.
Tip: Optimizing columns changes the database schema of the application. You can create a snapshot of your
local virtual machine to compare the performance to compare the performance before and after optimizing
columns.
Solution considerations
The computing resources needed to render the chart report can also be costly. Watch for browser interaction
alerts during your testing. Removing the chart can also result in performance improvement.
If FSG expects the record set to be greater than 500 records, your long-term recommendation may include
exporting parking data to an external warehouse and linking to that report instead of embedding the chart in the
user's portal.
Verify your work

Optimizing columns should result in significantly smaller RDB I/O Elapsed readings.
Exercise: Using a database index for report
performance
Scenario
Front Stage wants to investigate the impact of expanding its address search capability to include filtering on
street addresses that start with a certain number. They are aware of a source of actual address information that
they can use: OpenAddress . Front Stage is concerned that, over time as the Address table grows larger, and with
greater use of address search, query performance could impact their ability to efficiently process cases.

pgAdmin4 pega pega
Your assignment
You will analyze the possible performance impact of expanding the address search capability to include filtering
on street addresses. To do this you will first need to insert a large amount of test data into the FSG-Data-Address
table, pegadata.pr_fsg_data_address. Then you will test a street filter condition to be used with the Haversine
formula. To do this you do not need to modify the HaversineFormula Connect-SQL rule. Instead you will execute
the modified query from PostSQL pdAdmin4 tool. In order to analyze the query, you will prefix the query using
EXPLAIN (ANALYZE true, COSTS true, FORMAT json). You will first execute the query and note the
result. Then, you will add a database index to the street column. Then execute the query again and compare the
result from your first run.
Detailed steps
Install and run pgAdmin4 within the VM
Note: Skip this section if using the Linux Lite VM (LLVM). On the LLVM note that pgAdmin4 is installed in the
/opt/PostgreSQL/9.6/pgAdmin 4/bin folder.
If a pgAdmin4 docker container does not already exist, execute the script named pull_and_run_pgAdmin4.sh.
The pgAdmin4 docker image should exist. This explains why the script is commented out. You only want to
execute the “run” command once. If pgAdmin4 does not appear when executing “sudo docker ps”, set 2 to 1
before executing the script. Afterward set the if statement back to “1 -eq 2”.
set -x
# sudo docker pull dpage/pgadmin4
if [ 1 -eq 2 ]
then
sudo docker run --name pgAdmin4 -p 80:80 \
-e "PGADMIN_DEFAULT_EMAIL=pega" \
-e "PGADMIN_DEFAULT_PASSWORD=pega" \
-d dpage/pgadmin4
fi
sudo docker stop pgAdmin4
sudo docker start pgAdmin4
Use the email user id: pega and password: pega to log into pgAdmin4 using a browser. The URL to use is: {VM_
ip_address}/browser. From a browser within the VM console you can use localhost/browser as the URL.
After logging into pgAdmin4 create a server giving it any name you prefer. In the Connection tab of the server
you must use {VM_ip_address} for the host. Specify the port number exposed by the postgres docker
container to which you want to connect, for example, 32770. User name and password, again, should be “pega”.
Download and convert address data

Note: 11b_openaddr-collected-us_northeast.zip is provided with this exercise. You may not need to download
any file. Instead transfer the zip file to the $HOME/Downloads directory then remove 11b_ from the beginning
of the file name.
Using a browser within the VM console go to http://results.openaddresses.io/. Download one or more address
CSV files, for example us_northeast.zip. The files will be downloaded to the $HOME/Downloads directory.
Change to that directory and unzip each file.
cd $HOME/Downloads
unzip openaddr-collected-us_northeast.zip
Note: You can also unzip files using the File Manager.
Note: Skip the next copy step below if using the LLVM. The following copy step is applicable to the Lubuntu VM
only
Change directory to where each address zip file is located that you want to load to a shared volumes directory.
Copy that CSV file to the shared volumes directory.
Note: You can also copy files using the File Manager.
Optionally you can copy statewide.csv to /tmp which is also specified as a docker volume.
cd $HOME/Downloads/openaddr-collected-us_northeast/ma
cp statewide.csv $HOME/docker/volumes/postgres
cd $HOME/docker/volumes/postgres
To see the details on the files switch to the folder containing the files and use the list command.
cd $HOME/Downloads/openaddr-collected-us_northeast/ma
ls -l statewide.csv
cat statewide.csv | wc -l
The “word count” command, wc, shows there are 3,600,458 lines, the first being the header.
cat statewide.csv | head -1

LON, LAT, NUMBER, STREET, UNIT, CITY, DISTRICT, REGION, POSTCODE, ID, HASH
The NUMBER and STREET columns need to be concatenated. UNIT, DISTRICT, and HASH can be ignored, or if you
want, UNIT can be appended to STREET. Save the bash script below to a file named READ.sh then execute it,
saving the output to a new file name.
#!/bin/bash
INPUT=statewide.csv
OLDIFS=$IFS
IFS=,
[ ! -f $INPUT ] && { echo "$INPUT file not found"; exit 99; }
while read LON LAT NUMBER STREET UNIT CITY DISTRICT REGION POSTCODE ID HASH
do
echo "$ID,$NUMBER $STREET,$CITY,$REGION,$POSTCODE,$LAT,$LON"
done < $INPUT
IFS=$OLDIFS
bash ./READ.sh > ma_statewide.csv
It is not necessary but good practice to add a header to the file listing the column names in the Address table to
populate. You can do this using the File Manager. The header record should be: ID,NUMBER
STREET,CITY,REGION,POSTCODE,LAT,LON.
Load CSV address data into the PostgreSQL database

One of the fastest way to import CSV data into the database is to use the psql COPY command. Do not attempt to
load this amount of data using Pega’s Data Type import capability.
Note: Ignore the following exec -tistep below if using the LLVM. The following exec -ti step is applicable to
the Lubuntu VM only.
Because the Postgres database resides within a docker container, you need to access psql using exec -ti
command line arguments.
pega8@Lubuntu1:~/docker/volumes/postgres$ sudo docker exec -ti pega83db

psql -h localhost -U pega -d pega
psql (9.4.10)
Type "help" for help.
pega=#
Note: Had you wanted you could have used /bin/bash after pega82db, instead, followed by ls
/var/lib/postgresql/data to verify that the contents of that docker-internal directory are the same as
$HOME/docker/volumes/postgres outside the docker container.
Load the address data into the PostgresSQL database using the psql COPY command below. Here the column
names within the pr_fsg_data_address table are specified.
COPY
pegadata.pr_fsg_data_address
(pyGUID,Street,City,State,PostalCode,Latitude,Longitude)
FROM '/var/lib/postgresql/data/ma_statewide.csv' DELIMITER ',' CSV HEADER;
Within pgAdmin4, launch the Query Tool and execute select count(*) pegadata.pr_fsg_data_address
to verify that all the records loaded successfully.
Analyze and improve query performance

Instead of modifying the Haversine formula by adding a filter criterion such as AND street LIKE '1 ROGERS
STR%', it is enough to perform a simple query within pgAdmin4 against the address table such as the one
shown below.
EXPLAIN (ANALYZE true, COSTS true, FORMAT json)

SELECT pinguid AS pyGUID,
reference AS Reference,
isfor AS IsFor,
street AS Street,
city AS City,
state AS State,
postalcode AS PostalCode,
country AS Country,
latitude AS Latitude,
longitude AS Longitude
FROM pegadata.pr_fsg_data_address
WHERE street like '1 ROGERS STR%';
In the “Explain” tab hover over the icon. On the right you should see the statistics for the Sequential Scan that
was performed.
Next select Indexes beneath pr_fsg_data_address, right-click, and select Create. Provide an index name such as
idx_street or StreetIDX. In the Definition table select btree then add the street column to the index. Choose any
Operator class such as text_pattern_ops.
Execute the query again. This time you should see significantly faster performance due to an Index Scan being
used.
If you want, do the same for a modified version of the Haversine formula. The Explain graphic will be different.
EXPLAIN (ANALYZE true, COSTS true, FORMAT json)

SELECT pyGUID AS pyGUID,
Reference AS Reference,
IsFor AS IsFor,
Street AS Street,
City AS City,
State AS State,
PostalCode AS PostalCode,
Country AS Country,
Latitude AS Latitude,
Longitude AS Longitude,
Distance AS Distance
FROM (
SELECT z.pyguid AS pyGUID,
z.reference AS Reference,
z.isfor AS IsFor,
z.street AS Street,
z.city AS City,
z.state AS State,
z.postalcode AS PostalCode,
z.country AS Country,
z.latitude AS Latitude,
z.longitude AS Longitude,
p.radius,
p.distanceunit * DEGREES(ACOS(COS(RADIANS(p.latpoint)) * COS(RADIANS(z.latitude))
* COS(RADIANS(p.longpoint - z.longitude)) + SIN(RADIANS(p.latpoint)) * SIN(RADIANS
(z.latitude)))) AS Distance
FROM pegadata.pr_fsg_data_address AS z
JOIN (
SELECT 42.0 AS latpoint,
-71.0 AS longpoint,
30.0 AS radius,
69.0 AS distanceunit ) AS p ON 1 = 1 ) AS d
WHERE distance <= radius
AND street LIKE '1 ROGERS STR%'
ORDER BY distance
LIMIT 15
Note: Attempting to index the latitude and longitude columns will not improve performance since these are
numeric. pgAdmin4 does not support the definition of indexes for numeric columns, Forcing an index on a
numeric column using DDL syntax, for example, CREATE INDEX idx_lat ON pegadata.pr_fsg_data_
address(latitude), will not work; the index will be ignored.
Verify your work

Indexed columns should result in significantly improved performance readings.
Ex: Contact Hotels not contacted recently
Scenario
FSG wants to ensure that each hotel with which it has agreements to book rooms for events is treated as equally
as possible. FSG would like to identify hotels within 5 miles of an event within the last month that have not been
asked to reserve a block of rooms for an event. FSG plans to use this information to send an email to those hotels
making them aware the FSG will make it a priority to issue a room request at the earliest opportunity.

Admin admin@booking rules
Your assignment
Design a query that outputs hotel contact information according to the above requirements. Expose any
properties not currently exposed that are output by the report and/or must be exposed to perform joins.
Design approach
A brute force approach would identify every Event held within the past month then iterate the list of Events. For
each Event, capture the pyGUIDs of the hotels that were contacted. Next have the D_AddressesWithinDistance Data
Page search IsFor=HOTEL records with 5 miles of the Venue where the Event was held. The Reference values in
the D_AddressesWithinDistance result set would then be captured. Any Reference not in the list of FSG-Data-Hotel
pyGUIDs would be kept; any Reference that does match an FSG-Data-Hotel pyGUID would be ignored. Every
remaining Reference would be used to lookup an FSG-Data-Hotel record. Then capture contact information
(pyFirstName, pyLastName, and pyEmail1) from each Hotel record’s embedded Contact Field Group.
A problem with this iterative approach is that it is possible for multiple events to be held at the same Venue
within the past month. Also, two Venues may be within 10 miles of each other, meaning overlap could exist
within a 5 mile radius for each Venue. A Hotel may not have been contacted for one Event but could have been
contacted for a different Event at some point within the past month.
The D_AddressesWithinDistance data page sources an activity that calls a Connect-SQL rule that contains a query
based on the Haversine formula. The second table subselect, the one aliased as “p”, in the Haversine formula,
currently asks for a single location’s coordinates.
Alternatively a Table subselect could list the latitudes and longitudes of every Venue for every Event held in the
past month. Instead of joining to one row as it does now, the join would be made across multiple venue address
coordinates.
Current Definition of “p” Table Subselect

JOIN ( /* these are the query parameters */
SELECT {AddressPage.Latitude Decimal } AS latpoint,
{AddressPage.Longitude Decimal } AS longpoint,
{AddressPage.Distance Decimal } AS radius,
{AddressPage.pyNote Decimal } AS distanceunit,
{AddressPage.IsFor } AS isfor
) AS p ON p.isfor = z.isfor
Possible Definition of “p” Table Subselect

JOIN (
SELECT VenueAddress.latitude AS latpoint,
VenueAddress.longitude AS longpoint
FROM pegadata.pr_fsg_data_address AS VenueAddress
INNER JOIN pegadata.pc_fsg_booking_work AS BookEvent ON BookEvent.
{exposedVenueGUID}= VenueAddress.reference
AND BookEvent.pxobclass = 'FSG-Booking-Work-BookEvent
WHERE BookEvent.{exposedEventStartDt} {is within the past month}
) AS p ON 1 = 1'
Note: Radius, distanceunit, and isfor were removed since they can be defined elsewhere
The above modification to the Haversine Formula, however does not filter out addresses for Hotels that were
contacted during the past month. That needs to be done elsewhere in the query.
The solution requires that the expression below also be implemented
HotelAddressesNotContacted ::= AllAddressesWithinDistance EXCEPT

HotelAddressesContacted
In a future release of the Pega Platform, Connect-SQL rule queries may not allow tables that contain Pega-specific
columns, (columns that that start with px, py, or pz . The FSG-Data-Address table (pegadata.pc_fsg_data), is defined
in the CustomerData schema and has no pega specific columns and thus can be referenced in Connect-SQL rule
queries. However, the work pool table for the Booking application case types (pc_fsg_booking_work) should not be
queried using Connect-SQL rules since that table contains columns such as pzInsKey and pzPvStream.
In the long run the best approach is either (A) store the history of pyGUIDs for contacted hotels in the
CustomerData schema or (B) find a way to “insert” lists of pyGUIDs into a Connect-SQL query where each list of
pyGUIDs is obtained from the PegaData schema.
The challenge with approach (A) is that storing historical pyGUIDs and date-times in the CustomerData schema
requires extra work since it is the near equivalent of using atemporary table. A Savable Data Page could also
be used to reinsert data. Approach (A) adds complexity and potentially result in loss of data integrity since the
same information would be stored in multiple locations.
On the other hand, with approach (B), it is possible to insert SQL using syntax such as: {Asis: property-
name}. Below is a revised expression for HotelAddressesNotContacted.
HotelAddressesNotContacted ::= AllAddressesWithinDistance WHERE Reference NOT IN
({Asis:D_HotelsContacted.AsisExpression })
An example AsisExpression property value is shown below.
'5de1376c-aa4d-41dc-acd2-c5cd44eb3f61','d45d7130-471b-4138-87f2-
efb689983ee2','6584d826-06e6-4c47-b4ee-2a9c6cd62e7d','f7620988-c687-474f-8b3d-
27bb0371680e','6681b769-f2de-45cb-aa7a-e89526765f34','44eb05f1-9c16-48e7-b363-
7eaeb63e08e2'
The number of Hotel pyGUIDs should be small enough not to cause the entire SQL statement to exceed the
database’s maximum allowed length. As lengthy as the above example may appear due to the 32 hex character
length of a GUID, it would be difficult to exceed the maximum allowable SQL statement length. For example, the
maximum length of an SQL statement in PostgresSQL is now 2,147,483,648 characters or roughly 2GB.
A D_HotelsContacted data page that applies to FSG-Data_Address could be modeled after D_
AddressesWithinDistance. To do this the Connect_SQL_pr_fsg_data_address activity would first be copied to Connect_
SQL_HotelsNotContacted. Next a post-processing activity such as Post_Connect_SQL_HotelsNotContacted would be
created.
The Connect_SQL_HotelsNotContacted activity would first use a D_HotelsContacted data page that invokes a report
definition that obtains the list of GUIDs for hotels contacted within the past month. Afterward it would post-
process the pxResults() PageList to construct the value for a property named AsisExpression.
The solution for deriving AllAddressesWithinDistance (of an Event Venue) requires similar treatment. The goal is to
solve the right side of the expression below. Here we want to use “IN” as opposed to “NOT IN”.
AllAddressesWithinDistance :=
SELECT latitude AS latpoint,
longitude AS longpoint
WHERE Reference
IN ({D_VenuesUsed.AsIsExpression})
This AsIsExpression value would be the sequence of Venue Address pyGUID values associated to FSG Events held
in the past month. An example D_VenuesUsed.AsisExpression property value is shown below. D_
VenuesUsed.AsisExpression would be shorter than D_HotelsContacted.AsisExpression since multiple hotels can be
contacted per Event. See the example below.
'7e99dbc3-4e54-4419-a15f-f2ca1f0be265','b7206d9a-36d9-45c2-9849-
c5fcd995dadb','d8825749-e2fb-46b3-97aa-3ead12b89584'
Detailed Steps
Expose .VenueGUID within FSG-Booking-Work-BookEvent
1. In the Case Designer click on the Book Event case and open the Data Model tab
2. Add a .VenueGUID (Text) property
3. Within the App Explorer right click on .VenueGUID and choose “Define expression”
4. Set .VenueGUID = .Venue.pyGUID
5. Within the App Explorer right click on .VenueGUID and choose Optimize for reporting
Expose .Event.StartDT within FSG-Booking-Work-BookEvent
1. Within the App Explorer right click on .Event.StartDT and choose “Optimize for reporting
2. To verify, create a BookEvent case advancing it past the start date entry screen
3. Using pgAmin4, execute:
SELECT startdt_1,
pxcreatedatetime
FROM pegadata.pc_fsg_booking_work
WHERE startdt_1 is not null
AND pxobjclass = 'FSG-Booking-Work-BookEvent'
ORDER BY pxcreatedatetime desc
Create an Address report definition that JOINS BookEvent by .Reference =
.VenueGUID
1. See below:
Expose the HotelGUID property within FSG-Booking-Work-RoomsRequest

1. In the Case Designer click on the RoomRequest case and open the Data Model tab
2. Add a .HotelGUID (Text) property
3. Within the App Explorer right click on .HotelGUID and choose Define expression
4. Set .HotelGUID = .RoomsRequest.HotelGUID
5. Within the App Explorer right click on .HotelGUID and choose Optimize for reporting
6. To verify, create a BookEvent case, select Hotel Service, spin off at least one RoomsRequest subcase
7. Using pgAmin4, execute:
SELECT hotelguid,
pxcreatedatetime
FROM pegadata.pc_fsg_booking_work
WHERE hotelguid is not null
AND pxobjclass = 'FSG-Booking-Work-RoomsRequest’
ORDER BY pxcreatedatetime desc
Create an Address Report Definition that JOINS RoomsRequest by .Reference
= ROOMS.HotelGUID
1. Query tab exactly the same as in the VenueAddressLatLong report definition
2. However, the Data Access tab is different. .Reference = ROOMS.HotelGUID and ROOMS.pxCoverInsKey =
EVENT.pzInsKey
Define Data Pages that source the Hotel and Venue Address-querying Report
Definitions that also Transform the Response
The logic to define the two Report Definitions was discussed during solution design. In the table below the
Response Data Transform sets pyNote.
Data Page Report Definition Response Data Transform

D_HotelsContacted HotelAddressLatLong GenerateAsisExpressionFromAddressReference
D_VenuesUsed VenueAddressLatLong GenerateAsisExpressionFromAddressReference
Modify the HotelsNotContacted Connect-SQL rule to utilize the two Report

Definition-sourced Data Pages
l The final state of the HotelsNotContacted Connect-SQL rule is shown below.
l AddressPage.pyNote = (param.dist_unit = "km" ? "111.045" : "69.407")
SELECT
pyGUID AS pyGUID,
Reference AS Reference, IsFor AS IsFor, Street AS Street, City AS City, State
AS State, PostalCode AS PostalCode, Country AS Country, Latitude AS Latitude,
Longitude AS Longitude, Distance AS Distance
FROM (
SELECT z.pyguid AS pyGUID,
z.reference AS Reference,
z.isfor AS IsFor,
z.street AS Street,
z.city AS City,
z.state AS State,
z.postalcode AS PostalCode,
z.country AS Country,
z.latitude AS Latitude,
z.longitude AS Longitude, {AddressPage.pyNote Decimal }
* DEGREES(ACOS(COS(RADIANS(p.latpoint))
* COS(RADIANS(z.latitude))
* COS(RADIANS(p.longpoint - z.longitude))
+ SIN(RADIANS(p.latpoint))
* SIN(RADIANS(z.latitude)))) AS Distance
FROM {Class:FSG-Data-Address} AS z
JOIN (
SELECT latitude AS latpoint, longitude AS longpoint
WHERE reference IN ({Asis:D_VenuesUsed.pyNote}) ) AS p ON 1 = 1 ) AS d
WHERE distance <= {AddressPage.Distance Decimal }
AND reference NOT IN ({Asis:D_HotelsContacted.pyNote})
AND isfor = 'HOTEL'
ORDER BY distance
LIMIT 15
Verify your work

Proving the solution works requires at least two hotels within the specified radius from a venue, here 5 miles.
One of the hotels would be asked to provide rooms, the second hotel would not be asked to provide rooms. When
the query is run, the second hotel should be returned in the result set.
Locate the Code-Pega-List Connect_SQL_HotelsNotContacted Activity. Select Actions > Trace, then Actions > Run.
Enter 5 as the distance and mi as dist_unit.
SQL SELECT pyGUID AS pyGUID, Reference AS Reference, IsFor AS IsFor, Street AS Street, City AS City, State
AS State, PostalCode AS PostalCode, Country AS Country, Latitude AS Latitude, Longitude AS
Longitude, Distance AS Distance FROM ( SELECT z.pyguid AS pyGUID, z.reference AS
Reference, z.isfor AS IsFor, z.street AS Street, z.city AS City, z.state AS
State, z.postalcode AS PostalCode, z.country AS Country, z.latitude AS
Latitude, z.longitude AS Longitude, ? * DEGREES(ACOS(COS(RADIANS
(p.latpoint)) * COS(RADIANS(z.latitude)) * COS(RADIANS(p.longpoint -
z.longitude)) + SIN(RADIANS(p.latpoint)) * SIN(RADIANS(z.latitude)))) AS
Distance FROM pegadata.pr_FSG_Data_Address AS z JOIN ( SELECT latitude AS
latpoint, longitude AS longpoint FROM pegadata.pr_fsg_data_address WHERE
reference IN ('8d586ede-06ab-4e4c-93a8-6e5b353af790') ) AS p ON 1 = 1 ) AS
d WHERE distance <= ? AND reference NOT IN ('c3580ccf-2e8f-4b0e-a7bc-
d04819b47968') AND isfor = 'HOTEL' ORDER BY distance LIMIT 15
SQL <69.407> <5>
Inserts
The query returns the address for hotels that were not contacted. To identity the hotel and the hotel’s contact
would require the pyTempListPage.pxResults() PageList to be iterated.
For each page in D_Hotels, invoke the D_Hotel Lookup data page using “reference” as the pyGUID parameter
Exercise: Background processing
Scenario
Front Stage plans to become an international company with offices in multiple countries. The company wants to
send a Happy Equinox Day email to each customer shortly after 12:00 A.M. customer local time. When an equinox
occurs, daytime and nighttime are of the same duration all over the world. Equinoxes occur twice yearly
according to the following schedule.
Front Stage wants the emails to be processed as efficiently as possible to minimize the impact on normal
business hours processing.
Your assignment
When you begin, identify the following main challenges and document your approach.
l Calculating the time for sending the email.
l Sending the email according to the time calculation.
Although not part of this exercise, you can build out a complete solution by addressing these additional
challenges:
l Mapping a customer address to the appropriate time zone.
l Developing a way to retrieve and store the equinox dates.
l Orchestrating the relationships between the configured rules.
Solution detail
As you develop your implementation, rely on rules in Pega Platform. Also consider viable alternative approaches.
Compare the pros and cons of each alternative in order to build the best solution.
Note: From the Related Content section on this page, you can import the BackgroundProcEX solution file. The
solution contains a BackgroundProcEx case type that, when executed from a BROWSER Requestor, demonstrates
the calculations necessary to derive when midnight occurs in each timezone the day the equinox occurs.
Calculating the time for sending the email

First, determine the date that the equinox occurs in each time zone. Although the equinox occurs at the same
moment in time worldwide, the actual date may differ depending upon each time zone's geographical location.
For example, if the equinox occurs on September 22 at 20:02 GMT, the equinox occurs on September 22 for those
located in time zones in and West of GMT +1. For locations East of GMT +1, the equinox occurs on September 23.
You will require this information in order to send the email on the morning of the correct date.
Second, calculate the time in GMT to send an email to each customer in order to deliver an email to that
customer shortly after 12:00 am (customer local time) on the day of the equinox. Use GMT offset math to solve
the problem. Pega’s DateTime library does not contain any function that returns GMT offset within a particular
time zone at a particular GMT-expressed DateTime. The function named ToZoneId simplifies the calculation. The
function is created in a library named ZonedDateTime which imports java.time.* and java.time.format.*,
available in Java 8. The function is available to download via the related content link.
The function is shown in the following image.
The BackgroundProcEx case type populates a PageList of FSG-Examples-Data-TimeZoneInfo instances seeded with
different times. Four Rule-Declare-Expression(s) then fire against this PageList, the page context for the R-D-Es
being .TimeZoneList().
.TimeZoneList() R-D-E Expression

.LocalTime @ZonedDateTime.ToZoneId(Top.DateTimeString,.TimeZone)
.GMTTime @ZonedDateTime.ToZoneId(.LocalTime,"GMT")
.MidnightLocal @String.substring(.LocalTime,0,8)+"T000000.000 "+.TimeZone
.MidnightGMT @ZonedDateTime.ToZoneId(.MidnightLocal,"GMT")
Note: The .GMTTime property and associated R-D-E are not required as part of a solution. They are used for
verification. It’s value should always match Top.DateTimeString
Below is an illustration of the calculated times. Note: IDL stands for International Date Line.
To send a Happy Equinox email to customers in Honolulu, Hawaii, USA, so that the email arrives shortly after
midnight (local time) the morning of September 22, 2021, Front Stage would send it on September 22, 2017 10:00
GMT. Four hours later, i.e., the same difference between two time zones, the Happy Equinox Day email would be
sent to customers in Sydney, Australia.
Sydney and Honolulu are four time zones apart, hence midnight in Sydney occurs four hours later than in
Honolulu. The difference is that, after local midnight occurs in Sydney, the calendar date becomes one day
greater than the calendar date in Honolulu.
Sending the email according to the time calculation
Two Job Schedulers were defined in the solution, i.e., VernalEquinoxGreetings and AutumnalEquinoxGreetings.
These two Job Schedulers are configured to execute yearly on May 19, 2020 and Sept 21, 2020 respectively.
The LaunchTimeZoneQueueProcessors activity called by each Job Scheduler is told the equinox type, i.e., VERNAL or
AUTUMNAL, and for simplicity the DateTimeString when the equinox occurs. Ideally there would be a database
table where the DateTimeString could be queried based on the current year and equinox type.
The activity loops through distinct time zones identified by the D_SamplePersonTimeZoneList list data page. For
each time zone, the activity creates and populates an FSG-Examples-Work-BackgroundProcEx page named
CaseInfo. That page is then used as the step page when invoking the Queue-For-Processing method. The Queue-
For-Processing method sees that the configured, dedicated Queue Processor was configured as delayed. This
causes the Queue-For-Process method to display the Date time for processing field. If the Queue Processor was
not configured as delayed, that field would not be shown.
Note: An alternative approach, one that entails unnecessary risk, is having the LaunchTimeZoneQueueProcessor's
activity spin off a new BackgroundProcEx case for each time zone. Each spun-off BackgroundProcEx case would
avoid a disastrous runaway infinite loop by detecting that a page named CaseInfo exists on the Clipboard. Seeing
the CaseInfo page on the Clipboard, the spun off case would change to the Run in background alternate stage.
Within the Run in background stage, the DateTimeString and the TimeZoneInfo properties would be copied from
from top-level CaseInfo page into the BackgroundProcEx case prior to the Run in background flow shape. The Run
in background shape would tell the delayed SendTimeZoneGreetings Queue Processor to run at
.TimeZoneInfo.MidnightGMT.
The SendTimeZoneGreetings Queue Processor’s activity of the same name obtains and iterates each SamplePerson
in D_SamplePersonList[TimeZone:Param.TimeZone].pxResults. Rather than actually sending an email, which would
error out, the activity uses the Log-Message method in a step to output the timezone and WorkPartyUri values to
PegaRULES.log
In addition to the proposed solution, the following alternative approaches can be used to address the
requirements:
l Create an job scheduler for each known customer time zone. Configure each job scheduler to run at the
appropriate time for the given time zone. The job scheduler queries for customers within the indicated time
zone, sending each an email.
l Create only as many advanced agents that, when multiplied by the number of nodes, equals or exceeds the
number of known customer time zones. Allow the master agent to generate agent schedules. Remove the
unneeded agent schedule and modify the remaining agent schedules, setting the start time equal to when
emails are sent for a given time zone. Each agent schedules queries for customers within the indicated time
zone, sending each an email.
Advantages and disadvantages of each design

Design Pros Cons
Single-node job l Low maintenance l Additional complexity having to spin off a
l Same-day customer querying Queue Processor(s) per time zone
scheduler
l Distributed processing
l Avoids redundant emails
l Immune to node disablement
Job scheduler per l Distributed processing l High maintenance

l Avoids redundant emails l Affected by node disablement
time zone
l Customer time zones must be known well
in advance
Verify your work
1. Make certain that SamplePerson data is defined.
2. Log out the log back in as Admin@FSGEnt

3. Switch to the Background Proc Exercises Access Group
4. Copy/paste the value for pxRequestor.pyLastSignon to a text editor then add some number of minutes, for
example 10:
20201113T021633.688 GMT << current login time
20201113T021643.688 GMT << 10 minutes added
5. Locate the TestEquinoxGreetings Job Scheduler and check it out. Remember it is set to run every 10 minutes.
6. Click the Parameters link

7. Copy/paste the near-future date
8. Check in the Job Scheduler rule

9. In Admin Studio, filter on “Test” to locate the TestEquinoxGreetings Job Scheduler
10. Click “Override” if necessary to Enable the Job Scheduler
11. Click Override to disable the TestEquinoxGreetings Job Scheduler
12. Click Trace:
13. Eventually the Tracer will display information

14. Click on a row where D_SamplePersonTimeZoneList is the step page
15. Notice that the two time zones are identified:
16. Note how Queue-For-Processing was invoked twice:
17. Here is an example of CaseInfo page when Queue-for-Processing was called:

18. In Admin Studio click on Queue Processors then filter on “TimeZone”:
19. If more than two Queue Processor instances are created, remove them all and start over by enabling the Job
Scheduler and tracing
20. Disable the Job Scheduler as soon as a Trace is displayed:
21. LaunchTimeZoneQueueProcessors converts the provided Param.DateTimeString to local time zone,

Param.TimeZone
22. The computation of GMTTime shows the time conversion is reversible. It has nothing else to do with the
solution
23. The logic then computes midnight in the local time zone by setting the hours, minutes, second to 000000.000
24. Lastly the logic converts local midnight back to the GMT time zone:
25. Param.TimeZone = .TimeZoneInfo.TimeZone
LOOP: SamplePersonList[TimeZone:Param.TimeZone].pxResults:
26. Check the output to PegaRULES.log. Here is an example:
2019-11-13 10:27:33,102 [,19,2,3,4,5,6,7,8,9]] [ STANDARD] [ ] [ ] (s_Work_

BackgroundProcEx.Action) INFO - SendTimeZoneGreetings: TimeZone=Pacific/Honolulu,
WorkPartyUri=DonHo@tinybubbles.com
2019-11-13 10:27:33,102 [,19,2,3,4,5,6,7,8,9]] [ STANDARD] [ ] [ ] (s_Work_

BackgroundProcEx.Action) INFO - SendTimeZoneGreetings: TimeZone=Pacific/Honolulu
Exercise: Designing Pega for the enterprise

Scenario
You plan to meet with the Enterprise Architecture team at the organization to discuss the architectural
landscape at Front Stage and how the event-booking application fits into that landscape. You cover the following
topics:
l Application access
l Application server technology
l Integration and web services
l Data storage and warehousing
Application access
Front Stage plans to offer the ability for prospective customers to initiate a quote from the Front Stage cloud-
based web portal. Front Stage wants to allow event attendees to get basic event information from a chat
interaction. New sales prospects can create new Event Booking requests through social channels. Sales
executives also have access to a mobile application to track all open event bookings to follow up with the
prospect. This booking event details need to be available offline since sales executives travel frequently. Front
Stage uses an open source SAML single sign on (SSO) package for user access to all applications.
Application server technology

Front Stage deploys an enterprise archive on its application servers for all web applications. In the past, Front
Stage used container-managed transactions with an MDB listener to ensure messages entering the booking
application from external sources are retried if not successful. Going forward, with new ways of initiating booking
cases from offline mobile and social channels, use of an MDB may no longer be necessary.
Integration and web services

Front Stage provides access REST services to gather weather reports and traffic reports. The weather report
request/response is in JSON format. The traffic report uses XML. Front Stage protects all customer contact and
payment information through secure services.
Data storage and reporting

Front Stage uses a data warehouse to store and report on historical event information such as hotel bookings
and parking records. The new booking application feeds the warehouse for executive reporting. Warehouse
reports are available from the Pega application.
Your assignment
Produce a high-level architecture diagram and describe each application component. Use Visio, PowerPoint,
Image, or hand-draw your diagram. Assume an on-premises deployment.
In the diagram, illustrate:
l Components that are in Front Stage's virtual private network (VPN) and which are external to the network
l Components of the application, including web services and the components of the Booking application
l Relationship of booking application architectural components
As the alternative solution, describe any differences in design choices for the same set of requirements in Pega
Cloud.
Solution detail
Any options allowed by the Platform support guide are valid.
Alternate approach
If the application were to be deployed in Pega Cloud instead of on-premise, you also need to consider:
l Pega Cloud services networking – Work with the Pega Cloud team to configure the application to access
secured Front Stage resources.
l Integrating Pega applications in Pega Cloud with external systems – Review options available in Pega Cloud.
l Pega Cloud Security Overview – Examples include whitelisting and data residency.
l Business Intelligence Exchange (BIX) for Pega Cloud applications – Pega Cloud uses a separate node for BIX
processing.
Exercise: Defining a release pipeline

Scenario
The first delivery of the event booking application is targeted for production within 90 days. Front Stage wants to
deliver new application features and fixes on a daily basis by the end of year. Front Stage believes frequent
improvements to the application helps them gain an advantage in the event booking market. The Front Stage
architecture team thinks a Continuous Integration/Continuous Deployment (CI/CD) model is the best way to meet
this objective. Front Stage does not currently use any automated deployment practices or testing tools.
Your team of three developers develop the first release of the application at Front Stage headquarters. Front
Stage plans to hire a team of five new developers based in Poland to support new feature development and bug
fixing. Front Stage wants to move to a distributed development model within six to nine months, starting with the
Event Booking application. Front Stage also envisions every developer working in a local environment by the end
of the year.
Your assignment
Recommend a release strategy and plan to structure the development teams and environment to support Front
Stage's need to deliver new features and bug fixes daily after the first production release.
In your recommendation:
l Explain how to manage the work of the development team to deploy the first release application
l Recommend an approach for moving to a CI/CD model
l Describe how the two teams work together in a distributed environment
Solution detail
For the first release, you can apply the Standard Release process as described in the Pega Community. To
support development and deployment tasks during this first release:
l Identify someone to fulfill the role of Release Manager (responsible for managing ruleset versions and
overseeing the schedule)
l Use the prpcServiceUtils tool for service-enabled scripting to migrate rules between environments manually.
The preferred method is to implement pipeline automation for the first release using Pega’s Deployment
Manager, however this infrastructure is not readily available.
l Introduce branch reviews, guardrails, unit testing, and Branches and branch rulesets in the nonpipeline
model before implementing an automated release pipeline
After the initial release, work with the Front Stage architecture team to develop an automated pipeline for
implementing CI/CD.
Your recommendation includes the following actions:
l Bringing someone onto the team with automation server, repository, and CI/CD experience
l Determining the automation server and repository to use
l Describing how the automation server invokes automated testing tools, such as PegaUnit
l Identifying release tasks to be automated and in what time frame
Your recommendation includes the following actions:
l Identifying a release manager to oversee the pipelines
l Identifying who creates new ruleset versions and branches in the system of record
l Determining and communicating the process for handling import conflicts
l Communicating the frequency of development environment rebase
l Establishing pre- and post-import tasks, such as notifications and testing, to refine and improve continuous
integration process
You could also propose moving to a CI/CD model for the first release. Because Front Stage does not already have
a CI/CD model in place, attempting to implement this type of change could put the goal of delivering the
application in the 90 days in jeopardy. You can begin to introduce the practice of unit testing individual rules,
developing test suites, and delivering rules to target environments in an automated way using the Deployment
Manager or the prpcServiceUtils utility. This approach prepares the organization for automating the delivery
pipeline as the organizations CI/CD processes mature.
Exercise: Monitoring the guardrail compliance
score
Scenario
The development team has completed and checked in their work for the day. Now you perform a design review
to check the quality of the work by viewing any guardrail warnings produced in the application.

Admin Admin.Booking rules
Your assignment
Analyze the guardrail report warnings to identify rules that are reducing the compliance score. Use the
Guardrails landing page to review the Compliance Score, Compliance Details, Warning Summary, and
Warning Details tabs. If the current compliance score is unacceptably low, reconfigure as many rules as
necessary to improve the compliance score. Start with rules that have a severity warning of Severe. Then
address the rules that have a severity warning of Moderate.
Solution detail
Resolve Severe warnings
Start by reviewing rules that have Severe warnings and reconfigure those rules or justify them if they can not be
reconfigured.
Resolve SetOwningOrg activity warnings

Disable WriteNow in the Obj-Save method as follows:
1. In the Role column in the list of warnings, select the SetOwningOrg activity to open it.
2. On the Steps tab, open the Obj-Save method and disable the WriteNow check box.
3. On the rule form, select the Security tab and change the Activity type to Utility.
4. Click Save. This eliminates one Severe warning and one Moderate warning.
Resolve the SimulateRainForecast activity warnings

Replace the Property-Set method with a data transform as follows:
1. Create a new data transform with the following values.
Label Identifier Development Apply to Add to

branch ruleset
Simulate Rain SimulateRainForecast No branch FSG-Int-RainForecast- RainForecast
Forecast ForecastAPI
2. In the data transform rule, on the Definition tab, configure the steps as follows:
step Action Target Relation Source

1 Set .response_GET.forecast equal to @DateTime.addToDate( .request.query_
(<APPEND>).Date GET.StartDate,param.pyForEachCount,0,0,0)
2 Set .response_GET.forecast equal to 40
(<LAST>).Probability
3 Set .response_GET.forecast equal to "Percent"
(<LAST>).Unit
3. Click Save.
4. On the Guardrails landing page Warning Summary tab, in the Roles column, select the SimulateRainForecast
activity to open it.
5. In step 2 of the activity, replace the Property-Set method with the Apply-DataTransform method using the new
SimulateRainForecast data transform.
6. Select the Security tab of the SpinOffStandardAgent activity and change the Activity type to Utility.
7. Click Save. This eliminates one Severe warning and eliminate one Moderate warning.
Resolve Moderate warnings

Review Moderate warnings and reconfigure those rules or justify them if they can not be reconfigured.
To identify the rules with Moderate warnings, on Guardrail landing page Warning Summary tab, do the
following:
1. Disable the Severe and Informational check boxes.
2. Disable the Justified check box.
3. Select Apply Filter.
The rules with Moderate warnings are displayed. There may be as many as 27 Moderate warnings.
Reconfigure other activities.

1. Expand the Activity category in the Warning Summary tab.
2. Open each activity one at a time.
3. Examine the warning and reconfigure the activity as necessary to resolve the warning.
Verify your work

From the DEV Studio Configuration menu, select Application > Guardrails and review the Compliance Score,
Compliance Details, Warning Summary, and Warning Details tabs. The compliance score should have
noticeable improvements.
Exercise: Estimating hardware requirements
Scenario
The Front Stage event booking application is now 45 days post production. The application performs well, and all
users are satisfied with the responsiveness of the application.
Because of increased demand for event booking services in Los Angeles and Las Vegas, Front Stage plans to open
a US West Coast sales office and hire 400 new sales people. The sales people are expected to be mostly mobile
users of the event booking application.
Front Stage also plans to introduce a Request for Information (RFI) case type. The RFI case type allows new
contacts to get more information about Front Stage services before engaging with the Front Stage sales team.
Front Stage expects to provide this service from the corporate website. The RFI case type only contains basic
information about the request, such as contact information and description of the event. Front Stage expects to
receive 100 RFIs per day.
Jay Gerard, the VP of Enterprise Architecture, wants to know what infrastructure changes Front Stage needs to
make to support 400 new mobile users and the expected volume of RFI cases. You have some information about
the booking application environment to start.
Attribute Value
Application server Tomcat
Application server operating system Red Hat Linux
Database Oracle
JVM 64 bit
Highly available application? Yes
Pega version 7.3
Your assignment
Explain how to ensure the application can handle these new users and new case types. In the Solution
alternatives section, describe the impact this change would have if the event booking application was deployed
in a Pega Cloud production environment.
Solution detail
Initiate the hardware sizing request process with Pega.
Note: If you are a Pega employee, create a request in the Hardware Sizing Estimate application available in the
Pega Portal instead of following steps 1-4.
1. Send an email to HardwareEstimate@pega.com with your request. The Hardware Estimate sizing team sends
you an Excel-based questionnaire. For a sample empty questionnaire, see the Pega hardware resource
estimate questionnaire.
Important: Always start the request with this email. Do not use an existing version of the questionnaire.
2. Gather the environment and application information required by the questionnaire.
3. Complete the questionnaire as directed on the Introduction tab of the spreadsheet. For a sample completed
questionnaire, see the Front Stage sizing questionnaire.
4. Send the completed questionnaire to HardwareEstimate@pega.com.
After you receive the completed recommendation, meet with the resources at your organization to determine a
plan to modify the infrastructure based on this recommendation. For the completed sample sizing document,
see the Front Stage sample sizing document.
The process of initiating the sizing estimate for an application running on Pega Cloud is no different than
initiating the request for an on-premise application. The Hardware Estimate sizing team works with the Pega
Cloud team to recommend the most appropriate environment size for the organization based on the completed
estimate.
Exercise: Handling flow changes for cases in flight

Scenario
Front Stage's Booking application has been in production for a while and the number of event approval requests
has increased. Front Stage hired an additional executive officer to accommodate the increase. The new executive
officer is authorized to review and approve requests for fewer than 5,000 attendees during an undefined
probationary period. The existing executive officers approve requests for attendees between 5,000 and 10,000.
The CEO approves requests for events with more than 10,000 attendees.
Front Stage wants any existing cases awaiting executive approval to be distributed according to the new
requirement shortly after the new code is released into production.

Admin admin@booking rules
Your assignment
Implement a change to satisfy the new requirement. Elaborate on solutions for identifying cases in flight affected
by the new configuration, and reposition them to the appropriate location in the flow. Set up test cases to verify
that the change works for cases in flight.
Solution detail
To complete the solution, you will do the following:
1. Create Event Booking test cases.
2. Create the new Executive Officer Operator ID.
3. Create a new Booking patch ruleset version.
4. Update the FSG organization record.
5. Modify the ExecutiveReview_Flow process.
6. Create the maintenance activity.
7. Create a new DevMaintenance ruleset.
8. Create a new ShouldRestartCase when rule.
9. Create a new RestartStageFromWorkbasket activity.
Create Event Booking test cases

Prior to developing the solution, create test cases with 3000, 6000, and 11,000 attendees and advance them to the
executive approval stage.
Create the new Executive Officer operator ID

Create a new Executive Officer operator ID that uses the default workgroup. This change prevents cases assigned
to the Booking:Executives workbasket (Executives work queue) from being assigned to the new executive officer
until the end of the undefined probationary period.
1. In your exercise system, log in as Admin.Booking.
2. Copy the existing ExecutiveOfficer2.Booking operator ID using the following settings.
Field Setting
Short description Executive Officer 3
Operator ID ExecutiveOfficer3.Booking
3. Click Create and open to create the operator ID.

4. In the Profile tab, change the Full Name to Executive Officer 3 and the Email to ExecutiveOfficer3@FSG.com.
5. In the Work tab, change the default Work group from Executives@FSG to default@FSG.
6. Save the new ExecutiveOfficer3.Booking operator ID.
Create a new Booking patch ruleset version
To facilitate testing, create a new patch ruleset version for the Booking ruleset. This allows you to create cases
using the original configuration and then test the changes by including or excluding the patched ruleset version
in the application definition.
Update the Booking application definition to ensure that you have access to the new Booking patch ruleset
version.
Update the FSG organization record

To facilitate routing to the CEO.Booking, update the FSG organization record so that CEO.Booking is the Controller
operator ID.
1. Open the FSG organization record.
2. Set the CFO/Controller Operator ID field to CEO.Booking.
3. Save the updated organization record.
Modify the ExecutiveReview_Flow process

Introduce the change using new shapes in the ExecutiveReview_Flow flow and add a decision mechanism to route
events with fewer than 5,000 attendees to the new executive officer, to route events with attendees between
5,000 and 10,000 to the existing executive officers, and to route events with more than 10,000 attendees to the
CEO.
1. In the App Explorer, open the (FSG-Booking-Work-Event) ExecutiveReview_Flow process.
2. Save a copy of the flow to the new Booking patch ruleset version.
Important: Do not remove the existing Approve Event Quote smart shape. Doing so orphans any existing
approval assignments.
3. Add a decision shape labeled Approved By?, configured as a Fork type.
4. Create an IsCEOApprovalRequired when rule. Define the When condition as Number of Attendees > 10000.
5. Create an NewExecutiveApproval when rule. Define the When condition as Number of Attendees < 5000.
6. Set the label for the Else connector to Executive Officer Approval and connect it to the existing Approve Event
Quote smart shape.
7. In the CEO Review assignment shape, configure routing to the CEO.Booking operator.
8. In the New Executive Review assignment shape, configure routing to the ExecutiveOfficer1.Booking operator.
9. In the Automation details section of the Change stage to Executive Rejection smart shape, select Executive
Rejection in the Stage field.
The reworked ExecutiveReview_Flow process is shown in the following diagram.
Create the maintenance activity

Additionally, an activity identifying any cases in flight positioned at the Executive Review step in the flow is
required. The activity restarts the flow for those cases so that they get routed according to the new logic.
To create the new RestartStageFromWorkbasket activity, do the following.
1. Create a new DevMaintenance production ruleset that is accessible by only the Admin.Booking operator ID.
2. Create a new ShouldRestartCase when rule for the RestartStageFromWorkbasket activity to use.
3. Create a new RestartStageFromWorkbasket activity that restarts the stage for a parameterized workbasket.
Create a new DevMaintenance ruleset

As a best practice, place this type of maintenance activity in it's own ruleset that is accessible only by developers
and administrators.
1. Using the Records Explorer, find and open the Booking:Administrators access group.
2. In the Advanced tab of the Booking:Administrators access group, enter DevMaintenance in the Production
Ruleset list.
3. Click the target icon to create and open the record.
4. Save the new ruleset. Then save the updated Booking:Administrators access group.
5. Log out and log back on as Admin.Booking.
Create a new ShouldRestartCase when rule

Initially configure the ShouldRestartCase when rule to always return true.
1. Create a new ShouldRestartCase when rule. Use the following settings.
Field Setting
Label Should Restart Case
Development branch No branch
Production Rulesets Select radio button
Apply to Assign-WorkBasket
Add to ruleset DevMaintenance
2. Click Save and Open to create the ShouldRestartCase when rule.

3. In the Conditions tab, specify a when condition Rule Always evaluates to true.
4. If necessary, you can use a specific case type Apply to class to override the ShouldRestartStage when rule.
Create a new RestartStageFromWorkbasket activity

This activity restarts the stage for the case and repositions the flow. The activity only acts on cases in the
parameterized workbasket. If a large number of cases require updating, configure the activity so that it has
robust error handling and periodic commit capabilities.
1. Create a new RestartStageFromWorkbasket activity. Use the following settings.
Field Setting
Label Restart Stage From Workbasket
Development branch No branch
Production Rulesets Select radio button
Apply to Work-
Add to ruleset DevMaintenance
2. Click Save and Open to create the new RestartStageFromWorkbasket activity.

3. In the Parameters tab, enter two parameters as defined in the following tables.
WorkBasket parameter
Field Setting
Name WorkBasket
Required Yes
Data type String
In/Out In
RefObjectKey parameter
Field Setting
Name RefObjectKey
Required No
Data type String
In/Out Out
4. In the Pages & Classes tab, declare the following:
Page name Class

D_WorkBasket.pxResults Assign-WorkBasket
CasePage Work-
The completed tab looks like the following image.
5. In the Steps tab, add the following steps.
Step Method Step page Description

1 Property-Set D_WorkBasket Loop D_WorkBasket
[WorkBasket:param.WorkBasket] [WorkBasket:param.WorkBasket]
.pxResults .pxResults when
ShouldRestartCase
1.1 Obj-Open-By-Handle CasePage Open by
Param.RefObjectKey handle
set in loop, lock, release on
commit
1.2 call pxRestartStage CasePage Restart the Stage that the case
is in
1.3 Obj-Save CasePage Save
1.4 call commitWithErrorHandling CasePage Commit with error handling
2 Page-Remove Page-Remove CasePage
6. For Step 1 in the activity, do the following:
a. Configure Loop to Repeat For each embedded page.
b. In the When section, do the following:
i. Select the Enable conditions before this action check box.
ii. In the When field enter the new ShouldRestartCase when rule. In the if true field, select Continue
Whens. In the if false field, select Exit Iteration.
The completed When section looks like the following image.
c. For the Property-Set method, configure the Method Parameters to set PropertiesName
Param.RefObjectKey to PropertiesValue .pxRefObjectKey.
The completed Method Parameters section looks like the following image.
7. For the Obj-Open-By-Handle method in Step 1.1, set the InstanceHandle value to Param.RefObjectKey as
The completed Steps tab is shown in the following image.

Verify your work
Test the changes by running the RestartStageFromWorkbasket activity as follows:
1. Open the RestartStageFromWorkbasket activity and select Actions > Run.
2. Use Booking:Executives as the WorkBasket parameter and select Run. If the maintenance activity runs
correctly, a confirmation dialog with a green check mark is displayed.
3. Reopen the cases you created earlier to verify that they are assigned to the correct operators or workbasket
based on the updated flow.
Several approaches to working with cases in flight during code releases are available. However, letting only a
subset of operators deal with the current cases is not a viable solution because the affected cases require
repositioning shortly after the code release.
This solution leverages the fact that the executive review is the first step in the stage. If the executive review is
not the first stage, a ticket needs to identify the point to jump to in the flow. A ticket can be used here as well, but
it becomes a leftover artifact after the change has been implemented.
Exercise: Extending applications to other areas of
the business
Scenario
Front Stage acquires a company named Opera. Both companies have similar business models of helping
customers book and host guests for events. However, Opera manages only indoor events and does not perform
parking or weather preparation tasks. Like Front Stage, Opera must also be able to reserve hotel rooms for
events.
Front Stage wants to reuse its existing assets to support and promote Opera's business model. At the same time,
Front Stage does not want to restrict its outdoor event hosting business model.

Admin admin@Opera rules
Your assignment
Recommend a solution that enables Opera to reuse Front Stage's ability to reserve hotel rooms.
Possible approaches
There are two possible design approaches.
l Create a new Opera application built on the existing Event Booking application. You define Opera as a new
division of Front Stage. Class names within this new layer begin with FSG-OPERA-OPRA.
l Create a new Opera application built on the existing Hotel application. Class names within this new layer
begin with FSG-OPRA-.
Evaluate the design pros and cons

Design Pros Cons
Build on the Event Booking l Opera's static content branding rules l There is dependency on the Event
can be placed in the Opera division Booking Application’s release
application. Opera is a ruleset. cycle.
division. l Many rules within the ruleset
stack are never accessed.
Design Pros Cons
Build on the Hotel l There is independence from the l A special ruleset is needed to
Event Booking application’s release support Opera's static-content
application. Opera is not a cycle. branding rules.
division. l The ruleset stack only includes rules
that are accessed.
l This is simpler to maintain and it
promotes Opera’s unique business
model.

Building the Opera application on the Hotel application provides flexibility. The Opera application is only
affected by the release cycle of the Hotel application, which is less complex than the Event Booking application.
This approach avoids defining Opera as a Division, which lengthens class names. The Opera organization is free
to create a ruleset similar to the FSG ruleset that every Opera-related application utilizes.
Detailed steps
1. In your exercise system, log in as Adminstrator@pega.com.
2. From the Records Explorer, open the Hotel application record.
3. In the Application wizard tab, do the following:
a. Select the Show this application in the New Application wizard check box,
b. In theShort description field, enter Hotel Rooms Request.
c. In the Application description field, enterRequest that a hotel reserve multiple rooms for an event.
The completed Application wizard tab looks like the following image.
4. Save the Hotel application record.

5. Run the New Application wizard.
6. Build the new application on Hotel, Use this application type, Include all case types, and Include all data
types.
7. Select primary device Responsive and select a color scheme.
8. Name your application Opera.
9. Complete the Advanced configuration dialog as shown in the following image.
Note that the work pool classes are created by the system (for example, FSG-OPRA-Work-Hotel).
10. Click Save to save your settings and exit the Advanced configuration dialog.
11. Click Create application to create the new Opera application and then click Done to exit the New Application
wizard.
Create the Admin@Opera operator

1. From the Records Explorer, create an operator ID.
2. In the new rule form, in the Short description field, enter Admin@Opera. In the Operator ID field, enter
Admin@Opera.
3. Click Create and open to create the new operator.
4. In the Profile tab, enter the following:
Field Setting
Title Administrator
First name Admin
Last name Opera
Field Setting
Full name Admin Opera
Position/job title Administrator
Email Admin@Opera
5. Select the default access group to Opera:Administrators.

6. In the Work tab, in the Organizational unit field, select FSG / Div / Unit.
7. In the Security tab, update the password to rules, and select the Allow rule check out check box.
8. Save the Admin@Opera operator.
9. Log off. You are now ready to configure the Opera application.
Configure the case types

1. Log on using the operator ID Admin@Opera.
2. In the Cases Explorer, add an Opera Event case type and define the existing Hotel case type as a child case
type of the new Opera Event case type.
3. Select the new Opera Event case type.
4. In the Data Model tab, add a field group list named .HotelList and use data type FSG-Data-Hotel.
The completed tab looks like the following image.
5. In the Settings tab, do the following:

a. Select the Data propagation section.
b. Expand Into Hotel and add the properties you want to propagate as shown in the following table.
Propagate property value To property value

.RoomRequest .RoomsRequest
pyWorkParty pyWorkParty
c. Click OK to save your updates.
The completed Data propagation section looks like the following image.
d. Select the Parties section and configure the Owner party to Display on creation.
e. Select the General section and select the Skip 'Create' view when users create a new case check box.
This step prevents issues that may occur when advancing past the first screen during testing.
Create the Opera Event case life cycle

1. On the Workflow tab, click Add life cycle to create an Opera Event case life cycle.
2. In the Life cycle tab, add a Create Hotels stage.
3. Add a Create Case step to the Create Hotels process.
4. In the create case Step description panel, select Create child cases(s) and configure the step as follows:
Field Setting
Create the following case Hotel
Starting process Hotel
Create multiple cases using a list Select check box
List field .HotelList
Data transform UpdateFromHotelPage
Source page parameter name HotelPage
The completed Step description looks like the following image:
5. Click the cross hair icon next to the Data transform field to open the UpdateFromHotelPage data transform.
6. Configure the UpdateFromHotelPage data transform as shown in the following image.
7. In the life cycle, add a Wait Utilities step after the Create Case step. Configure the Wait step as shown in the
following image.
Field Setting
Wait type Case Dependency
Wait for (Case type) All Hotel
To be resolved Select this option
Scope Current case
Users can choose to continue process Select this option
The completed Step description looks like the following image.
8. Add a Resolve stage after the Create Hotels stage.

The completed life cycle looks like the following image.
Configure a stage for entering test data
1. In the Data Explorer, ensure that at least one hotel instance exists.
2. Edit the (FSG-OPRA-Work-OperaEvent) pyDefault data transform to populate the .HotelList field group list with
test data as shown in the following image. You will need to add Page name D_HotelList.pxResults with Class
FSG-Data-Hotel to the Pages & Classes tab.
3. Copy (FSG-Hotel-Work-Hotel) pySetFieldsDefaults to FSG-OPRA-Work-OperaEvent and apply the data transform

from the (FSG-OPRA-Work-OperaEvent) pyDefault data transform as shown in the following image.
4. To FSG-OPRA-Work-OperaEvent, copy the FSG-Hotel-Work-Hotel EnterTestData_Flow flow, the EnterTestData

section, and the EnterTestData flow action.
5. On the Opera Event life cycle, add Enter Test Data as the first stage. Create Hotels is now the second stage as
Verify the results

1. Launch a Case Manager Portal.
2. Create an Opera Event case.
3. Advance the case to the Review form at the Wait step.
4. From the Actions menu, select Continue Process.
The form looks like the following image. Note that two Hotel cases were created.
Exercise: Leveraging AI and robotic automation
Scenario
Front Stage competes with Bright Lights Booking Co. Jay Gerard, the VP of enterprise architecture, heard from a
former employee that Bright Lights offers a self-service option on their website to schedule an appointment with
a sales representative. Front Stage offers live chat on their website, but booking the appointment is a manual
process. This process requires the service representative to search three separate legacy systems to gather the
data needed to set up the appointment.
Bright Lights also uses an artificial intelligence (AI) solution (called the Bright Lights Buddy) to provide expert, yet
completely automated, guidance to sales people in producing a quote for the event. Bright Lights' AI solution has
predicted the actual cost of an event 80 percent of the time within a two percent margin of error. At Front Stage,
producing an accurate quote requires heavy involvement from the sales executive. If the sales executive is not
involved in the quote generation process, the actual cost of most events exceeds the quoted amount. The sales
executive's time is precious and costly. Front Stage desires to use AI to provide a more accurate quote.
Finally, Bright Lights uses the same mainframe-based hotel reservation system that Front Stage uses. The
reservation system is notoriously complicated, causing average call-handle times to be upwards of 10 minutes to
make a simple change to a reservation. The average call-handle time for Bright Lights is three minutes. Front
Stage is considering building a REST service to connect to the hotel reservation system. This project is time-
consuming and costly, so Front Stage has put it off.
Jay is concerned that Bright Lights will start taking away Front Stage's market share because Bright Lights offers
faster and higher-quality customer service. Your assignment is to propose a solution to Front Stage that
leverages AI or robotic automation to provide an improved experience for Front Stage's customers and better use
the time and expertise of Front Stage employees.
Approach
Review each comment from Jay and research how automation and AI could be leveraged to allow Front Stage to
compete with Bright Lights. In addition, present a recommendation to Jay on how he could use automation and AI
to transform how Front Stage operates long term.
Solution detail
The chat experience can be handled without any human intervention. Leverage the Intelligent Virtual Assistant to
handle the chat interaction. The process of booking an appointment could run unattended using robotic process
automation (RPA).
To create a similar self learning AI to help with quoting process, Front Stage can use predictive and adaptive
analytics. Using the Adaptive Decision Manager, Front Stage can train the AI solution to produce a more accurate
quote by loading sample quote data. Over time, the AI solution will drive more accurate outcomes, freeing the
Sales Executive to focus on higher value tasks, like building relationships with prospective and existing
customers.
For the hotel reservation process, Front Stage can use robotic desktop automation (RDA) to log into legacy
systems and create an automation using RDA to mimic the actions of logging into the mainframe computer and
booking the hotel reservation. Propose use of workflow intelligence (WFI) to identify where slow downs are
occurring in the current process to find opportunities to streamline this process further.
For the hotel reservation, you could have built the REST service and not used AI or robotics at all. You also could
have proposed the usage of an outsourcing model to help with quoting and take on chat interactions. Both of
these options would not put Front Stage in a better position to complete with Bright Lights long term. Front Stage
needs a different approach to compete with Bright lights.

c1791 Exercise Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

c1791 Exercise Guide

Uploaded by

Copyright:

Available Formats

Lead System Architect 8.

This document is the property of:

Exercise: Designing Pega for high availability 1

Exercise guide reference

Your mission: Architect a Pega solution for Front Stage

DEV Studio configuration

Pega Marketing and Customer Decision Hub

Pega Customer Service and Robotics

Single Case with subcases

Multiple cases (with subflows/processes)

Conditionally creating top level case (with subflows/processes)

Pros/cons of each approach

Conditionally l Case created only when Event l No record of rejected quotes

Alternative approach analysis

Design Pros Cons

Conditionally l A weather subcase is l The history leading up to the decision to

Design Pros Cons

Role Operator ID Password

Application A. Booking A. Contains Event Booking rules

Create case type-specific rulesets

Add new Event, Weather, Parking and Hotel subcase types

Define stages and process steps for the case types

Verify your work

Event case type stages, processes and steps:

WeatherPrep case type stages, processes, and steps:

Booking 01.01.01 Goals

Booking 01.01.02 Goals

Role Operator ID Password

Minimum Data Model to support an Event case type - Design

Application layering - Implementation

Minimum Data Model to support an Event case type - Implementation

Ruleset Usage - Implementation

Other Key Features

Verify your Work

Role Operator ID Password

Create the Demos application

View Relevant Records verifying potential reuse

Role Operator ID Password

Data driven rules

Single application rule specialization

Application per venue

Recommended design approach

Spun-off Email process Component

Advanced Agent-processed Email data instances

Email subcase component application

Recommended design approach

Exercise: Leveraging the email component

Email Case Stages:

Enter Test Data Stage:

Edit Send or Skip Stage:

Detailed construction steps (optional)

Create the email application

Create the email case type and case life cycle

Configure supporting rules in Designer Studio

Complete the case life cycle

Note: You can update the step name to Send Email.

Make the application available in the New Application wizard

Verify your work

Exercise: The Hotel and Hotel Proxy

Role Operator ID Password

Note: Use Advanced/granular mode to import the RAP file.

RoomsRequest Case Type

Create Proxy Stage