I notice execution links can be named and also have a UniqueID property. Is there any way I can reference either the name or unique ID of an execution link in my automations?
I spend a lot of time writing custom error messages in my automations to log in my robotic activities. For example, “divMenu was not created in automation WEB_P_NavigateHome.” Even though the messages are a clearly written, they’re ultimately not much help in debugging as I still have to find the automation and back track through the code to see why the automation may have failed.
Since I have to open the automation anyway, it seems like it’d be more useful and time saving if I could log the name or unique ID of the last execution link. I could search my project for the execution link and find the exact point where the automation failed.
@Jarrett There is not any published and documented way to access your stack trace of previous steps in an automation. The good news though is that you really don’t need to if you have at least an INFO level log (although for troubleshooting, I suggest setting all categories to VERBOSE). The log contains each execution link and data link (yellow and blue lines respectively). From here, you can easily locate your error and work backwards to see the steps. Below, I’ll illustrate how you can make that easier.
The Robot Inspector tool creates a “CMD” file in your %AppData%\Pegasystems folder named “_LogParser.cmd”. This can be helpful in reading logs since it can distill your log file down to only the lines you care about. The mechanics of the cmd file are better explained here; https://support.pega.com/discussion/quick-log-parsing. I generally customize the lines I am interested in by starting with only the execution and data links as well as exceptions.
When examining a log for a particular error message, I first start by searching for that message and locating the point at which it occurs. From there, you can backtrack by scrolling up to locate the preceding steps. Execution links will be logged on a line containing “ExecutionLink From:” while data links will be logged on a line containing “propagating From:”. This is easiest with a parsed log using the CMD above. I usually use Notepad++ to open log files and will open the parsed log and the full log at the same time. I’ll start my analysis on the parsed one to locate where the issue occurred and then backtrack a little to see if I can determine a cause. If I need more information such as matching information or anything like that, I’ll switch to the full log.
@ThomasSasnett Thank you. We usually keep logging off in production though.
I realized I can copy the Unique ID property on the execution link and paste it into my error messages. Even if the execution link changes in the future, the ID number should still be unique in the message, and I can find the location of the error.
