Why you should know about Dynamic Class Reference (DCR) in Pega
For example, a sales company has one framework layer and multiple implementation layers and want to reuse their assets from framework layer. Consider an activity in framework layer that do Obj-Open in one of its step.
As the class name is hard coded with framework class, this activity can't be reused directly from the implementation class, instead this activity should be copied in to all the implementation layers to change it to implementation class name. With this potential problem, lot of assets and rules has to be copied from framework layer to every implementation layer. Pega has provided a design pattern called Dynamic Class Referencing (DCR) to overcome this situation.
What is DCR
Dynamic Class Referencing (DCR) is a design pattern that enables you to avoid hard-coding of class names, flow names, and workbasket names.
How to configure DCR
Step 1: Create a Data Class
When configuring a DCR, it is often advisable to create a data class to house the properties used as the dynamic reference variables. That way it is easy to get an overview of the extension points that need to be configured when extending the framework. Generally the class name "AppExtension” is suggested to create the data class that stores the dynamic reference variables.
Create single value properties in the Data class to store the class names like "ClaimsClass", "InsuranceClass" etc.
Create page property in Framework work class
Create a page property in the framework’s class group. So, this property is then available to all application layers.
This property points to the data page to hold the values.
Create Data transform to hold the reference values
The Datapage D_AppExtension should be configured with a Data Transform as the source.
This Data transform will be in the frame work class and initializes the data class variables with the required reference values.
So now, if you refer D_AppExtension.ClaimWorkClass , it refers to the class name "ABC-CS-Work-Claim" as per this example.
How to use DCR
In the Activities or other rule forms, wherever it is required to hardcode the class names, use the Data class Appextension property rather than hardcoing the class name.
The Data transform is required to override at every application and update with the implementation class names. As the data page is thread level, the data page will be created for each application and it dynamically refers to the implementation class names.
Thus, there is no need to overrides any of the rules in the implementation layer just to change their class names.
Other use cases of DCR:
DCR is not meant only to define the class names, we can use any where in the application, where we want to dynamically the change the name based on the application.
Work List and Work Basket Names
One of the use case is, while we configure the routing, generally we hardcode the work list names and work basket names. Instead, if we refer with the help of DCR properties, then the same routing logic can be used across any implementation application.
To set threshold values
In some applications, we want to set the threshold value to some integer and we expect implementation team to change its value based on their requirement. In these kind of use cases, rather than hard coding the threshold values in a Data Transform or activity, we can simply use the DCR properties to hold this value. The DCR data transform can be overridden in implementation to update its value. Thus, we can eliminate the overriding the logical layer into implementation.
To Update system settings
In some applications, we have some system settings like language, prefix or integration server names or urls. This might change for implementation applications. In these kind of scenarios it is advisable to refer to DCR properties rather than hardcoding in the Connector Rules or Activities.
As over all, the DCR adds more re-usability to the application and reduces the complexity of the application. It is advisable to use DCR in any Customer's applicatoion.
You may also want to see: