Posts

No Check-in with Pega Warnings

Image
Prevention is better than cure. One of the main pain points of any Pega project is the gradual accumulation of technical debt . This buildup can be clearly seen by the declining compliance score. One of the ways to mitigate technical debt is to have a keen eye on code smells  and refactor regularly. To identify code smells Pega has a static code analysis mechanism called Pega Warnings. Even though the best practice is to fix (or occasionally justify) the warnings as soon as they appear, the best practice is not always followed and rules are checked-in with unattended warnings consequently increasing the overall technical debt of the system. What if there is a way to stop the check-in process if a rule has unattended warnings. Following simple change will halt the check-in process if a developer tries to check-in with unjustified warnings. From my practical experience I can say that this small change will have a huge impact on the overall quality of the code.

Managing Configuration Data in Pega Rules

Identifying and incorporating configuration data into a rule base is one of the design best practices in PRPC development. PRPC has several out of the box features where users can create and manage configuration data with less effort and minimum steps. Configuration data in PRPC can be classified into three different domains mainly based on the actor who configures. The k ey to good design is identifying the best feature, for a given requirement with the actor in mind.   Following table lists down all three actors and supported PRPC features with examples. Actor PRPC Feature Environment Examples Business User Data Table Decision rules that support rule delegation e.g. Map Value Production Limit Approval values for Managers System Administrator

Beauty of Higher Order Functions

If you are familiar with JavaScript you must have come across the usage of Higher Order Functions. Simply put higher order functions can accept functions as parameters or can return function as a result. When you understand the basics, it's joy to work with them. Due to the elegant design of PRPC runtime, we can easily simulate higher order functions using activities. Following activity is a good example of such a scenario. Code-Pega-List.ProcessSelection So next time when you find a problem see if you can solve it using higher order functions. If properly used your code will be more modular and look very professional.

Clipboard Page Analyzer

Image
Have you seen a colored clipboard like this before, probably not right, please read to find out how and more importantly why it looks as it is.

Importance of Sandbox ruleset

One of the major problems that Pega projects face with time is build up of test rules within the official business rulesets. If not properly managed these rules could end up in the production environment which is not an ideal situation to have. But can we really stop creating test rules, for me the answer is no, because creating test rules is also an integral part of the iterative development process. So how can we maintain a clean development environment while also allowing the creation of test rules. The answer is the Sandbox ruleset . By creating a separate ruleset only for test rules it is possible to have a clean development environment while allowing the creation of test rules in development process. Following are the steps that have to be followed Create a sandbox ruleset and version Update ruleset restrictions in classes to include the sandbox ruleset Create a separate sandbox application rule and include the sandbox ruleset and put your main application as t

Creating custom rules in PRPC

Image
You can find the first part of this post from here What do you think one of the frequently asked question in PDN forum, any guesses?, it's about Excel integration with PRPC, but ironically by the time of this writing PRPC still does not support a rule based approach to the problem of Excel integration. So are we in a dead-end, frankly not. Due to the elegant design of PRPC, we can create our own custom rule to accomplish the task.   Welcome to the second post of the series "Creating custom rules in PRPC", as I pointed out in the first post, in this post I am planning to systematically lay down the steps that need to be taken in order to create a custom rule. Word of caution: Most of the things I am writing here are, what I called observable knowledge, meaning - understanding how something works literally by observing the system and in case of PRPC reading the rules in the system without going through a formal How-To docume

Creating custom rules in PRPC – Introduction

Image
Pega Rules Process Commander is such a wonderful product. It is built so elegantly with layer upon layer of abstraction so that a normal business user can easily change the runtime behavior in order to adjust to the changing business conditions without going through a typical development cycle. At the same time it is a mixture of J2EE technologies, bunch of browser based thin client technologies and more importantly a wonderful design that has the unique feature of "ability to be extended in multiple layers", where a person could not distinguish whether a feature is out of the box or custom made. All these are possible due to the initial wonderful design of PRPC. One of the best things that the designers of PRPC have done is, even though there are multiple layers of abstraction, they have given us, the end developers a chance to extend the core product through custom rule creation. Before creating custom rules first let's get a clear understanding to the question &quo