Support Article
Unable to read updated Call Interaction for ID!<pyCallId>
Summary
Errors are generated periodically in the log file related to the Call Interaction ID.
Error Messages
Unable to read updated Call Interaction for ID!14915
java.lang.Throwable
at com.pegarules.generated.activity.ra_action_getinteraction_501a944a4dbc9ea3927c5fa93ac84fec.step2_circum0(ra_action_getinteraction_501a944a4dbc9ea3927c5fa93ac84fec.java:306)
Steps to Reproduce
- Take calls in the Call Center application.
- Review the log files.
Root Cause
The errors occurred because the Avaya server recycled through the call IDs and the call objects have not been properly purged.
Resolution
Perform the following local-change:
The call object is a temporary object that is valid only for the life of the call. It is necessary that objects get deleted in a timely fashion.
There is a dynamic system setting (DSS) with the name PurgeCallObjects/CallAgeLimit/Default and with Pega-ChannelServices as the owning ruleset. This is the setting that defines the maximum time (in minutes) that a call object should live. It should be long enough so that a call object is unlikely to be deleted while still in use (that is, the call is still ongoing).
There is an agent called purgeCallObject in Pega-CTI that does the actual purge of the call objects. By default, this agent runs every 24 hours. It can be modified to run every 2 or 3 hours.
A balance must be achieved between the life of the call object (controlled by the DSS setting), the likely maximum call time, and the interval over which the purge agent runs.
The DSS interval should be long enough so that the call ID is unlikely to be deleted while a call is still in progress. If a call ID goes away while a call is in progress, certain operations (for example, forwarding a call) will no longer be possible. It cannot be so long that the Avaya server reuses a call ID before it gets purged from the previous usage.
Therefore, a reasonable combination would be for the DSS setting to allow purging of the call ID after 3 hours, and the agent to run every 4 hours. This balance ensures that call IDs go away before they are reused under the observed 17-hour cycle window (given that it is unlikely for a call to be in progress for more than 3 hours) and that the agent will purge everything at least every 4 hours and will not be running too often.
Caveat: If a problem occurs and the purge agent cannot run in Production, it is because there is a defect in PegaRULES:SysAdm4, which restricts access to all Rule-Obj-FieldValue class entities to Production Level 4 and below. Import HFix-33528 to allow the purge agent to run. Because rule resolution is not used when processing Rule-Access-Role-Object (RARO) rules, this hotfix can be used even if it is for another release.
Also, if the system generates more than 50 call IDs between runs of the purge agent, create a custom copy in the ruleset of the ExpiredCallObjects list view and disable paging. Otherwise, the agent will not purge more than 50 items on any run. Modify the CTIService access group to ensure that it has visibility into the custom ruleset where the list view is saved.
See the appropriate Pega Call CTI Link guide for the product release that you are using.
Examples:
Pega Call Configuration and Operations Guide for CTI Link with Avaya AES CTI 7.21
Pega Call 8.3 Configuration and Operations Guide for CTI Link with Avaya AES CTI .
Tags:
Published December 2, 2021
Have a question? Get answers now.
Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.