web analytics

Before starting, I hope all of us are aware of the famous giant food ordering app swiggy. Let’s have a look at one of its screen below.

Have you ever observed that whenever you change the quantity of your order, the bill amount gets updated automatically?

Let’s dig more into this, here the bill amount listens for the quantity of the order and therefore whenever the quantity is changed the bill also gets updated. This is what we call as Declarative Network.  

Declare rules are one of the cool features in Pega PRPC. When you define any declare rule the configurations starts get executed automatically, eliminating the need of calling explicitly, whenever the conditions defined in the declare rule are satisfied.

The following list identifies advantages and disadvantages of using declare rules in an application:

Advantages

a. Gets triggered automatically and therefore eliminating the need to call implicitly from anywhere in the code.

b. Can be delegated to business users to make changes in production environment.

Disadvantages

a. Declare rules create a declarative network like a kind of chain link. For example let’s say property A has declare rule on which property B value is computed, which inturn have a declare rule and so on. One has to be very careful while defining these in an application and not to create an infinite loop resulting in this type of scenario’s.

b. Declare rules need to be considered only when the processing needs to happen only in one or two scenario’s. As said in point #1, these rules create a declarative network, so if declare rules gets executed frequently, there will be a performance impact within the application with lots of computations involved.

Pega provides five types of declare rules

1. Constraints

    a. Used to define conditions on properties so that whenever the property value is changed, it’s value will be validated against the defined conditions in the rule. This eliminates the need of calling validations explicitly whenever the property value is changed

2. Declare expression

    a. Provides the functional relationship between properties. Let’s take example of the swiggy order discussed in the starting of this article. Once you define declare expression on the Total Amount property with source as Quantity, whenever the quantity is changed, the Total Amount property will gets changed accordingly therefore establishing functional relationship between the properties.

3. Declare trigger

    a. Provides the ability to run an activity whenever the specified work object instance is updated.

4. Declare onChange

    a. Provides the ability to run an activity whenever the specified property values are changed.

5. Declare index

    a. Provides the ability to expose and store the embedded properties.

The difference between Declare trigger and onChange is, declare trigger runs the activity whenever the workobject instance is updated whereas declare onChange runs the activity only when selected properties are updated.

For easiness we are going to discuss about Constraint and Declare trigger rule in this article. I will cover the remaining topics in the upcoming post.

1) Constraints

When the criteria defined in the rule is met, the validations starts getting triggered and error message will be shown if validation fails.

One of the use case for declare constraint will be as below.

Let’s say there is a property holding the pincode value. The pincode format should be unique throughout all the places wherever the property is being updated. If we define constraint rule on this, whenever it’s value is getting updated, the format will be checked automatically eliminating the need of calling validation rule explicitly.

In our scenario we are going to create a constraint rule which checks the value for the contact number property when the contact type is provided in the below screen.

Let’s jump into the creation and configuration details. 

      a. Creating constraint rule

The below details need to be given :

Label : Name for the constraint rule.

Identifier : Unique identifier for the constraint rule.

Class :  Class to which the constraint rule applies

Ruleset : Ruleset details like name and version.

      b. Configuring the constraint rule

Constraints

I hope everything in this screen is self-explanatory. Please feel free to let me know in the comments if you feel any difficulty.

Pages & Classes

Pages & Classes

If we are using any properties referred from a page we can define the respective page here.

Page context data

If we are defining constraint rule for the top level page properties, leave this empty.

If we are defining the constraint rules for any embedded properties, the respective embedded property and it’s page class need to be configured here.

 For example, think of multiple contacts, like home, work etc., the properties contact number, contact type will be part of ContactsList property. Then the properties contact number, contact type will be defined in the Constraints tab and the ContactsList property and it’s page class should be defined under Pages & Classes tab to provide the proper context.

      c.Testing the constraint rule

I am selecting the contact type and keeping the contact number empty. After submitting the details, the configured message in the constraint rule will be appeared as error message in the screen.

      2) Declare trigger

Allows you to run an activity whenever the defined class instance is saved/commited to DB.

One of the use case for declare trigger will be as below.

Let’s say you need to track the case updates, i.e., whenever a case is updated we need to capture the time, operator id etc., and need to send to an external system for doing analytics on the case processing related things. This can be achieved by configuring a declare trigger for the case type and calling an activity which is used to send the details to the external system.

 Let’s take the above use case and jump into the creation, configuration details.

      a. Creating trigger rule

The below details need to be given :

Label : Name for the declare trigger rule.

Identifier : Unique identifier for the declare trigger rule.

Class :  Class of the case type, on which once save/commit happens, the activity need be triggered.

Ruleset : Ruleset details like name and version.

b. Configuring the trigger rule

Triggers

Trigger when an instance is 

      · Deleted – Gets triggered when the work object of the class gets deleted.

      · Saved – Gets triggered when the work object of the class gets saved.

      · Committed Save – Gets triggered when the work object of the class is saved and committed

      · Committed Delete – Gets triggered when the work object of the class is deleted and committed.

      · Saved and… – Gets triggered when the work object is saved and also if the mentioned property values are changed (better version to Saved ).

      Note : The properties details will be visible only for the type Saved and …

Condition

Serves as an extra step to define conditions other than in above step. The trigger rule gets executed only if the result of the when condition is true. For now I am keeping this empty.

Trigger activity

Name : Activity name that needs to be executed.

Execute : Select a value to determine how the activity runs:

    • Immediately — Runs the activity immediately on execution of this rule.
    • In Background on Copy — The activity executes in a new requestor, outside of the main context. The activity should include a Commit method. (This activity cannot use Obj-Save with Write Now checked, but can use all other methods.

    Pages & Classes

    Pages & Classes

    If we are using any properties referred from a page we can define the respective page here.

    Page context data

    If we are defining the top level page properties under triggers tab, leave this empty.

    If we are defining any pagelist properties under triggers tab, the respective pagelist property and it’s page class need to be configured here.

    For example, think of multiple contacts, like home, work etc., the properties contact number, contact type will be part of ContactsList property then the properties contact number, contact type will be defined under triggers tab and the ContactsList property and it’s page class should be defined under Pages & Classes tab to provide the proper context.

     I configured as per below image. For now I created a dummy activity where I am setting some properties for testing purpose.

    c. Testing the trigger rule

    I am going to create a case and on submitting the data, the case gets committed and therefore the rule gets triggered.

    That’s it folks!!! We reached the rest stop before reaching to our destination of the entire discussion. We will resume our journey soon, till then stay tuned 🙂

    Hope you got enough information about the discussed declare rules. Please feel free to comment in case of any doubts.

    Happy learning!!!

    Author - Satish Segu

    A passionate and self teaching programmer with lots of love for Android programming. Currently being working as PEGA Developer and posses kowledge in a variety of areas starting from Case Management, Agents, Security, BIX etc., Connect with me through below links.

    Happy Learning!!!


    Leave a Reply

    Your email address will not be published. Required fields are marked *