Monitoring Email Listener Performance?
We'd like to be better be able to monitor the email listener performance.
I started the analysis here to figure out how we would do this.
Measuring Email Listener Performance [I assume most Pega employees have access to this document -- cf. Support Content Persistence ]
One concrete goal is to measure/alert if there are latencies in the time that Pega is processing emails. This could be done if the EmailListener were looking at the mail header to find out when the message was received by the email server -- and record that in the headers passed into the Service, and alert if that goes beyond a threshold. I don't see that in v7.1.5. Curious what will be available in the future.
***Updated by moderator: Marissa to close 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.
>>> I wouldn't mind if my email is processed 3-4 minutes later
- an email or SLA triggering late than expected/configured time might impact the business policies.
- edge cases (exactly mid night, leap year, cut off date breaches etc..)
>>> These are batch processes which may take some time to process.
- from my learning's, the listener should act only as a bridge of transferring/reading data and rest of the bulk processing should be passed to agents for better processing of work
Hi Jon,
As suggested in your article, do we have any alert in Pega that is thrown if the time taken from email received to email processed is greater than the defined threshold time
OR
Can we find the time taken to process the email after it is received
@Phani Sahukaru
Why would listener get impacted on exactly mid night, leap year, cut off date breaches etc..? Listeners are to read incoming emails, not sending out emails. Do you expect to receive a huge number of emails at mid night or any scenarios you mentioned? I'd say no. Bunch of incoming emails coming in at the same time is a rare scenario. Business policy might have something to respond to an email within an hour or so, but not definitely within 1 or 2 minutes.
Thank you Abhijith for your reply.
In general it'd be nice if there is an improvement in this area so tried putting an arbitrary use case.
Just a thought, why are you so particular about email listener performance unless it's taking hours to process? As a user, I wouldn't mind if my email is processed 3-4 minutes later. I mean, it's not an user interface to give me bad user experience or a service which is timing out. These are batch processes which may take some time to process.
I'm just trying to know the impact you had because of this performance.