Dynamic Referencing and Dynamic Class Referencing (DCR) in Pega

In this blog article, we will talk about dynamic referencing and dynamic class referencing in Pega.

Let’s start with the term  – Pega –  build for change

What is build for change?!

Think of different ports available in a Television

• HDMI port,
• USB port,
• A port for cable connection,
• A port for dish connection,
• Cables to connect DVD player or to use Playstation ( FIFA 18 😀 )

We can reuse the TV in multiple ways!! . We can call it as built for change.

Re-usability and build for change are interchangeable.

Now let’s come to our Pega, Whenever you start building an Pega application, always have this is mind – Build for change.

Build it for future changes. Figure out all the configuration points and make it dynamic.

What is Dynamic referencing?

Dynamically reference values in the application. I will walk you with an example

Let’s say a Pega application supports Sales and Service cases in an organization.

Both the case contains an approval process.

All the steps in the approval process are same, except that the case has to be routed to either SalesWB or ServiceWB.

I give you two approaches to decide which is the best

Approach 1:  Create 2 separate approval process for Sales and Service

Sales – Route it to Sales WB

Service – Route it to Service WB

Approach 2: Create a single approval flow in the parent layer

and dynamically pass the Approval WB Name

The reasons, why Approach 2 is best?

– In future, the same approval process can be applied for other cases with the change in Workbasket name. Say there is a new case – ‘Marketing’ and the approval should routed to ‘’MarketingWB”. Here you can use the same flow by dynamically varying the workbasket name.

– Lesser number of rules and easy to maintain.

Now, how to set the workbasket name dynamically?! – We will see about in details shortly.

What is dynamic class referencing?

Dynamically refer the classes – also called ‘DCR‘

Why do we use DCR?

When you are in Framework layer and you want to make use of Implementation layer classes.

For example, You have an activity in framework layer.  You want to open a case from that activity. We  use Obj-Open method to open the case.

When you try using an Implementation class, you will end with the error

<Class name> does not exist or is not a valid entry for this ruleset and its prerequisites.

Note: You can also create a Implementation work type from Framework layer by making use of DCR.

These are the ideal use cases for DCR.

Never hardcode the class values in activities or other rules.

This is because, Every application should adapt to changes.

Say for example You have any existing class and want to rename. So if you have hardcoded the class name, then the developer has to scratch his head to find all the referencing rules.

If you use DCR here, then you can change the class name at once place and if reflects in all the referencing rules.

How to configure DCR in an application?

There are two things you have to identify.

a) How to store the dynamically referenced variables?

b) Where to use these dynamically referenced variables in the application?

We will go one by one.

How to store the values dynamically? 

This is how we implement DCR

There are 4 rule types, we need to make use of.

a) Data layer ( This can be in the organizational or framework level)

b) Properties – Holds the dynamically referenced values.

c) Data Page – Load the variables

d) Data transform – Source for the data page. ( This can also be replaced by activity for complex computation)

Here we will see, how we can extend our application for dynamic referencing.

Step 1: Create a new data class extending framework.

Update: In the latest Pega versions, you can create this on your App Data layer directly or under an reusable data layer.

I name it as “AppExtension”.

Step 2: Create  properties

A Page property –  holds all the dynamically referenced values – AppExtension

I created this property in ‘Work’ class and can be reused in all work cases.

I used ‘Refer to a data page’, because this may change based on the application we are in.

We will see very shortly, how this same property loads different data based on different application.

 Single value properties in data class –  First let me create an property to hold Purchase Order class.

Step 3: Create a new data transform to set the value.

First, you can have an data transform in reusable layer.

You can also create a ruleset specialized version  in the implementation application, and override these values from framework.

Note: When you need some complex business logic, you can make use of activity in place of data transform.

Step 4: Create a new data page.

I named it as “D_AppExtension”

Data page definition will be

Structure – Page. This is going to be a single page structure

Object Type – Refer the AppExtension data class

Edit mode – Read Only. No need to edit the values

Scope – Thread. Since we are extending this on application level.

Note: In some scenario, you may need to extend the Organization level configuration points. Eg – Org Int end point URLs. I such scenario, You can make of the data page throughout the organization. Scope can be node/requestor level.

Data Source – Use data transform and specify the newly created data transform name.

Now all our rules are ready

Whenever you create a data page, It’s always nice to run and test the data page.

Let’s check it. Run the data page from Other actions.

You can see the PurchaseOrderClass is populated from the data page.

Now we have successfully configured DCR in our application.

We will see, How we can make use of DCR functionality in application

Step 1: Open any activity in Framework layer. (I am using the same activity, I used in Introduction part)

Step 2: In the Obj-Open step, replace the Open class hard coded value with the dynamically referred AppExtension.PurchaseOrderClass value.

Now, You can save the activity and at run time the class name is passed dynamically.

Note: Data pages are used to render the values dynamically at runtime, when required.

What are the places, we commonly use Dynamic referencing?

The below examples are just a piece out of the cake.

a) In a flow shape, where we can refer values dynamically – Worklist or Workbasket.

You can also find other shapes, which can accept the dynamically referenced values.

b) Connectors – End point URL

Just for learning, go through the below content first!! At the end, I will also share how to refer the URL directly using Pega OOTB data page referencing.

Legacy option

Remember, Connector end point URLs tend to change based on the environment. We may have the actual URL only in production system. In the lower environments, we may have different URLs for Dev / QA.

Integration connectors can be used across organization. I recommend you to create a separate Organization data layer. You can create the below rules.

1. Organization Int class – BBB-Int-EnvSettings.

2. Create separate properties for separate URLs you use ( page property not required).

For example, In your application you can have multiple connectors for multiple functionalities. You can create individual properties to hold the URL values – FetchPolicyURL.

3. Create a node / requestor level data page – D_EnvSettings

4. Create either Dynamic system settings or System settings to hold the URL values.

My next post will be on System settings and DSS.

5. Create a data transform to set the values from DSS to URL properties.

Now you can refer the fetch policy details URL dynamically loaded from the data page.

Note: Please follow the same steps, how we configured before

D_EnvSettings.FetchPolicyURL – contains the URL value

You can see an Equal to sign (=) before referring the resource path.

This is because, resource field always expects an constant value (Inbuilt Pega code). It may interpret the values you provide as a constant, unless you provide an equal sign before.

A simple trick is, whenever you see drop down select value field, you can directly refer without equal sign. This can be identified by a blue triangle at the right bottom.

If you don’t see this blue triangle in any input field, then

You can use any constant values or

You may be forced to use an equal sign before you refer any value dynamically.

Recommended action

Instead of creating your own data page for dynamic referencing the URLs, you can use Pega OOTB data page – D_pxGetApplicationSettingValue

D_pxGetApplicationSettingValue[OwningRuleset:”<rulesetname>”,Purpose:”<AppSetting Name> “].pySettingValue

This data page can retrieve the value of App settings.

Of course you can configure the endpoint URLs in the Application settings configuration.

c)  Activity steps – Obj methods.

Apart from these places, You can refer the values dynamically in many places in the application.

What are the points to remember?

– It’s always nice to have data pages to hold the dynamically referenced values

D_AppExtension – Application related values

D_pxGetApplicationSettingValue – Environment related values ( URLS )

– Try maximizing the reusability features by incorporating the DCR functionality.

– Using DCR, you can initiate Implementation work types from framework layer.

– You can always extend the framework by copying the data page source data transform to application specific rulesets.

– Try to bring all the classes and Organization specific rules like – Workbasket, Workgroup inside the data page. This can be extensively used to route work dynamically.

We are at the end of this article.