Hurry Up Already!!!

For a general application build, any usage of Pega activites / decisions / flows would be sufficient to accomplish a given task. In fact, taking the worst possible route to do something would still be better than not doing it. However, when troubleshooting an issue, tracer is an absolutely invaluable tool. One drawback of tracing is that it can be quite long and time consuming. Luckily for us, Pega has incorporated a number of options which can easily optimize tracer and speed up our troubleshooting time.

As a general rule of thumb, a developer can limit the tracer to trace only certain rulesets and/or certain rule types. This can easily cut the time in half when we only need to trace only our application rules, and not built-in Pega rules/rulesets.

If the above method is still not fast enough, the next best thing to do is to play around with the options below.

For the “Events to Trace”, the slowest part of tracing is listing each activity step. Sometimes we don’t care for each step of the activity. And when we do, we can always use the “Trace Open Rule” feature to focus on a particular activity that we are interested in. Disabling Activity Steps will make the tracer fly.

The next thing that can be done is un-checking the When rules start event. For most traces the start of a when rule serves no real purpose. Since we get our evaluations when the rule ends, we can easily survive with only the When rule end event.

Under the “General Options” section, the two options listed also have an impact on tracing speed. When the Abbreviate Events is checked, the tracer does not write the clipboard page into the tracer log. Since less data needs to be retrieved and stored in memory, the tracer run becomes quicker.

The Expand Java Pages option deals with properties that are of mode “Java Page”. As I have not personally encountered a scenario where properties are used in this mode, this option should still be noted for cases where there are properties of this mode.

Tracing the tracer

When I first got a glimpse of PRPC, I was thoroughly impressed at how easy it looked. I mean, how hard could it be to place some Visio shapes together and link them with various connectors? Well, apparently looks can be deceiving, and what seemed to be a simple visual diagram is really a complex network of activities, decisions and sub-flows. Figuring out how everything ties together is as hard is navigating a spider web. Luckily for us, PRPC includes a tracer feature which lets us sail along the visual pathways with ease, relatively speaking.

Aside from giving us the details on each activity step, stream rule, and/or when rule that has run, the tracer’s high-level objective is to tell the developer which paths the work object has taken. The most common way of branching out the flow (aside from Tickets) is to use Fork shapes, Decision shapes and Utility shapes. While it’s always best to use the shape that is most appropriate for the task, in certain cases, clarity may be more important than function, and likewise, each shape mentioned above provides a different way of seeing the right path.

Below is the screenshot of the most typical used flow fork methods.

Out of all the choices displayed, the When fork may be the least clear. When the When rule returns false, the “ELSE” path is taken, and that is clearly indicated. When the When rule returns true, the tracer’s description displays the name of the rule, which blends in quite well with the rest of the lines, leading to a lack of clarity for the end-user/developer. A lot of times when we have a lot of lines to go through the tracer, it’s good to have a clear indication of what is happening.

For all the other methods, the values/statues returned are clearly indicated. For the decision table/tree, the value returned is clearly displayed. For the utility/activity shapes, the status returned is clearly displayed.

While neither of the methods mentioned above are “best practice”, the information described is good to know when designing and building new application, from a developer’s standpoint.

Below is the flow that was used to get the results described above.