As of now, we have some default properties which we use to log the alerts.
But in advanced world there is a chance of working multiple users on a single rule. Due to this, there is a chance of getting multiple exceptions/alerts during the run time. These may come because a developer not following proper guidelines.
When as a Developer and as a User tried to analyze these log I wish I could have these additional customized properties in the logs which make my life easy.
As a Developer,
- If the logs have the version and developer name who recently worked, then it will be easy to assign this to the concerned person.
As an End User,
- Example, an application has some 150 requests that will be processed using PEGA (there are common rules which are used).
- Each request have some unique identifiers like request ID, session ID, etc. (pal log properties)
- During the processing of the request, I have got some 20 Alerts on the common rules used.
- Now, the only way to identify the occurrence of the Alert is 'Time Stamp'. This may take around 5 to 10 mins to identify the request which causing the alert.
- If we have an option to add my custom (pal log) properties to logs then I can identify the request in seconds.
- Easy identification of the alert
- It saves times
- Analyzing and fixing the alert will be easier
- Adding customized properties may decrease the performance as the log size increases. But, it can be fixed faster so that the alert will not repeat.
***Edited by Moderator Marissa to change type from Pega Academy to Product***
Thank you for sharing your idea here in the Pega Collaboration Center (PCC)!
I have submitted this idea on your behalf in our internal system for feature enhancements and updated your post with the associated FDBK-ID. You can take this ID to your Account Executive for next steps.
Thanks and keep the ideas coming!
Marissa | Senior Moderator | Pega Collaboration Center
Logs already have requestor id to help identify the user session. As you mentioned if a system is being used by multiple users it is hard to identify which particular request created the alert. But what a developer does by identifying the request. I think the alert has all the necessary information like the activity/harness/report which created the issue. So, the developer have to look the rule in question and fix the rule.