Implementing case type life cycles
Archived
3 Tasks
20 mins
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 BookEvent top level case is implemented to accommodate child cases.
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. Creating it as a child case and having it wait is acceptable.
Parking case type stages, processes, and steps:
The steps for the Parking case are:
- Route to a Facility Coordinator to arrange the shuttle service
- Wait until the day after the event.
- The Facility Coordinators must collect and report the number of cars parked during the event.
There is no need to complete the Parking case currently. Creating it as a child case and having it wait is acceptable.
Hotel case type stages, processes, and steps:
The steps for each Hotel child case are undecided other than knowing that an email should be sent to 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 Purpose
Booking 01.01.01 represents the work you did in the previous exercise, "Creating the Booking and FSG applications". It's represents some of the initial "groundwork” for the Booking application prior to the business process logic being implemented.:
- Application layering
- The “Book Event”, “Weather Preparation”, and "Parking" case types class hierarchy
- Ruleset usage
After the 01.01.01 version of the Booking application was defined, the rulesets where left unlocked, in case you, as a student wanted to further develop the work you did in the previous, "Creating the Booking and FSG applications" exercise. The application was then versioned to 01.01.02.
Booking 01.01.02 Goals
As stated earlier an LSA should proactively “lay the groundwork” for the new applications prior to the business process logic being implemented. Ground work items should at a minimum include:
- Application layering
- The “Book Event”, “Weather Preparation”, and "Parking" case types class hierarchy
- Ruleset usage
- Minimum Data Model to support a “Book Event” case and “Weather Preparation” case
To save time, we have defined the Minimum (or preliminary) Data Model to support the “Book Event” case and “Weather Preparation” case for you in the 01.01.02 version of the Booking application. The data model will be discussed in a subsequent lesson. After the 01.01.02 version of the Booking application was defined, a Product rule was created in the Booking 01-01-02 ruleset version then locked down, The application was then versioned to 01.01.03.
Booking 01.01.03 Purpose
Represents the application version and unlocked rulesets that you can use to work out and implement the details on your own of what is presented in the solution for this exercise. When you first login as Admin@Booking01, the access group for Booking 01.01.03 is selected by default. You can use the access group for the Booking 01.01.03 application to:
- Practice building out the solution on your own
- Experiment with different approaches and designs
- Switch back and forth between the solution and your work
After the 01.01.03 version of the Booking application was defined, the ruleset versions where left unlocked so that you can use Booking 01.01.03 as you work environment, the application was then versioned to 01.01.04, which contains the solution.
Booking 01.01.04 Goals
The Booking 01.01.04 application version is the solution for this exercise. The goal of the 01.01.04 Booking application version is to demonstrate how to leverage the case design, data model, and application layerig supplied by Booking 01.01.02. Case processes are implemented such as the Quotation stage and the FSG Approvals stage. A third “Manage Event” stage was also added to create the WeatherPrep and Parking child cases.
The following table provides the credentials you need to complete the challenge.
| Role | Operator ID | Password |
|---|---|---|
| Administrator | [email protected] | install |
| Administrator | Admin1@Booking | rules |
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.02 and 01.01.04 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:
- Application Layering - Design
- Minimum Data Model
- Ruleset Usage
- Application Layering
- Other Key Features
Detailed Tasks
1 Exercise Setup
The exercise is presented in four (4) phases delimited by four separate Access Groups for your review and use. To review the provided exercise phases you will need to import the provided Booking_Lifecycle_Solutions.zip RAP file.
Note: Importing the Booking_Lifecycle_Solutions.zip RAP file may overwrite some of the experimental work you completed in the previous "Initializing the Event Booking Application" exercise with the design that we will be using as a baseline for the remainder of the exercises in the course.
- Login as [email protected].
- Import the Booking_Lifecycle_Solutions.zip RAP file.
- During import enable the Enable advanced mode to provide more granular control over the import process check-box on the File information form.
- During import enable the Enable new operators and overwrite existing operators on import. check-box on the Operators form.
- During import enable the Import aged updates check-box.
- During import enable the Replace with older copy check-box on the Newer version of rule already on the system form.
- After the successful import, log-out.
- Log-in as Admin1@Booking.
- Notice, the default access group for Admin1@Booking is Booking 01.01.03. Booking 01.01.03 and it's ruleset versions are unlocked. This is your working environment. If you want to practice the configuration steps described in the remainder of this exercise, use this version of the application and it's unlocked rulesets to do so.
- Switch to the Booking 01.01.02 access group via Booking > Switch Application . The Booking 01.01.02 access group is using the Booking:01.01.02 application version and represents the basic configuration that you as an LSA would prepare prior to commencement of DCO.
- Switch to the Booking 01.01.04 access group via Booking > Switch Application . The Booking 01.01.04 access group is using the locked Booking:01.01.04 application version and represents the completed soution for this exercise. Booking 01.01.04 overrides your wotking copy and contains all the completed steps described in this exercise.
- By switching back and forth between the unlocked Booking 01.01.03 and Booking 01.01.04 access groups you can practice while comparing and contrasting your implementations of the configurations described in this exercises to the provided solution.
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.
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. A Event ruleset could be created prior to the BookEvent case type being created, its class and case type rule added to that Event ruleset.
Minimum Data Model to support an Event case type - Implementation
FSG-Data-Address
- Data structure is flat, can be stored in the CustomerData schema
- Key = pyGUID, Configure on the class rule
- Besides Street (text), City (text), State (text), PostalCode (text), and Country (text) properties, this class should possess a Reference (text) property
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 (integer) and Name (text).
- It would also reference a List of FSG-Data-Address instances.
FSG-Data-Pricing
- Properties would include ItemID (text), Price (decimal), PricingModel (text), Quantity (decimal), DiscountFactor (decimal), VolumePriceIncludesQty (a boolean property)
- Values for PricingModel include UNIT (text) and VOLUME (decimal)
- 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 (decimal), VolumePrice (decimal), and DiscountedPrice (decimal).
- 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 (text), StartDT (datetime), EndDT (datetime)
- Values for Category (text) include Concert, Convention, Corporate, Show, Sport
FSG-Booking-Work-BookEvent
- Certain case-level properties are needed as inputs to pricing calculations such as NumAttendees (integer) and DiscountPercentage (decimal)
- 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 (boolean) and EventManagerWG (page of Data-Admin-WorkGroup).
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 (datetime) and EndDT (datetime)
- A weather forecast has a central location, hence needs Latitude (decimal) and Longitude (decimal)
- A weather forecast returns a list of FSG-Data-Precipitation instance, each instance including a Date (date) and Probability (decimal), the Unit (text) for Probability being "Percent".
FSG-Data-Weather-Preparation
- Properties include RaincoatsProvided (boolean), TentsSetup (boolean), SeatingCovered (boolean) and WeatherCheckDate (datetime).
FSG-Booking-Work-WeatherPrep
- Case-level scalar properties should include PrepSLAGoal (datetime) and PrepSLADeadline (datetime).
- 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 BookEvent placing it in the Event ruleset.
- In the Data Model tab of the BookEvent case type, add a Field Group property named Event with the class set to FSG-Data-Event.
- In the Data Model tab of the BookEvent case type, add a Field Group property named Venue with the class set to FSG-Data-Venue.
- In the Data Model tab of the BookEvent case type, add single value 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 and place it in the Event ruleset.
- Add a Decimal property to the FSG-Booking-Data-PricingDisplay class named EventPriceand place it in the Event ruleset.
- Add a Field Group property named PricingDisplay to the BookEvent case type, set the class to FSG-Booking-Data-PricingDisplay, and place it in the Event ruleset.
- Create "EventManager1@Booking", "EventManager2@Booking", and "EventManager3@Booking" operator IDs for the test users with the role of Event Manager as defined in the Build Scenario. Then associate the three Event Managers with a workgroup named "EventManagement@FSG". Set the "EventManagement@FSG" workgroup manager to "EventManager1@Booking".
- To support routing Event cases to the EventManagement@FSG workgroup manager, add an EventManagerWG property to the BookEvent case type and place 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 CEOApproved (boolean) 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 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 class could be added to the data model in order to remove the redundancy present in the Venue and Hotel data classes. This will be discussed in more detail in the Data Model module.
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 SetWeatherCheckDate 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 BookEvent 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.
2 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 compare the completed solution for this exercise (Booking 01.01.04) with your working copy (Booking 01.01.03) to check your work.
3 Solution download
Booking_Lifecycle_Solution.zip
(2.43 MB)