My Top Tips For Debugging Pega Like a Pro
Written By: Rachel Hoenisch
Debugging is an essential skill for a developer, but it can be quite difficult to teach; everyone has their own way of approaching problems, and what feels as natural as breathing for one person might make no sense to another. There’s no single ‘right’ way to go about it, and developing your own method takes time.
That being said, as Pega developers, we share a common toolbox when it comes to debugging, and understanding those tools is the first step to improving your debugging skills. Today I’ll be going over the four tools I use most often in my work: the tracer, the clipboard, logs, and Live UI.
For me, the first step toward fixing an issue is understanding it. When does it happen? What users experience it? Does it require a delicate dance of steps to replicate, or is it as simple as a button doing nothing when clicked? Sometimes it’s easy to get this information, but when the problem isn’t readily apparent in the UI, the tracer is your best friend. Running the tracer while replicating an issue lets you view every step of the processing that’s taking place behind the scenes, and issues are brightly highlighted by colored cells, allowing you to isolate the exact location of any failures. Yellow means a warning message, orange denotes the presence of a message on a page, and red marks a failed step; even if you have thousands of lines in your tracer, these visual indicators make it easy to scroll through and pinpoint areas of potential interest. Clicking into the Step Page column of a line will allow you to take a closer look at the data in question, and the Name and Ruleset columns can be used to isolate exactly what rule (or version of a rule) is causing the problem.
Sometimes, though, the bug isn’t due to failed processing; in that case, the tracer may not yield any helpful information. Let’s say I have a section with a table that’s supposed to appear when I click a button, but nothing happens when the button is clicked. In that case, my tool of choice will be the clipboard. This is a collection of all the data in memory, and selecting each page allows you to view which properties are present, as well as their current values. Here, you can find the results of data pages, the contents of temporary pages, and everything on pyWorkPage. In the missing table example given above, perhaps my visibility is based on the property .ShowTable, which can be either true or false. If I click the button, open the clipboard, and find that .ShowTable is still set to false, there’s a good chance that my button isn’t correctly setting .ShowTable to true as intended.
But what then? My app might have hundreds or thousands of sections, and I have no idea what this one’s name is. I could go to Records or start paging through classes in the App Explorer, hoping I’ll eventually come across it by chance. Or I could use Live UI, a tool that allows you to instantly identify any section on your screen, as well as what flow action called it. For the button example, I’d simply open Live UI, click on the button or its surroundings, and use the target icon on the rectangle or in the panel on the right to open it up. This allows me to jump straight to the section in question, where I can confirm my suspicions and make any changes as necessary.
Generally, I find that I can resolve the vast majority of bugs by using the three tools mentioned so far. There are some cases, however, that require deeper digging. That’s when the logs come in handy. Though they can certainly be overwhelming at first, logs allow you to comb through the events happening in your app and search for anything that might be out of place, such as exceptions, errors, or messages. This can help you unearth deeper configuration issues, things that can’t be seen with the tracer, the clipboard, and Live UI alone. Even if you don’t understand all of what you’re seeing, the logs can often act as a springboard for further research by giving you key phrases or error codes to look into. As a note, building activities with error handling that involves strategically logging messages is extremely helpful in debugging, especially if you make those messages descriptive.
This only scratches the surface of how these four tools can be used; the more time you spend with them, the more you’ll learn about their nuances and the situations they’re best suited for. The best way to get familiar with them is to practice. With time, using them will become second nature, and as your debugging skills develop, bugs that would have once taken you hours to solve will be resolved in mere minutes.