Live Chat handoff from Aria results in messages not being seen on both sides
Article ID: 204476
Updated On:
Products
Issue/Introduction
During a run of xFlow and ServicePoint, will find that initially, end users are able to transition an Aria Chatbot interaction to a Live Analyst Chat. However, after a time, the transition from Aria to Live Analyst Chat stops working. When the issue occurs, after the transition to Live Analyst Chat, end users that are transmitting new messages do not see the resultant communications appear on either side of the chat screens. If the xFlow service is restarted, Live Analyst Chat works normally again for a while until the functionality to hand off from Aria Chat to Live Analyst Chat is leveraged again, either hours later or the next day.
Issue is specific to Aria Chat to Live Analyst Chat transition. If one disables Aria Chat functionality in xFlow and operates solely with Live Analyst chat on an existing ticket, there are no issues seen.
The collabMS.log files or the collabMS_debug.log files located in "C:\Program Files\CA\xFlow\APPS\logs" will contain messages such as:
collabMS_debug.log:ERROR 2020-01-01 07:08:35 [ka.actor.default-dispatcher-50] SdmVirtdbInsertActor 67 Exception occured in Virtbd Insert Actor recvMsg method com.ca.casm.playApi.sdm.genpojo.chat_log WARNING arguments left: 1
collabMS_debug.log:ERROR 2020-01-01 07:08:35 [ka.actor.default-dispatcher-50] SdmVirtdbInsertActor 67 OnReceive Method received the CasmBaseExceptionException occured in Virtbd Insert Actor recvMsg method com.ca.casm.playApi.sdm.genpojo.chat_log
Environment
Release : 17.3 GA, RU1, and RU2
Component : XFLOW INTERFACE FOR SDM
Cause
The issue is occurring as xFlow is attempting to prepare a message to send to the backend virtdb process, but the message fails to even make it to the virtdb process. This is due to the absence of the chat_log.class file.
Resolution
During startup of the xFlow interface, verify that the following directories are present in Windows Temp directory, ie: C:\Windows\Temp:
Directory of C:\Windows\Temp
01/01/2020 02:03 PM <DIR> CasmPlayApi
01/01/2020 02:02 PM <DIR> playtemp11501088754349590551
01/01/2020 02:02 PM <DIR> playtemp14466993665470835437
01/01/2020 02:02 PM <DIR> playtemp15015678114917297493
01/01/2020 02:02 PM <DIR> playtemp4105150396921134535
Of particular interest is the chat_log.class file, which should be located:
C:\Windows\Temp\CasmPlayApi\Class\Pojo\com\ca\casm\playApi\sdm\genpojo
What happens is that the CasmPlayApi and playtemp directories located in the C:\Windows\Temp directory may be wiped out while xFlow is running. Removal may take place by site defined maintenance activities, such as Disk Cleanup, Microsoft SCCM scripting, or third party maintenance utilities.
Workaround for the present time is to suspect any actions/activities that would impact C:\Windows\Temp directory or restart xFlow immediately after a given scheduled activity. Restarting xFlow would restore the above directories and the associated class file.
Additional Information
Issue has been addressed in the 17.3 RU4 patch and higher.
Starting from 17.3 RU4, there is some change to the location of CasmPlayApi...please refer to
https://knowledge.broadcom.com/external/article?articleId=219886
Feedback
