Adding hotel as a built-on application

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. (Ensure the FSG-Booking-Int is removed from the Associated Classes section). 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.

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.

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.

The remedy is to create a new version of the sourced Report Definition to have it report on descendant class instances.

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 or 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.

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 of 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);

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.

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.

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.

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.

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.

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
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.