Leveraging the template pattern for data instances
The template pattern is a commonly-used design pattern in object-oriented programming (OOP). The template pattern does not need to involve the use of an abstract class but typically does. In Pega, any rule that is non-final can be specialized by ruleset override regardless of being in the same applies to class or a derived applies to class.
An application can, for example, override the OpenDefaults Work- extension point and keep the applies-to class as Work-. The override occurs only when an application’s ruleset stack includes the ruleset that contains that OpenDefaults override.
The application more likely uses its work pool class as the applies to class or limits the override to a single case type.
The template pattern can be used in multiple situations, including managing how complex and enterprise-critical data instances are instantiated and updated.
Same-layer, CustomerData schema, and data type hierarchy
There are valid reasons to extend a data class within the same layer, the most important reason being "ownership." The Implementing an effective data model challenge discusses data type ownership, which includes schema packaging, according to the application that owns the ruleset that owns the data type class.
Within the provided Pega Certified Lead System Architect mission solution, the FSG COE team maintains ownership of two data type class hierarchies within the Enterprise layer, the base class of the following hierarchies:
- FSG-Data-Pricing
- FSG-Data-Location
Because Pricing is a component, the FSGPricingTest application exists not only to test that component but also to act as the hierarchy owner of the Pricing data type. The FSGPricingTest application must be installed to have access to this data type hierarchy. No other application should include pricing data types within its data type view and attempt to package those data types.
The Booking team, which builds its applications on the COE team's Enterprise layer, could potentially own a ParkingLocation data type that directly extends FSG-Data-Location, the same base class that the COE-owned FSG-Data-Venue and FSG-Data-Hotel classes extend. The COE Team could, instead, enforce that every class that directly extends FSG-Data-Location must be defined by the COE Team itself. In this way, the COE Team would own an FSG-Data-ParkingLocation class in parallel to the COE Team's Hotel and Venue Location-extending classes. By doing this, the COE Team maintains ownership of the entire Location data type hierarchy as defined at the Enterprise layer.
An application above the Enterprise layer is free to extend an Enterprise layer Data class for an application-specific purpose. If so, that application should strive to use the pattern-inheritance naming convention, not direct inheritance. In doing so, recognition is given to source of inheritance hierarchy, i.e., the Enterprise layer.
Also consider the FSG-Data-ParkingLocation-History class. Anticipating the need for this class, the FSG COE Team creates it within the FSG ruleset. Whether this class should be abstract or persisted to the CustomerData schema is questionable. The Parking application only needs to use the FSG-Data-ParkingLocation-History class to sum the total number of cars parked. The VehicleParking case that performs this sum uses that total to persist two FSG-Data-Pricing records, one for ItemID=NumParkedCars and one for ItemID=NumParkedCarsCost.
The CreateOrUpdateLocation templated flow
The FSG COE team has defined a templated screen flow to create or update an instance of any FSG-Data-Location derived class. The following image shows the Work- CreateOrUpdateLocation templated screen flow.
The following table shows the Template Pattern in action. A new and different class that extends FSG-Data-Location needs only to override the low-complexity rules on the right.
Rule Type |
Final Rules |
Extension Points |
Overrides |
Flow Action |
Work- SearchLocation Work- AddLocationInfo Work- ReviewSavedLocation |
|
|
Section |
Work- AddLocationInfo |
FSG-Data-Location AddInfo FSG-Data-Location AddNameAndOtherProp |
FSG-Data-Hotel AddNameAndOtherProp FSG-Data-Venue AddNameAndOtherProp FSG-Datat-ParkingLocation AddNameAndOtherProp |
Activity |
Work- SaveLocationAddress |
|
|
Data Transform |
Work- PreSearchLocation Work- PreAddLocationInfo Work- SaveLocation Work- PostReviewSavedLocation |
Work- InitLocation |
Overridden by the FSG-Booking-Work-BookEvent within the Production Booking application to set the VenueGUID property.
|
To enable higher-layer applications to use the CreateOrUpdateLocation screen flow, the FSG COE creates their own FSG COE portal that includes a COE Data Management UI page. The FSGCOE portal rule is applied-to FSG-UIPages. The Booking team includes this FSGCOE UI page within their Authors portal that they created for themselves.
The D_Location Lookup Data Page with Type Parameter
Normally, a Lookup data page with a single key, such as pyGUID, uses a single pyGUID parameter. The D_Location Data Page, however, has a second Type parameter. The D_Location data page sources a LoadLocationDCR activity that utilizes the Type parameter as follows:
When parameter Type !="" continue processing. Otherwise, jump to step GO.
Set param.ObjClassNew = "FSG-Data-" + param.Type
Call PageChangeClass passing the primary page as the primary page.
GO
Open an instance of FSG-Data-Location (Location) onto LocationTEMP
passing param.OpenClass as Primary.pxObjClass
using param,pyGUID the value for the class key, .pyGUID
Copy LocationTEMP to Primary
Remove LocationTEMP from memory
This parameter tells Pega to create a LocationTEMP page based on the value of Primary.pxObjClass after it was changed. Regardless of the derived class, Pega accesses the row in the Location database table that matches the supplied pyGUID. Pega does not just return the properties defined by FSG-Data-Location. Instead, Pega returns all of the properties in the Location table associated with the derived Location class. For example, if the value for the Type parameter is ParkingLocation (in addition to the properties applied to the FSG-Data-Location class), it also returns ParkingType (Lot or Garage) and Capacity.
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?