Creating the booking and FSG applications
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:
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.
1 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.
- Cloud instance (online)
- 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:
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.
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 need to import the FSG Booking solution RAP (Rule Application Product) file provided in the beginning of the course 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.
2 Determine the Booking application structure
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.
3 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 the FSGSample App BEFORE column of the following table.
FSGSample App BEFORE
FSGSample App AFTER
Built on FSG App:
A copy of the FSGSample application is then saved as FSG 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 the FSG rulesets are in use by other applications at any given time.
4 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 avoids having to re-enter the same information when a repeat customer wants to book another event.
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 one or more subcases into a reusable component applications. Smaller applications are more flexible and easier to maintain and deploy. This strategy is similar to the microservices strategy where monolithic applications are avoided.
To develop and test the Booking application, an FSG-Booking-Work case type class needs to exist every inherited case type defined within a built-on application. For each subcase case type, the Booking Team creates a corresponding ruleset within the Booking application. The Booking Team then creates a corresponding case type within each corresponding ruleset. Afterward, the generated case type class's direct inheritance is changed to the class of the corresponding built-on application's case type. Lastly the generated Case Type rule in each corresponding Booking application ruleset was deleted.
In the Booking application's Case Designer, the WeatherPrep, BookingParking, and RoomsRequest case types cannot be edited since a Case Type rule does not exist. ICase Designer editing is performed within the built-on WForecast, Parking, and Hotel applications. This technique avoids the “two applications being edited simultaneously” problem, where rules can end up in the wrong layer and in the wrong ruleset.
This approach works well for the Booking team, and they are pleased with the result. As is often the case, several rules deemed unnecessary or obsolete are withdrawn during development. A major skim is performed on every ruleset to cause those unnecessary or obsolete rules to no longer be visible.
5 Review solution download
If you are using the off line local virtual machine you will need to download and import the FSG Booking solution RAP (Rule Application Product) file provided in the beginning of the course. 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.