Leveraging the template pattern for data instances

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

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.

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.