PRPC Developer

Exploring the wonderful world of Pega Rules Process Commander

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


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


Dynamic System Settings

Data Transform

Map Value

Data Table



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.

Extension points are one of the important constructs that designers of PRPC have baked into the product. As the name says it lets you to extend core functionalities of PRPC in a control manner as envisioned by the original designer of a particular module.

As a beginner when you first found out about extension points you were very exited and used this new found pattern to crack a problem with ease. After that for most of us the natural question was where else has Pega used this pattern while building the product. You do a PDN search and find a list of activities, but the real question is, is that it, have they documented everything in PDN, I do not think so.

So this attempt is to capture documented and undocumented Extension Points into one centralized place with the help of PRPC community.

If you are willing to contribute please use the following Google form to submit extension points where they will be added to a public Google spreadsheet.

To access the form directly please visit here

To see the extension points list please visit here

I think most of you know that we can add custom search engines to chrome and associate them with a keyword. By doing that we can directly invoke search from address bar itself. We can do the same for Pega Developer Network search.

Right Click Address bar --> Edit Search Engines –> Configure ‘Other search engines’ section with following URLs.

PDN default search -
PDN forum search -

When you want to search type the specific keyword space your search term in address bar and hit Enter.




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.


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.

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.

Color Clipboard

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

  1. Create a sandbox ruleset and version
  2. Update ruleset restrictions in classes to include the sandbox ruleset
  3. Create a separate sandbox application rule and include the sandbox ruleset and put your main application as the Built on Application
  4. Create a sandbox access group and include the sandbox application
  5. 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.

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.

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.

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.

Connect Excel - write data

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

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