PRPC Developer

No Check-in with Pega Warnings

2018-10-15T08:25:00.000+05:30

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

2014-03-15T13:39:00.000+05:30

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 key 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	Dynamic System Settings Data Table	All environments	Web service end point URLs on each environment Web Service Security user credentials on each environment Performance alert settings
Developer	Dynamic System Settings Data Transform Map Value Data Table Hierarchy	Development	Implementation layer class names Any constant value in the code

Above three scenarios can be described as follows.

Authorized business users should be able to change runtime process level values so that certain changing business needs can be easily managed without waiting for a full development cycle.

System administrators should be able to manage values specific to inter system communications, system security, etc.., which are key components in the smooth operation of runtime environments.

Finally, developers should incorporate configuration aware rules and data instances into the overall design so that fellow developers will find it easy to modify existing functionalities with minimum rule changes.

If all are considered well in the design, the end result is a system with utmost flexibility, where a change is easy to handle and less prone to break the rest of the functionalities.

Please leave a comment with your practical experiences on how you have used configuration data in your projects. Thank you.

Beauty of Higher Order Functions

2013-01-13T18:21:00.000+05:30

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

2012-12-09T04:16:00.000+05:30

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.

We love creating Pages, especially finding good names for them. Within Pega Rules Process Commander (PRPC) pages play a very critical role as a highly flexible data structure that offer application developers the ability to abstract the underlying business data model.

But with all this glamor, “named” pages hold one dark secret, once created they have to be manually deleted through the code. Which means you have to track most of the pages that system create for you (Obj-Browse, Obj-Open) and all of the pages that you create (Page-New), so that you can remove those pages at the correct moment within the business process after they are no longer needed. If not this can lead to significant performance issues as every page in the clipboard occupies memory.

This being a design feature in PRPC, Pega has given couple of ways to delete named pages. Widely used Page-Remove activity method is the easiest and by far the best way to delete named pages, but if you are writing Java then removeFromClipboard Pega Java API method can be used to achieve the same outcome.

Everything is working perfectly up to this point, there are ways to create pages and ways to delete pages. But there is a problem, since we are doing these tasks as humans, even though it is a good development practice to remove pages whenever not needed, sometimes we tend to find the best practice is not being followed, resulting a cluttered clipboard.

So what if there is a way to find out pages that were created but not deleted within two different points in an execution flow that you have selected. Which brings us to the beginning of this post the colored clipboard. Yes you guessed it correctly, those colored pages indicate exactly that. Those are pages that were created but not deleted within a user specified two points in an execution flow. I like to call this the Clipboard Page Analyzer.

So you know the problem and you have seen an answer, let’s see how to implement this.

Let’s start with an example, Imagine you have a process with 3 flow actions (FA) and you are creating two pages called A and B within the boundary of these 3 flow actions. According to the technical design correct life span of these two page should be as follows.

Page A – Initialized within FA1 and removed within FA2

Page B – Initialized within FA1 and removed within FA1

Following diagram shows the correct representation of that.

Now for a moment let’s analyze the following diagram which is an incorrect implementation of the technical design

So as you can see if you examine the clipboard after the FA1 you will find Page A and B both on the clipboard, but according to the design only Page A should be present, which means the developer has not removed Page B at the correct moment within the process. Something similar can be seen if you examine the clipboard after FA2, where you will see both the pages present but according to the design none should be there.

So how do we track these clipboard page creation and deletion moments. It turns out to be that we do not have to track, there is a neat trick that can be used to get the delta of pages within two different points in time.

If you examine the PRPC Java API you will find a method called getPageNames in PageDirectory interface.

Once you have this method it is matter of invoking this method at two points in time and find the delta. So with this in mind and after some client side coding following is what you get. (Please see the video in YouTube directly with HD full screen for better quality).

Clipboard Page Analyzer

Importance of Sandbox ruleset

2012-04-29T17:51:00.000+05:30

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 the Built on Application
Create a sandbox access group and include the sandbox application
Include the sandbox access group as an optional entry in the operator access group list

Now you will get the sandbox application as an optional application rule when you log in as a developer. So next time when you want to create a test rule, switch the application to the sandbox application and use the sandbox rule set to save your test rule.

If your team is not used to this process, it will take some time for them to adjust to this new way of working, but with time you will see better results.

Creating custom rules in PRPC

2012-02-23T04:55:00.000+05:30

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 documentation, reason being we do not have such documentation, this is the only article I was able to find in PDN regarding custom rule creation. According to the PDN there had been some documents, but not anymore. Search for the lost pearls didn't go well either:). So if you feel that I have missed something please feel free to correct it by leaving a comment.

Let's start with a question - Why do we need to create a custom rule ? - To impresses our colleagues, while that could be a possible reason, we will be able to find a better answer if we look at the definition of the custom rule again.

Custom rule is a rule which describes a process / execution pattern which does not available as out of the box rule in PRPC

One of the the key phrases with in the definition is "which does not available as out of the box rule in PRPC". So we should never create a custom rule if we can find something alternative with in PRPC as an OOTB feature.

Following list explains what needs to be done to plan and finally implement a custom rule

Plan and Design
Create rule class and properties
Create a rule form
Create a model rule in the rule class
Create a validation activity
Create a custom warning activity
Create the activity which does the actual rule logic
Map the custom rule to a new table cloning pr4_rule table

I will explain each step by giving reference to the Connect-Excel rule, please try to relate these steps to a common rule you are familiar with and try to see how Pega has done the same steps with reference to the rule you are examining.

Plan and Design

One of the most important step that has to be done before doing anything is to plan and design the custom rule. Always wear the end users hat and look at the custom rule from their angle as well. Consider the most critical functionalities that the end user is expecting from your custom rule and think about the end user profile (Technical / Business) while doing the design.
Plan and Design step can be sub divided in to four steps.

Finalize the initial scope of the rule in terms of functionalities that the rule offer

In Connect-Excel rule there are four main functionalities

Reading data from a table structure
Reading data from a cell
Writing data to a table structure
Writing data to a cell

Sketch the UI of the rule to better align with the functionalities of the rule and to align with the end user knowledge of the domain.

In Connect-Excel rule there are 2 main tabs to distinguish reading and writing functions of the rule, inside those two tabs fields are aligned such a way that users will be able to better relate to the domain that they are working with, which is an Excel sheet with the rule.
This UI mock-up will be very helpful in the 2nd step when you are creating the properties

Setup/configure the PRPC environment to include any third party libraries or jar files

Depending on the problem, you might use external jar files or libraries that will deliver the functionalities of your custom rule, please put them to the correct class paths so that PRPC will identify those in compile time and run time.
Apache POI package was use to implement the Connect-Excel rule.

Workout the algorithms that will describe the behavior of the custom rule

It is always better to workout the algorithms offline before creating the full fledged rule, in terms of the Connect-Excel rule, basic operation of reading and writing was carried out with the Apache POI methods.

Create rule class and properties

As you all know classes play pivotal role in PRPC Object Relational Model, where you as the developer is abstracted from low level CRUD operations, so if you need to work with instances of a rule, first you need to have a class to start with. Not any other class, but a class which inherit from Rule- class, why, as I explained in the first post, when you inherit from Rule- class or any one of its descendants you get the Ruleness to your rule. The four magical spells.

So in Connect-Excel rule I have created a class called Rule-Connect-POI-Excel, as you can see it inherits through the the Rule-Connect- class, since Connect-Excel rule is related to connecting to a external source inheriting through the Rule-Connect- was the obvious choice.

Normally when a class is created inheriting from Rule- class PRPC maps the class to pr4_rule table in the PegaRULES database, we will see at the last step of this process how we map our new rule to a new table.

With the class created now it is the time to create the data model of the rule, the UI mock up will be very useful in this step as you have to map the UI with properties.

The best way to understand the property mappings in Connect-Excel rule is to go through the following screenshots.

Create a Rule Form

Up to now we have created the class and the properties of the new rule, in this step we will be creating the actual UI of the rule, which we call Rule Form in PRPC.

There are two ways in which we can create Rule Forms

1. The classical Rule-File-Form approach using Form Builder Tool

2. The new Rule-HTML-Harness approach starting from version 5.5

The Rule-File-Form approach is still widely used even in 6.2 version of the PRPC application, this is one of the biggest reasons why PRPC developer environment is IE only, reason being Rule-File-From use XML Data Islands, which is IE only, but from version 5.5 Pega has started to use Harness rules to define the rule forms, which is the best way to go forward.

I have used the Rule-File-Form approach to define the UI of the Connect-Excel rule

If you open an existing Rule-File-Form rule (e.g Connect SOAP) initially you will be overwhelmed by the amount of source code it has. but as always Pega has given a nice abstraction to us, called Form Builder, using Form Builder it is very easy to create a Form rule with in minutes.

The best way to understand the Form Builder is to investigate Form Builder layout of a know rule like Connect SOAP. Open existing Rule-File-Form rules and try to see how Pega has created the form rule layouts.

As you can see while you configure the tree structure according to your rule form UI by mapping properties of the rule class with UI elements, the Form Builder is creating the complex underline Form Rule UI source code.

If you can remember, in the Connect-Excel rule form, you can see a color picker component within the rule form itself, which you have not seen in Pega supplied rule forms. This demonstrate the power of PRPC to express anything you want in any level of the product, since PRPC is a web application, even while we use highly abstracted tool like Form Builder we can use normal web technologies like HTML, JavaScript to accomplish custom functionalities.

So finally after building the Rule Form you have to attach it to the rule class so that PRPC knows which UI to display when you want to do CRUD operations on an instances of the new Rule class.

Create a Model rule in the rule class

Model rule is used to initialize the rule properties of the new rule.

Create a Validate activity

Create an activity rule with the name Validate in the rule class and put all the custom validations of the new rule. PRPC will pick the validate activity using rule resolution and execute while the rule is being saved, resulting errors if errors are found.

Create a custom warning activity

If you are planning to add custom warning to your new rule, override the @baseclass CheckForCustomWarnings activity and save it to your rule class,

Create the activity which does the actual rule logic

Now we have come to the main step of the new rule creation process where we create the actual activity rule which carry out the logic behind the new rule.

Before describing the steps of our activity, let’s try to understand how we would normally use a connect rule which is available in PRPC. (e.g. Connect-SOAP).

So when we want to call a web service we will use the Connect-SOAP activity method and pass the parameters which the method is expecting. One of the parameter is name of the Connect SOAP rule. With that information PRPC magically does something and we have our data we requested.

So what does PRPC do, it basically does two things,

Opens the passed rule instances to the clipboard with the help of rule resolution
Apply the logic (in this case call an activity which has the logic) using the data which is in the rule

You will be able to see this if you examine the generated java code of an activity with the Connect-SOAP method.

We will be doing the same thing, but with small changes because of some limiting factors in PRPC.

So let’s start,

Sadly as soon as we start we are hitting a wall, we all would like to have a catchy name like Connect-Excel to call our new rule right, but in PRPC you can not create Rule-Methods rules, this is what you have in help under Rule-Methods in bold letters.

You cannot update methods, create new methods or override standard methods

So we have to find another alternative way to call our new rule, this is what I did, I created an activity with the name Connect-Excel and put the above described two steps in to that activity and use it to call our new rule. So when the developers want to use a Connect Excel rule they would call the Connect-Excel activity with proper parameters and you have the results. That was the best we can do with the PRPC limitations.

Having said that, Actually Pega has given a way to execute new rule type with an instruction called “Rule instruction”. The only reason I went with the first approach is to get a more catchy name.

So we have seen the activity signature and how you would go and call the activity to get the work done. If you are a developer who is using this new rule those information would be enough.

But we are implementing a new rule here, so let’s see how we would write the implementation code, the real stuff that will do the work.

As you can see in the first step Connect-Excel rule is being opened with the keys that was passed to the activity as parameters and in the second step the actual logic is written using the POI package.

I will be writing the remaining part in the next post, till then happy reading.

Creating custom rules in PRPC – Introduction

2011-01-15T02:18:00.001+05:30

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 "What is a rule?". If you can remember the Fast Track training that you have attended, you may remember the phrase "Everything is a rule" and how you left the Fast Track training with that in mind. but is it correct?, frankly not, technically a rule is an instance of a concrete class which is inheriting from Rule- Class. So while Decision Table / Decision Tree are rules, Operator ID / Access group are not, they are just data objects which does not have the "Ruleness" within them. So naturally the next question should be What is "Ruleness" ?

It turns out to be, when you inherit a class from Rule- class and make it concrete, all the instances of that class will get some magical powers as opposed to instances of a normal class. Exactly 4 magical spells which as a unit can be called as Rule Resolution options.

More importantly you as the developer can adjust the "Ruleness" according to your requirements. You get to choose the Rule Resolution options for your custom rule. You get to choose how your custom rule should behave at runtime.

So far we have understood the concepts of Rule and "Ruleness", now let's see the big question "What is a custom rule"

Custom rule is a rule which describes a process / execution pattern which does not available as out of the box rule in PRPC.

One of the unique features of a custom rule is that after the initial creation, it can be used by other developers as if it were out of the box rule.

Basically there are two flavors when comes to creating and executing rules in PRPC

1. Using an Activity to interpret an instant of a rule type. (e.g. Rule-Connect-SOAP)

2. Using the “First Use Assembly” process turning the rule instance in to a java class file and then let the PRPC engine to execute (e.g. Rule-Declare-DecisionTable)

In the next post I will explain the method one, by creating a rule that connects to an excel file to read and write data (Let's call the new rule Connect-Excel ). Here is a sneak preview of how the rule looks like.

CSSA PDN Links Compilation

2010-10-24T12:43:00.001+05:30

Following PDN links compilation document will help you to prepare for the Pega Certified Senior System Architect CSSA 5.5 exam. It is created according to the CSSA blueprint. Please use this as a starting point to prepare for the exam. Happy reading.

CSSA PDN Links Compilation

Upgrading flows that are already in production

2010-10-16T14:09:00.000+05:30

Business needs are always changing, so changing a logic of a process even after it went to the production is quite common. PRPC with the Build for Change motto does very good job of keeping it promises. But you need to be careful when changing flows. Because you might be in trouble if you do not know the below points. Happy reading.

PDN article link

Harness the power of PRPC Content search

2010-06-10T23:22:00.000+05:30

According to my view Content search is one of the main features within PRPC and most probably the best. Content search enables us to learn the beautiful PRPC architecture and it acts like a personal trainer. So how does the content search does all its magic. The secret is, Pega’s Content search is implemented using Apache Lucene open source text search engine.

You might be thinking it is a well known fact. Yes, you are absolutely correct, most of the Pega developers know that the content search is based on Apache Lucene. So then what’s all this fuss about.

The truth is we only use a fraction of what is available to us as content search, since the content search is based on Apache Lucene, we literally get the power of Query Parser Syntax in Lucene directly into content search.

That means you can do Fuzzy searches, Wildcard searches, Fields searches, Proximity searches, use Boolean operators, Group several searches and list goes on.

For actual syntaxes please read this wonderful Query Parser Syntax documentation.

Play with all the combinations and have fun.

In case if you have not enabled the Content Search here is the PDF.

Pinnacle of PRPC development

2010-06-08T12:12:00.002+05:30

As Software engineers, the pinnacle of PRPC development is creating your own custom rules which goes through the Rules assembly or First Use Assembly (FUA) process. You might wonder why someone should put custom rules creation at the top, frankly the reason is when you design a custom rule and finally implement it, you are exposed to the wonderful design of Pega itself and you slowly understand the inner workings of PRPC.

The moral of the story:

Don’t be stuck in a higher level abstraction layer, go down and explore how the creature is build, then only you will understand its behavior.

PRPC Error Messages

2010-06-07T09:43:00.020+05:30

Have you seen the following error messages, as developers we might have seen below error messages while developing with PRPC. But what will happen if these error messages happen to pop up on production environments. Look closely, these messages might be disclosing internal details or sometimes these messages are not meaningful to end users even though these are good debugging aid for developers. So as a solution PRPC has given us various options to customize error messages and configure some of them. To find out please read the following three PDN articles. Happy Reading.

1. Suppress details of show exception details (Java Exception Traceback)

2. How to suppress the Show Details link after a database exception

This article describes some legacy method of disabling the error messages; currently we have HTML rules inside PRPC for the same content.

3. How to customize the success and exception windows

Please read the article carefully, because some of the rule names are mentioned incorrectly, but after you understand the article, it is easy to find the correct rules.