This is just a varning!!

As developers, we always strive for efficiency and the hope of doing our work the best possible way. Sometimes this mentality drives us into solid walls. But being the smart people that we are, we create our own holes in the wall, break the obstacles, and allow ourselves to see the big picture.

One such example of efficiency revolves around PRPC activities and variables. There are three common ways we can store some data in memory. We can either use properties, parameters, or local variables. Properties are great in that they are static, and can be referenced basically from anywhere (assuming we know the correct clipboard page). Their downfall is that, as intended, they are static. Any temporary property that is created will always remain in the ruleset used.

The other two variables are dynamic, created as necessary, and reside only during the processing of the running activity. There are, however, distinct differences between the two. Local variables can only be used within a single activity. Parameters are more flexible and they can be passed from one activity (or flow) to another. This added flexibility adds to a higher overhead memory allocation, and make them not as efficient for quick processing. Likewise, when a process does not require the sharing of memory space, there is no reason to use a parameter over a local variable.

For troubleshooting, however, there is a bigger problem. Parameters can easily be viewable in the Tracer, where as local variables cannot.

There is a solution for this!

Since PRPC 5.3, Pega has introduced the Log-Message method. This method allows the activity to log any type of a message into the physical log file, or if necessary, to the tracer. In our activities, we can use this method to log anything we need (including local variables), depending on our logging level. More importantly, for real time tracing, we can have those same messages be displayed in the tracer for us.

Below is a screenshot of a tracer run which shows such tracer messages with local variable values.

For the tracer options, the only thing we need to do is enable the "Log Messages" option in the Events to Trace section.

Now.... just because we are using a more efficient variable, that does not mean that should start logging it every chance we get. It would probably make more sense to have the Log-Message step conditionalized, so that it runs only when needed (lets say we're running our application in Debug mode).

Of course, all of this is really irrelevant information, since we all know that our code is perfect :)