Changing class dynamically

Enterprise-level data classes can be referenced by Enterprise level Work- classes. Similarly, implementation-level data classes are normally referenced by implementation level Work- classes. Enterprise-level <Org>-Data- classes should also be able to be referenced by implementation level <Org>-<App>-Work cases. So how can an enterprise-level data class (i.e.: <Org>-Data-Warranty) be referenced by an implementation level <Org>-<App>-Work cases? Or how can an enterprise level Work- case reference an implementation level data class? The solution is to use Dynamic Class Referencing (DCR).

When a ClipboardPage is constructed multiple properties are initialized when a number of properties are instantiated by default that have a “px” prefix including pxObjClass. The “px” prefix connotes “should remain static” but does not necessarily mean “must remain static”. The values of some "px" properties should not be changed post-construction such as pxCreateDateTime and pxCreateOperator as they record historical information.

It is possible to its change the value of the pxObjClass property post-construction but care must be taken. An example of where pxObjClass is changed at run-time is when Assign-WorkBasket is changed to Assign-Worklist and vice-a-versa.

A ClipboardPage is a StringMap according to the Engine API. Suppose the value of pxObjClass for an existing ClipboardPage is changed to a more specialized class within the inheritance hierarchy, such as class that directly inherits from the existing class. This is not the same as constructing a ClipboardPage from the start using the original pxObjClass value.

The difference lies in the values that are initialized when the pyDefault Data Transform, if any, is called at the time of ClipboardPage construction. A pyDefault Data Transform can be configured to call its super (more generic) Data Transform. When case types are generated, the Call super data transform check-box option is set. When Data classes are created, this option is not set automatically.

A possible approach to the Call super data transform option post-construction initialization problem is to use an @baseclass WasPageInitialized ValueGroup property. Every pyDefault Data Transform within an inheritance hierarchy can be altered as follows.

Whether a Data class at the root of an inheritance hierarchy, e.g., Org-Data-Vehicle, calls its super Data Transform is optional.

The figures below are from the FSGGogoRoad and FSGEnt sample applications provided with this mission. FSGGogoRoad is built on the FSGEnt application, and the FSGEnt application is built on the FSG application. The FSGGogoRoad and FSGEnt applications are intended to mirror the relationship between the OOTB PegaSample and PegaRULES applications. The FSGEnt application is considered enterprise-level; while the FSGGogoRoad application is considered to be implementation-level.

The figures show eight pyDefault Data Transforms within the FSG-Examples-Data-Vehicle class hierarchy.

Note that a FSG-GogoRoad-Data-Vehicle pyDefault transform would not be called when the super Data Transforms are invoked. This is the reason for having step (3) above. As the pyDefault data transform change GogoRoad’s Motorcycle, Truck, and Car classes, each must apply a data transform with a different name such as DefaultGogoRoad in their step (3).

The first Field within the Identify Vehicle screen within an Assistance Request case establishes the vehicle’s Type, i.e., Car, Truck, or Motorcycle. On change, the Type field’s value is posted to the Server followed by a Section refresh where the TypeOnChange activity is called. The TypeOnChange activity passes the Type value as a parameter to the D_VehicleDCR Data Page. The D_VehicleDCR Data Page, in turn, invokes its LoadVehicleDCR data transform. This data transform is overridden by the FSGGogoRoad application as illustrated in the figure below. The TypeOnChange activity then sets the pxObjClass of the case’s FSG-Example-Work .Vehicle Field Group (Page) equal to the pxObjClass of the D_VehicleDCR Data Page.

The LoadVehicleDCR data transform does not need to be complex. A simple Decision Table could be used which could be modified as new Vehicle types are added.

Modifying the .Type property for the LoadVehicleDCR data transforms at both the enterprise and implementation application levels is as simple as appending the Type value to the root Vehicle Data class path.

Please import the product file below to check the extended data model designed with DCR.