Discussion
Do you know .. Popular Pega Classes/Loggers that helps in Troubleshooting Issues ? Check it out here-
Have you spent Hours & days of your time to Troubleshoot Issues ?
Here are some Pega Classes or Loggers that I (came across..) generally use to Troubleshoot Issues quickly. You would also have enabled DEBUG some or the other time for a PegaClass/Activity & if you feel after enabling DEBUG to that class/activity helped you in narrowing down the Root-Cause, please share it here.
Lets put all together & have a Nice Handy document which would help all of us.
Popular Pega Classes/Loggers - helps in Troubleshooting Issues | ||
Problem Description/Usage | Pega OOTB Classes/Loggers | Set Log Level |
To troubleshoot PegaCall CTI related issues | com.pega.pegacti | DEBUG |
com.pegarules.generated.pega_channelservices_utilities | DEBUG | |
To understand the rule resolution/Troubleshoot Rulenotfound exception issues | com.pega.pegarules.generation.internal.vtable.asm | DEBUG |
com.pega.pegarules.generation.internal.vtable.ruleres.VirtualTableResolver | DEBUG | |
com.pega.pegarules.generation.internal.vtable.VirtualTableImpl | DEBUG | |
To troubleshoot Integration-Connector related issues | Rule_Obj_Activity.InvokeAxis2.Rule_Connect_SOAP.Action | DEBUG |
com.pega.pegarules.integration.internal.ServiceHelper | DEBUG | |
com.pega.pegarules.integration.internal.util.SOAPUtils | DEBUG | |
To produce detailed output from an email listener | com.pega.pegarules.services.emaillistener | DEBUG |
To troubleshoot IAC issues, if there are issues with the pzPostData parameter | com.pega.pegarules.session.internal.engineinterface.service.HttpAPI | WARN |
Troubleshoot Agents | com.pega.pegarules.session.internal.async.Agent | DEBUG |
com.pega.pegarules.session.internal.async.BatchRequestorTask | DEBUG | |
com.pega.pegarules.session.internal.async.agent.QueueManagerImpl | DEBUG | |
com.pega.pegarules.session.internal.async.agent.QueueProcessor | DEBUG | |
To troubleshoot AES & Monitored Nodes Communication issues, enabling debug on AES Node | Rule_Obj_Activity.AlertCreateNode | DEBUG |
Rule_Obj_Activity.NodeCreate | DEBUG | |
Rule_Obj_Activity.ClusterCreate | DEBUG | |
Rule_Obj_Activity.ExecuteMBeanOperationNode | DEBUG | |
Rule_Obj_Activity.VersionInfoNode | DEBUG | |
Rule_Obj_Activity.parseAlertLineSOAP | DEBUG | |
Rule_Obj_Activity.parseAlertLine | DEBUG | |
com.pega.pegarules.services.ServiceHelper | DEBUG | |
com.pega.pegarules.authentication.Authentication | DEBUG |
**Moderation Team has archived post**
This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.
Thanks Hari, that’s a great idea, having a list correlating keywords of trouble areas and suggested debug classes.
One thing I’ve found useful occasionally is being able to turn on the debug classes just before performing the operation I want to analyze, and then turn them right off again right after.
That is useful for situations where leaving those debug classes on longer floods the log file with lots of unwanted info.
A fairly easy way to see how to turn the classes on and off is to trace the set-logging-level landing page to capture the java it uses for setting the logging level for the class, and then copy that small piece of java into your own activity just before the operation you want to analyze, and a similar piece just after the operation to restore the class settings.
That trick becomes even more valuable when the number of classes involved is more than one, since changing the values of multiple classes takes a while using the landing page since only one class can be set at a time.
/Eric