Changing class dynamically

Pega uses px, py, and pz as prefixes for its properties.

The px prefix generally means a property's value should remain the same once its value is set. Examples include pxCreateDateTime and pxCreateOperator which record historical information. Something can only be created once by whomever it was that created it.

When deciding what prefix to use for the property representing a rule's Apply-to class, Pega uses the px prefix. However, Pega changes the value of pxObjClass at runtime when Assign-WorkBasket is changed to Assign-Worklist and vice-a-versa.

The takeaway from this is that pxObjClass can be changed at runtime, but you must carefully perform that change. For example, you do not configure a decision table to alter the pxObjClass of its step page during the execution of that decision table. Instead, a decision table can return a class name value that is subsequently used to change the value of pxObjClass outside the Decision Table's execution.

Dynamic Class Referencing (DCR) is the term that has been used in Pega when the value for an object's pxObjClass is decided at runtime as opposed to design time. The term DCR is applicable whether the object whose pxObjClass is decided exists at the Enterprise layer or the Application layer.

Use DCR against a class with a clearly defined type instead of a class that does not, such as ORG, ORG-App, [*]-Data, and [*]-Work. Within the mission-provided solution code, there are two related sample applications: FSGSample and FSGSample2. Two similar case types are defined in each sample application: Roadside Assist and Service Complaint.

These four case types utilize and extend the same generic Data type: FSG-Sample-Data-Vehicle. The following image shows three specializations of *-Data-Vehicle within each layer, the specializations being -Car, -Truck, and -Motorcycle.

A common way to use DCR is to define an application-wide data type with a property for every value (for example, .MotorCycleClass).  A data page, typically named D_AppExtension, is defined within this application-wide data type. That Data Page sources a Data Transform to populate the data page's property values. A value is retrieved using syntax such as D_AppExtension.MotorCycleClass. Layers above the layer that defined the application-wide Data type would override that data transform from the AppExtension data page. Note that this approach does not adhere to the Open/Closed Principle. Whenever a new derived class is defined, a new property must be added to the AppExtension data type.

The modular way to use DCR within a class hierarchy is to define a DCR data page at the base of that class hierarchy. Within the provided solution, the FSG-Sample-Data-Vehicle class defines a D_VehicleDCR Data Page. This data page's sole purpose is to set its pxObjClass based on the value of the Data Page's required Type parameter. It does this by sourcing a data transform named LoadVehicleDCR. 

The code in FSGSample does not actually use D_VehicleDCR. The code can call the LoadVehicleDCR Data Transform directly. It does this within the Service Complaint case’s Create stage. The FSG-Sample-Data-Vehicle IdentifyVehicle Section has an autocomplete control that sets the Vehicle's .Type property. On change, the section is refreshed. Before the refresh, the LoadVehicleDCR Data Transform is invoked. The .Type property supplies the value for the Type parameter.

The primary goal of the two Vehicle sample cases is to show that the polymorphic classes defined in two different layers can be persisted and recovered from the same CustomerData schema database table —a table that lacks pzInsKey and pxObjClass columns.

Something potentially important within a two-layer class hierarchy is the root class's initialization with the second or higher layers. Data transforms will recursively call data transforms using the pattern-inheritance path first, if that is how the class is configured, followed by using the directly-inheritance path, so on and so forth.

When executing the pyDefault data transform for a higher layer specialized class such as FSG-Sample2-Data-Vehicle-Car, if a pyDefault Data Transform exists in FSG-Sample2-Data-Vehicle, that transform will be executed before the pyDefault transform in FSG-Sample2-Data-Vehicle-Car. This makes perfect sense.

Note that the Page-Change-Class activity method has a keep parameter. Ignoring the more complex third option with the value of 2, the remaining keep parameter values are:

• 0  = the value of any property already present remains the same
• 1 = the value of any property already present will be overwritten by the data transform

When the class of an instance is changed multiple times, would that instance be identical to an instance whose classwas only changed once, the final class being the same for both instances? 

if a certain specialized class, say -Car, were to override a property value set in FSG-Sample2-Data-Vehicle that property would not be restored if keep = 0 is used.

But is keep = 1 the correct solution either?  Suppose an inherited FSG-Sample2-Data-Vehicle property has been set, Using keep =1 could cause that property's value to be reset resulting in information loss.