Creating the booking and FSG applications

5 Tasks
40 mins
40 mins
Release 2
Pega Platform
8.5
English
Scenario

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 challenge: Architect a Pega solution for Front Stage Group (FSG)
During this mission, you create an event booking solution for Front Stage Group (FSG). Using the business scenario
document, you apply what you learn in each module to design the best technical solution to meet Front Stage's vision of
digital transformation.

Here is the detailed FSG Business Scenario:

Front_Stage_Scenario_Requirements_85.pdf

Each challenge includes a unique scenario and assignment that identify the specific business problem to address. Before
you attempt each challenge, review the scenario and assignment to understand the goal of the challenge.

The following table provides the credentials you need to complete the challenge.

Role User name Password

Administrator Administrator@pega.com install

Administrator COE@FSG rules

Administrator Admin@Booking rules

Detailed Tasks

Establish your exercise system

Pega Academy provides an opportunity for you to practice what you learn.

Pega Academy provides different types of exercise systems for you to complete the exercises.

1. Cloud instance (online)

2. Virtual Machine (VM) (offline)

The cloud instance (when available) is accessible by clicking the Initialize Pega button within the Scenario challenge
instructions.

The VM is made available as an OVA (Open Virtualization Archive) file that contains a compressed, "installable" version of a
virtual machine.

You can use any VM Player of your choosing, such as Virtual Box (Windows, macOS), VMWare Player (Windows),
or VMware Fusion (macOS). You are responsible for downloading and installing your own VM player.

Exercise VM archive
The exercise VM is made available as an .ova (Open Virtualization Archive) file that contains a compressed, "installable"
version of a virtual machine. You can download the VM .ova file and corresponding checksum (.md5) by using the following
links:

LinuxLite-Pega852.ova

LinuxLite-Pega852.md5

The .ova file is 8.1 GB and can take a while to download. Because of the large file size, we recommend using Chrome or
Mozilla to complete the download. After downloading the .ova file, you can use the checksum file (.md5) to ensure that the
data within the .ova file is complete and has not been corrupted during the download. After downloading the file, if it has a
.tar (Tape Archive) file extension, rename the .tar file extension to .ova before running the checksum or importing
it. Windows, macOS, and Linux all have built-in utilities for generating checksums. For example, on Windows, you can run
the command, " Get-FileHash LinuxLite-Pega852.ova -Algorithm MD5 " from Windows PowerShell.

If you are using Microsoft Internet Explorer, Microsoft Edge, or Google Chrome, please read the
Pega_Virtual_Machine_User_Guide_85.pdf for important information about correctly configuring the exercise VM.

Pega Virtual Machine User Guide_85.pdf

Use your virtualization software (VM Player) to open, import, and extract the .ova file.

Although Pega does not provide a VM Player for you to use, we do recommend that you use one of the following: Virtual Box
(Windows, macOS); VMWare Player (Windows); VMware Fusion (macOS). The Virtual Machine User Guide provides details
on downloading and importing the OVA file and running the VM in one of the recommended VM players. You are responsible
for downloading and installing your own VM player.

You also need to import the FSG_COE_Booking_852_1.zip RAP (Rule Application Product) file also found in the Review
Solution Download section of this challenge into your Pega Platform once you have installed the Linux-Lite VM. To enabled
all operator id’s during import of the RAP file, please be sure to select the “Enable advanced mode to provide more
granular control over the import process” and “Enable new operators and overwrite existing operators on import”
options.
Determine the Booking application structure
After analysis of the Booking application’s requirements, the following conclusions are reached:
After analysis of the Booking application’s requirements, the following conclusions are reached:

The Divide-and-Conquer design pattern is the best fit for this application.
A subcase hierarchy is a better approach than using same-case, parallel processes.
A single weather subcase is unconditionally created.
A single parking subcase is conditionally created.
A rooms-request subcase is conditionally created for each selected hotel.
Review the construction of the FSG Enterprise application
The PegaRULES application contains a class group named PegaSample. The purpose of this class group is to demonstrate
the features and capabilities of Pega Platform™. The number of records associated with the PegaSample class group is
minimal relative to the rest of the PegaRULES application. Nevertheless, PegaSample records are never used in a
production application. The PegaSample application might be packaged as a separate application built on PegaRULES.

An enterprise application does not need to contain case types. The main purpose of the enterprise application is to provide a
standardized business object data model plus other reusable record types, such as Libraries. This description describes the
FSG Enterprise application, which in theory is maintained by FSG’s Center of Excellence (COE) group. The FSG application
itself does not include any case types. Other applications maintained by the COE group, such as FSGEmail, are built-on the
FSG application and contain case types.

Any application created with the New Application wizard contains a work pool class and class group. The New Application
wizard outputs classes that begin with ORG-APP-[Data/Work/Int/UIPages] and classes that begin with ORG-[Data/Int]. The
New Application wizard also creates an ORG-FW abstract class regardless of choosing Framework, which can be ignored if
not used.

Similar to the way PegaRULES uses PegaSample, an enterprise application should offer a way to test and demonstrate the
features that it contains. Like PegaRULES, an enterprise application does not need to include that test and demonstration
records within its application. Instead, a test and demonstration application can be built on the enterprise application; this
raises the question: how is the enterprise application constructed?

The FSG Enterprise application is constructed by having the New Application wizard create an application named
FSGSample. The initial application contains the four rulesets listed in theFSGSample App BEFORE column of the
following table.

FSGSample App BEFORE FSGSample App AFTER

FSGSample FSGSample
FSGSampleint FSGSampleint
FSG
Built on FSG App:
FSGInt
FSG
FSGInt

A copy of the FSGSample application is then saved asFSG to the FSG ruleset. The FSG and FSGInt rulesets are then
removed from the FSGSample's application ruleset stack in its definition. In place of the removed rulesets, the FSGSample
application declares the FSG application as a built-on application. In turn, the FSG application removes the FSGSample and
FSGSampleInt rulesets from its ruleset stack.

A small number of changes are needed to make the FSG application valid, starting with selecting an available skin rule such
as the generic CosmosSkin or other FSG organization level skin. Also, in the Associated Classes section of the Cases and
Data tab, the class names need to be updated to reference valid classes. For example, in the case of the FSG application,
the referenced classes need to be FSG-specific because every ORG class extends Work-Cover- the FSG class can be
declared a class group so that the App Explorer displays the FSG class. Finally, the Application Wizard tab can be edited to
advertise that the FSG application is intended for use as a built-on application.

For consistency, the Validation mode of the FSG and FSGInt rulesets is changed from Ruleset Validation to Application
Validation. This option provides more control over which versions of theFSG rulesets are in use by other applications at any
given time.

Review the construction of the production Booking application

The Booking team can construct the Booking application on top of the FSG application by themselves. Instead, because the
Booking application is considered critical to FSG’s success, the Center of Excellence (COE) team feels it is best to define the
first stage of the Booking application’s BookEvent case then let the Booking Team develop the rest.

The COE does this to ensure that pricing is initialized properly. The COE also wants to ensure that “Customer” is
implemented as an FSG-Data-Contact reference and that an event’s venue is implemented as an FSG-Data-Venue
reference. Storing customer information in the CustomerData schema outside the BLOB supports an autocomplete control to
populate customer information rapidly. This feature is essential for repeat customers to avoid entering the same information
whenever they want to book an event.

The Booking team is aware that a RoomsRequest case takes longer to develop than the Weather and Parking subcases.
Constructing the RoomsRequest case within a built-on application, but not the other two subcases, is possible. The only hint
that a second application might use a Hotel application is the rumor that FSG might acquire a company named Opera in the
future. That company does not support outdoor events.

Instead, the Booking team decides to develop their application in a highly modular way. Doing so facilitates speedier
development since more coding can be performed in parallel. Plus, the Booking Team does not want to refactor their
application in the future to decompose the Parking or Weather into a reusable component application if their assumption that
no other application would want Weather or Parking capability s incorrect. Smaller applications are more flexible and easier
to maintain and deploy, a strategy similar to microservice strategy where monolithic applications are avoided.

The Booking application needs a case type for every inherited case type that is defined in a built-on application to develop
and test. The Booking team first created a case type for the Weather and Parking cases in a case-specific ruleset, modified
the direct inheritance for those case types, and intentionally deleted the Rule-Obj-CaseType rule in the Booking application’s
WeatherPrep and Parking case type class. The Booking application rule still declares the class for WPREP- to beFSG-
Booking-Work-WeatherPrep and the class for PARK- to be FSG-Booking-Work-BookingParking. In contrast, the
RoomRequest case within the Booking application retains its case type rule.

In the Booking application, the WeatherPrep and BookingParking case types cannot be edited using the Case Designer.
Instead, Case Designer editing is performed only within the built-on WForecast and Parking applications. Doing so avoids the
“two applications being edited simultaneously” problem, where rules can end up in the wrong layer and the wrong ruleset.

Besides application switching, other ways exist to avoid accidental updates to the Booking application case type, rather than
a built-on application’s case type. Having a separate ruleset per case type, regardless of the application, helps considerably.
Within the Booking Rule-Application rule, a ruleset version can be specified at the patch level where that version is locked.
Rulesets for other case types, such as the RoomsRequest case’s HotelBooking ruleset, can be specified at the minor version
level within the Booking application rule. The HotelBooking ruleset contains an unlocked version.
 This approach works well for the Booking team, and they are pleased with the result. As is often the case, several rules that
are deemed unnecessary or obsolete are withdrawn during development. A major skim is performed on every ruleset, as
shown in the following image.

Review solution download

If you are using the off line local virtual machine you will need to download and import theFSG_COE_Booking_852.zip
solution RAP file. To enabled all operator id’s during import of the RAP file, please be sure to select the Enable
“ advanced
mode to provide more granular control over the import process” and “Enable new operators and overwrite existing
operators on import” options.

FSG_COE_Booking_852_1.zip

Creating the booking and FSG applications -- Mon, 05/24/2021 - 03:17

To get the full experience of this content, please visit Creating the booking and FSG applications