Extension Points in PEGA Platform – Part 1

Before getting into a technical discussion, let us understand what an extension point in PEGA is !!! 😳

Let us derive the actual purpose from the word “Extension Points“, it’s a point (any OOTB rules in most cases “Activity“) that can be extended to meet our application needs.

• Extension points are placeholders/stub rules in PEGA which are intended to be overridden in our application layer to meet our business needs.
• Most of the API rules in PEGA have extension points to satisfy application-specific needs.

Extension point before specialization

Extension point after specializing in application ruleset

Things to consider while specializing extension points in our layer

• Make sure the rule is specialized in the appropriate class and ruleset of the application.
• Make sure the class and ruleset of specialized rules are accessible during rule resolution.

pyDefault/pySetFieldDefaults

pyDefault/pySetFieldDefaults are rule types of class “Rule-Obj-Model“. As the name suggests, they are extension points provided by PEGA to pre-populate case-specific fields before a new case gets created in the system.

pyDefault

• pyDefault can be used to set OOTB properties that are specific to a case. Some of the examples are, “pyWorkIDPrefix” to set the Work object ID prefix, “pyStatusWork” to set the Work object status, “pySLAName” to set the Overall SLA for the case.
• pyDefault gets invoked from “pyStartCase” flow rule which is the default starting process of all case types.
• pyDefault data transform will always be enabled to call its superclass data transforms. At run time, pyDefault execution of loan case will follow below order:
  @baseclass -> Work- ->Work-Cover- -> Loan Work class
• During a case life cycle design, pyDefault data transform will be automatically made available by the system in the corresponding case type class when we configure a view for the case type.

pySetFieldDefaults

• pySetFieldDefaults can be used to set custom properties/fields or to initialize aggregate properties in a case.
• pySetFieldDefaults gets invoked from “pyDefault” data transform.
• pySetFieldDefaults data transform will always be enabled to call its superclass data transforms. At run time pySetFieldDefaults execution of loan case will follow below order:
  @baseclass -> Loan Work class
• When pyDefault data transform is manually specialized in case type class, then pySetFieldDefaults data transform should be explicitly called from the same. When the system specializes pyDefault data transform in case type class while configuring view, then the system invokes pySetFieldDefaults data transform by itself.

Business Scenario

Let us consider an application built for loan processing.

Whenever a loan request is initiated, System should set “Initial work urgency” of the case to 20 and “Loan processing Deadline Date” to current date + 10 calendar days.

Implementation

• pxUrgencyWorkClass is the OOTB property used to hold the Initial work urgency of the case and it can be updated by using pyDefault data transform specialized in loan work class.
• LoanProcessingDeadline is the custom property that keeps track of the loan processing deadline date. This can be updated by using pySetFieldDefaults data transform specialized in loan work class.

NewDefaults

NewDefaults is a rule type of class “Rule-Obj-Activity“. As the name suggests, it’s an extension point provided by PEGA to plugin logic before a new case/assignment gets created. NewDefaults is available as an extension point in Work– and Assign– classes.

• Work-.NewDefaults: It gets executed before a new case gets created. This can be used to set case level properties. “CreateWorkPage” API invokes the activity “Work-.NewDefaults”.
  
• Assign-.NewDefaults: It gets executed before a new assignment gets created. This can be used to set assignment level properties. “Work-.NewAssign” and “Work-.NewAssignBasket” APIs invokes the activity “Assign-.NewDefaults”.

Business Scenario

Whenever a loan case is initiated, the loan department head office should be notified of the initiation of the loan case.

Implementation

The above scenario can be implemented by specializing NewDefaults in the loan’s Work class with logic to send email notification on loan case initiation.

Work-.NewDefaults is specialized in this example and Assign-.NewDefaults specialization is left for exploration.

Things to know when using NewDefaults

• NewDefaults gets invoked irrespective of the “skip create harness” configuration in case type.
• NewDefaults gets invoked when a case is created through service using “svcAddWorkObject” API.

ValidateNew/OnAdd

• ValidateNew is a rule type of class “Rule-Obj-Activity“. As the name suggests, it’s an extension point provided by PEGA to validate the information before a new case gets committed to the database. ValidateNew is invoked from “AddWork” API.
• ValidateNew invokes OnAdd validate rule which is also an extension point provided by PEGA. OnAdd is a rule type of class “Rule-Obj-Validate“.
• ValidateNew & OnAdd are available as extension points in Work– class.

Business Scenario

Whenever a loan case is initiated, the customer details entered in the New harness should be validated with the below business logic:

• Customer First Name: Only Alphabets
• Customer Last Name: Only Alphabets
• Customer Age: Should be 18+ [Customer Age will be a calculated field based on the Date of birth entered]

Implementation

The above requirement can be implemented by specializing ValidateNew/OnAdd in the loan’s Work class. OnAdd specialization is used for implementation.

Things to know when using ValidateNew/OnAdd

• OnAdd Validate rule can be used for simple validation of properties whereas ValidateNew activity can be used to implement complex logic that cannot be achieved using validate rule.
• ValidateNew/OnAdd gets invoked irrespective of the “skip create harness” configuration in case type.
• ValidateNew/OnAdd gets invoked when a case is created through service using API “svcAddWorkObject“. In such a scenario, ValidateNew can be used to validate the incoming request.

OpenDefaults

• OpenDefaults is a rule type of class “Rule-Obj-Activity“. As the name suggests, it’s an extension point provided by PEGA to plugin logic whenever an assignment in the work item is opened from the Case Worker/Manager portal. OpenDefaults are invoked from the “Open” API.
• OpenDefaults gets invoked when a work object is configured to open from a custom link or button using actions like “Open Work by Handle“, “Open Work Item” or “Open Selected Item“.
• OpenDefaults is available as an extension point in Work– and Rule– classes.

Business Scenario

Whenever a loan case is opened from UI, customer information should be populated as mentioned below,

• Customer First Name: Value entered during the case creation
• Customer Last Name: Value entered during the case creation
• Customer Mobile Number: Should be fetched from the external system
• Customer Primary Email: Should be fetched from the external system

Implementation

The above requirement can be implemented by specializing OpenDefaults in loan’s Work class with logic to fetch customer mobile number and primary email from an external system. This ensures that the system always displays the updated values of the Customer’s mobile number and email id.

PerformDefaults

• PerformDefaults is a rule type of class “Rule-Obj-Activity“. As the name suggests, it’s an extension point provided by PEGA to plugin logic before an assignment is performed. PerformDefaults get invoked from the “Perform” API.
• PerformDefaults is available as an extension point in Work– class.

Business Scenario

Whenever an assignment in loan case is performed, a custom audit should be recorded with the below information:

• Assignment name that is performed.
• Loan case ID that holds the assignment.
• Operator name who has performed the assignment.

Implementation

Work-.PerformDefaults can be specialized in loan work class to record audit with all the required information. Audit gets recorded for each and every assignment performed in a loan case though the code is at one single place.

Things to know when using PerformDefaults

• PerformDefaults will be invoked when a work item is opened from Worklist or Workbasket in Perform harness or when the “Begin” button is clicked from the review harness of the case.
• The above scenario can also be implemented by using Pre/post-processing DataTransform or Activity in flow-action. But the difference is, when using PerformDefaults, code will get executed for all the assignments that get performed.

Now that we have got some basic understanding of extension points, when & how to specialize them for application-specific requirements; let’s explore more on extension points in our continuation post [Part 2].

Part 2 will cover the following extension points.

• Work-.ReopenDefaults
• Work-.ReassignDefaults
• Work-.ReassigntoWorkbasketDefaults
• Work-.CloseDefaults

Stay tuned for part 2 😎