Skip to main content

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.

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

Did you find this content helpful?

100% found this content useful

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice