Through out my nearly 16 years of experience in Pega I have worked on many different projects and with many different teams. Sometime I am surprised to see some so called best practices which are actually not making any sense and actually not really best practices. So I thought will do a write on them.

Reusing Properties

Don’t get confused. I don’t mean reusing properties with the intended purpose they have created for instead reusing some irrelevant properties already available in the class for completely different purpose. Creating a new property rule doesn’t harm the performance of the system. Pega has got a good rule caching mechanism so only the used rules are counted. Even if there are many properties available in the class, if the name of the property does not match with the requirement feel free to create a new one. Stop using pyNote, pyLabel or pyDescription or any other property for the sake of avoid creating new property rules.

The code you create should be easily readable by one and it will save lot of time for yourself other team members in future. Don’t count on people’s knowledge for understanding which property hold what value at what situation in the application by reusing not relevant properties.

Naming the rules

I see in many applications developers name the rules to represent logic in it instead of the business purpose of the rule. For example consider a simple a requirement where if the amount is more than 100 you want to route the case for approval. So in this situation if you create a when rule “IsAmountLessThan100” you make an obvious mistake as naming the rule with the logic instead of the business purpose. In future if the business logic changes to where approval is needed for amount more than 150 instead of 100 then we are in trouble. Either the when rule IsAmountLessThan100 will hold a logic of Amount<100 or you will have to create a new when rule and change the places where ever you called the previous when rule. By doing this you loose the purpose of introducing the when rule in the first place which is keeping the logic in this single rule. So in this example situation the rule name could have been IsApprovalNeeded with the logic Amount>100. So when amount change you only update the amount in the when rule. Also the same time the application is more readable. In the flow if you use the when rule IsApprovalNeeded the path will go to approval. So reading the flow will become easy.

Using App Extension when not required

Using App Extension is a great way when developing frameworks to allow implementation applications to use the framework without copying rules from framework. But in a situation we build application for a particular client most of the details we don’t need to keep in the app extension. When we refer rules through app extension we sacrifices the referencing and trackability. If app extension is for sure going limit future customization then we could go for it. But most of the time we over do it.

Consider an example where we refer a work class through app extension saying the work class could change in future. Assume this is not a framework build, how frequently the class is going to be renamed. Also if the class is changed it is a code change going to happen within the same application. So the change cannot be addressed only by changing app extension. So it is not a good use case for app extension.

Consider another example where you refer a work basket / work queue name in the flow through an app extension thinking business might change the work basket name. Let say business wants to rename the work basket name, in this you should only update the work basket description as you should be displaying work basket name in screen not the ID. Let say business wants to split the work queue and for some scenarios wants to use a second work basket. In this scenario you will have to have change the flow even if you have used app extension as you will not have two references to the workbasket. So as you can see it is not going to add any value using app extension instead will make it difficult to see where the workbasket has been used.

So always question the decision whether you really need an app extension.

Focusing on guardrail score over anything else

In some of the projects I noticed, developers are too aggressive on reducing guardrail warnings and try different techniques to hide / reduce the warnings. Following are some techniques used to improve the score.

1. Calling activities through functions in data transform.
2. Creating a single activity by combining multiple actions in it and controlling the action to perform by parameters.
3. Creating a single activity violates the best practice then calling it everywhere such as a commit activity.

We need to understand guardrail warnings will provide some inputs on best practices but following them as it is without proper insight will do more harm than help. For a certain scenarios if you need an activity you will have to go for it. If you need to call an activity in after action then create a post activity and call it from there instead of from data transform using function. When you call an activity inside a function you will not have the reference. Quality of your application is mostly depends on how readable and stable your code is than how much guardrail score you have.

Not using appropriate rule type

There are many rules types available in Pega. But most of the time we tend to use what ever we became familiar with. Time to time Pega introduces new features / rule types. Always be open for experimenting with new rule types instead of trying to achieve everything with known rule types.

For example let say you have queued something to run in background when user trigger it from the screen due to the heavy processing involved. How you will notify the user once the processing is complete? Are you going call refresh at time interval until it is done? That is when Pega UI channel notification comes where instead pulling you can use push notification through web socket implementation.

Not using appropriate technology

Pega is a very good BPM tool doesn’t make it a great whole purpose tool. So when solutioning a given problem always see if that needs to be solved within Pega. With the introduction of container based deployments it is easy to create and deploy micro services in any technology and connect them to Pega to solve the specific problem.

I will give an example based on a recent project I worked with where we were using Pega robotics. The problem was we have to connect to email server.

Over use of Job Scheduler

Job scheduler is good for doing batch processing of something at schedule time. But in some projects I see many thing is processed using queue processing including some part of the case processing. When job scheduler process a case and move from one stage to another the holistic view in case designer cannot give good understanding of the case processing. Always the design should be readable and should limit the possibility of introducing errors by new developers. For example in your project if you resolve all the cases at night using a job scheduler think whether you really need that. Instead you could add parallel flow when initiating the case which will resolve the case after no of hours based on a SLA rule at case level. This way load will be evenly distributed to the util nodes throughout the day instead of accumulating more loads at certain time. As more and more job scheduler added to the application to run at night you will start noticing performance decrease for the batch processing.

Having too many disconnected actions

In many projects, I have noticed developers tend to call several actions on click of button or link to achieve something. This introduce several issues. First one is performance issue and many sequential calls needs to be made to the server will have visible delay for users. Sometimes users will think click is not registered and could try clicking again. Although the Pega’s wait icon can be displayed to give visual feedback to users to let them know it is progressing the experience will not good for users. Second issue is many disconnected actions will make debugging difficult also there is no flow view on how things are moving. Always think if the sequence of actions can be organized in alternative stage and achieved using OOTB case processing. If there is no way using OOTB way, try to limit the number of actions by grouping things in single action call to server.

Summary

We have went through about some of the bad practices which we shouldn’t follow. Lets end this post with the quick checklist of what makes good design and implementation best practice.

1. Use case stages and steps as much as possible.
2. Avoid calling many actions on single click of button or link.
3. Explore with many rule type available and find very appropriate rule type for the given problem.
4. Avoid using job scheduler for part of the case processing, which should be handled within the case
5. Avoid app extension when not needed. When something changes if you also have to change the rule then no point of referring it through app extension.

I know there will be many other points you want to add to this list. Write about the bad practice you noticed in comments below for others to know. Thank you for reading.