CTI intermediate issues
Hi,
We are using pega call version Proprietary information hidden on pega 7.1.8, cpmhc 7.1.3. We have integrated with AVAYA SDK version 6.3.
We are using IE 11 and plug in mode.
In production environment the users are complaining that the CTI pop ups are working for sometime and suddenly it stops working. They have to do a new session and start again for CTI to work.
Can anyone please let me know the debugging steps I need to perform to understand this issue.
Thanks
Sunil
***Updated by moderator: Lochan to add Categories***
Pegasystems Inc.
US
Wellpoint
US
Thanks Keith.
I believe the problem is with IE security settings . I'll work with our security team on this.
Is there anyway to check if IE addon is compiling its script, Also can we check the port to properly listening.
Thanks
Sunil
Wellpoint
US
Hi Keith,
CallStateEvent tag is not created in screenpop.log file. Due to which the user is not receiving the pop up. Do you know what might have caused the issue.
Thanks
Sunil
PEG
US
I would use something like Task Manager to monitor the footprint of your Browser; perhaps there is a memory leak, and at some point the browser just gives up. If you see it increasing beyond reasonable bounds, this is a strong possibility.
The other thing that might be happening is that you are getting some kind of JavaScript error which is causing the listener which is involved in managing the popup to get removed. Can you modify your Browser options so that it shows all JS errors? Or, you might have the user run with the JS debugger enabled (difficult, I know, for an end user, but I've done it before) to see if this catches the JS fault.
If the user can run with Fiddler enabled and tracking, you can see if the Browser is attempting to contact the Server to manage the popup. The direct communication from the CTI server to the Browser will NOT show up in Fiddler, but Browser<==>Pega server will appear.
Finally, you might just do some JS debugging in pega_cti_callEventHandler.js
Wellpoint
US
Thanks Coher.
I believe the problem is with IE security settings . I'll work with our security team on this.
Is there anyway to check if IE addon is compiling its script, Also can we check the port if its listening and connection is still active.
Thanks
Sunil
Wellpoint
US
Hi Coher,
CallStateEvent tag is not created in screenpop.log file. Due to which the user is not receiving the pop up. Do you know what might have caused the issue?
Thanks
Sunil
PEG
US
The listener "PhoneCallStateEvent" might not be getting registered. Or, there might have been a previous JS error in processing a previous callStateEvent, and this would have removed the listener. Or, the event might not be getting sent; do you see it in the CTI log?
You don't say what version of Pega you are running with, but see if your version of handleCallStateEvents encloses the bulk of the code in a try/catch block with a write to the screenpop log of "EXCEPTION Handling event" in case an exception occurs. If you don't have this, add it.
Wellpoint
US
Thanks Coher.
We are using Pega call Proprietary information hidden and Pega PRPC 7.1.8.
handleCallStateEvents have try and catch method.
Here is a link to the PDN doc that contains some debugging tools available in pegacall.
https://pdn.pega.com/documents/pegacall-configuration-and-operations-guide-cti-link-engine-avaya-aes-cti-7131
Pega 105 / appendix
You need to ensure you have the pegacti debug enabled and since we are dealing with screenpops you will need to enable client side debug. If you are using ocx control there is a screenpop log that can be setup, if its applet there is an applet log that can be set in the presence rule, or if its Long poll / http event you will need to a collect a F12 / console log (fiddler, wireshark, etc..).
Once you have all this in place you just need to recreate the behavior and then walk through the Pegacti log to see if the screenpop / alerting events ever hit PRPC and if so do they make it to the browser.
If you need more assistance than this I would suggest opening an SR.
Thanks.