03-17-2016 11:16 PM
Hi,
I am using PCCE 10.5 and using Finesse 10.5.
In ICM script I am passing CTI data via Call Variable1, Call Variable2, Call Variable3, Call Variable4 and Call Variable5. When the agent answer new call then the agent can see all the data in Finesse screen.
Now if the agent transfer to the call to another queue and before queuing the call I change the Call Variable3 in ICM script so that it reflect the new queue name. Now there are 2 scenario
1. No agent available in the new queue, caller hear the queue music after that agent become available and answered the call. This case agent call the Call Variable3 updated with the new Queue name.
The problem is
2. If the agent is available in the new queue and answer the call then Call Variable3 does not update and agent see Old queue name.
I capture dump log from cti server and can see that Call Variable3 updated before reaching the second agent and Finesse logs showing that it receive the updated value of Call Variable3. So wondering why Finesse does not show the updated value.
So is there any difference in Finesse screen pop if the call is answered after passing the queue node and if the call is directly answered from the queue node?
Thanks,
Ashfaque
Solved! Go to Solution.
03-31-2016 02:39 PM
Hi,
I did an analysis of the logs you provided and came to this conclusion:
In the scenario where there are no agents available (#1) and call variable 3 gets updated correctly,
If you notice, when Agent 1002 goes READY and gets the call with the updated call variable 3, the call id is different than the original and consult call, and the callType is PREROUTE_ACD_IN instead of TRANSFER. It seems like UCCE treats the call to Agent 1002 as a queued call and loses the transfer details.
In the scenario where Agent 1002 is available (#2) and call variable 3 doesn't get updated correctly,
If you notice, in this situation, the consult call is the one that gets its call variable 3 updated. Since the original call (almost) always survives, the updated call variable 3 gets lost.
UCCE is sending Finesse the events like this, so Finesse is just reading in these events and processing it. There isn't anything Finesse can do in this situation. If it is a problem for you, you have to chase the issue with the UCCE/PCCE team.
I have attached my notes (copies of log snippets from the webservices logs) to come to this conclusion.
Thanx,
Denise
03-18-2016 09:45 AM
Hi,
Are you using the Finesse desktop out of the box? In order to answer your question correctly, I would need to see the webservices logs and the matching client logs to see what is going on.
Also, when you say Finesse screen pop, do you mean a workflow screen pop? Or are you referring to the call variable layout in the call control gadget. Providing a screenshot of the issue would be good too.
Thanx,
Denise
03-20-2016 07:47 PM
Hi Denise,
I am replying on behalf my friend Hossain.
We use the default call control gadget and populate the call queue by grab the call variable 3 value from ICM script.
We notice if the call straight away answer by the agent, the call queue never refresh.
I see the log and I could not find the new dialog id.
Below is the log:
Mar 18 2016 16:39:54.640 +0800: CallControl : [ClientServices] {"content":"/finesse/api/User/1002/Dialogs1416168003241415TRANSFER2900callVariable1Y|Y|N|EN|2900callVariable2S1234567D|T1234567JcallVariable3CC_Code_1_1_PQcallVariable4219-151652-0callVariable51416callVariable6ENcallVariable72981callVariable8callVariable9callVariable10user.microapp.ToExtVXML[0]application=EnableCSSuser.microapp.FromExtVXML[0]Y|Y|N|EN|2900user.microapp.error_code0user.media.idE72871800001000000000042691EB60Auser.microapp.isPostCallSurveyYuser.microapp.metadataN|000|01|00|00|007675|GS,Server,V,interruptuser.microapp.ToExtVXML[2]user.microapp.FromExtVXML[3]user.microapp.ToExtVXML[1]CallId=219-151652-0user.microapp.ToExtVXML[4]Date=3/18/2016user.microapp.app_media_lib..user.microapp.ToExtVXML[3]Language=EN;RNA=0;EWT=EWT5user.microapp.FromExtVXML[1]S1234567D|T1234567Juser.microapp.caller_inputTuser.microapp.FromExtVXML[2]WIS_PQuser.cvp_server_info10.182.30.104user.microapp.UseVXMLParamsNVoiceTRANSFER_SSTCONSULT_CALLHOLDUPDATE_CALL_DATASEND_DTMFDROP14162016-03-18T08:39:41.410ZACTIVE2016-03-18T08:39:41.410ZTRANSFER_SSTCONSULT_CALLHOLDUPDATE_CALL_DATASEND_DTMFDROP1410AGENT_DEVICE2016-03-18T08:39:54.532ZACTIVE2016-03-18T08:39:54.532ZACTIVE2900/finesse/api/Dialog/16800324PUT/finesse/api/Dialog/16800324","object":{"Update":{"data":{"dialog":{"associatedDialogUri":null,"fromAddress":"1416","id":"16800324","mediaProperties":{"DNIS":"1415","callType":"TRANSFER","dialedNumber":"2900","outboundClassification":null,"callvariables":{"CallVariable":[{"name":"callVariable1","value":"Y|Y|N|EN|2900"},{"name":"callVariable2","value":"S1234567D|T1234567J"},{"name":"callVariable3","value":"CC_Code_1_1_PQ"},{"name":"callVariable4","value":"219-151652-0"},{"name":"callVariable5","value":"1416"},{"name":"callVariable6","value":"EN"},{"name":"callVariable7","value":"2981"},{"name":"callVariable8","value":null},{"name":"callVariable9","value":null},{"name":"callVariable10","value":null},{"name":"user.microapp.ToExtVXML[0]","value":"application=EnableCSS"},{"name":"user.microapp.FromExtVXML[0]","value":"Y|Y|N|EN|2900"},{"name":"user.microapp.error_code","value":"0"},{"name":"user.media.id","value":"E72871800001000000000042691EB60A"},{"name":"user.microapp.isPostCallSurvey","value":"Y"},{"name":"user.microapp.metadata","value":"N|000|01|00|00|007675|GS,Server,V,interrupt"},{"name":"user.microapp.ToExtVXML[2]","value":null},{"name":"user.microapp.FromExtVXML[3]","value":null},{"name":"user.microapp.ToExtVXML[1]","value":"CallId=219-151652-0"},{"name":"user.microapp.ToExtVXML[4]","value":"Date=3/18/2016"},{"name":"user.microapp.app_media_lib","value":".."},{"name":"user.microapp.ToExtVXML[3]","value":"Language=EN;RNA=0;EWT=EWT5"},{"name":"user.microapp.FromExtVXML[1]","value":"S1234567D|T1234567J"},{"name":"user.microapp.caller_input","value":"T"},{"name":"user.microapp.FromExtVXML[2]","value":"WIS_PQ"},{"name":"user.cvp_server_info","value":"10.182.30.104"},{"name":"user.microapp.UseVXMLParams","value":"N"}]}},"mediaType":"Voice","participants":{"Participant":[{"actions":{"action":["TRANSFER_SST","CONSULT_CALL","HOLD","UPDATE_CALL_DATA","SEND_DTMF","DROP"]},"mediaAddress":"1416","mediaAddressType":null,"startTime":"2016-03-18T08:39:41.410Z","state":"ACTIVE","stateCause":null,"stateChangeTime":"2016-03-18T08:39:41.410Z"},{"actions":{"action":["TRANSFER_SST","CONSULT_CALL","HOLD","UPDATE_CALL_DATA","SEND_DTMF","DROP"]},"mediaAddress":"1410","mediaAddressType":"AGENT_DEVICE","startTime":"2016-03-18T08:39:54.532Z","state":"ACTIVE","stateCause":null,"stateChangeTime":"2016-03-18T08:39:54.532Z"}]},"state":"ACTIVE","toAddress":"2900","uri":"/finesse/api/Dialog/16800324"}},"event":"PUT","requestId":null,"source":"/finesse/api/Dialog/16800324"}}} 2016-03-18T16:21:41.220 +08:00: : ipcclabfin.ipcclab.lab.com: Mar 18 2016 16:39:54.641 +0800: CallControl : _processCall(): Process the dialog with id: 16800324, to extension: 2900, from extension: 1416, call state: ACTIVE, callType: TRANSFER 2016-03-18T16:21:41.240 +08:00: : ipcclabfin.ipcclab.lab.com: Mar 18 2016 16:39:54.661 +0800: CallControl : _processCall(): User's call state is: ACTIVE, user's state cause is: null 2016-03-18T16:21:41.272 +08:00: : ipcclabfin.ipcclab.lab.com: Mar 18 2016 16:39:54.693 +0800: Header : ------ Event queue is empty. ------ 2016-03-18T16:22:02.700 +08:00: : ipcclabfin.ipcclab.lab.com: Mar 18 2016 16:40:16.121 +0800: Header : Time Information - UTC: 'Fri, 18 Mar 2016 08:22:02 GMT'; Local Time: 'Fri Mar 18 2016 16:22:02 GMT+0800 (Malay Peninsula Standard Time)'
03-24-2016 11:37 AM
Hi,
Sorry for not responding sooner. I didn't get a notification when you updated the log to this thread.
Can you attach the full files of the webservices log and client logs where you see Finesse getting the update from the cti server? I would like to see what Finesse is publishing when it gets the updated callvariable3 event. I need to pinpoint to see if it is a Finesse backend issue or a UI issue.
Thanx,
Denise
03-28-2016 06:11 PM
hi denise,
the log is huge.
can I email to you the file?
03-28-2016 10:45 PM
Hi,
People have attached log files to their replies. If you click the "Use Advanced Editor" link on the upper right of the reply box, an "Attach" link will appear in the lower right.
Thanx,
Denise
03-30-2016 10:56 PM
03-30-2016 11:49 PM
Hi Denise,
In the attached logs kindly look into the below log files only as it contains both the scenario i mentioned earlier.
Desktop-ClientLog.1001.2016-03-17T19-36-34.773
Desktop-ClientLog.1001.2016-03-17T19-38-36.441
Desktop-ClientLog.1001.2016-03-17T19-38-39.586
Desktop-webservices.2016-03-14T11-30-48.682.startup.log
Agent IDs are 1001 (ext 1415) and 1002 (ext 1410) caller number is 1416.
The call flow is 1416 to (1111 and VG convert it to 2900) VG to CVP to agent (1001) to transfer to queue via CTI route point (275x) to CVP to Agent (1002).
1. No agent available in the new queue, caller hear the queue music after that agent become available and answered the call. This case agent call the Call Variable3 updated with the new Queue name.
The problem is
2. If the agent is available in the new queue and answer the call then Call Variable3 does not update and agent see Old queue name.
03-31-2016 02:39 PM
Hi,
I did an analysis of the logs you provided and came to this conclusion:
In the scenario where there are no agents available (#1) and call variable 3 gets updated correctly,
If you notice, when Agent 1002 goes READY and gets the call with the updated call variable 3, the call id is different than the original and consult call, and the callType is PREROUTE_ACD_IN instead of TRANSFER. It seems like UCCE treats the call to Agent 1002 as a queued call and loses the transfer details.
In the scenario where Agent 1002 is available (#2) and call variable 3 doesn't get updated correctly,
If you notice, in this situation, the consult call is the one that gets its call variable 3 updated. Since the original call (almost) always survives, the updated call variable 3 gets lost.
UCCE is sending Finesse the events like this, so Finesse is just reading in these events and processing it. There isn't anything Finesse can do in this situation. If it is a problem for you, you have to chase the issue with the UCCE/PCCE team.
I have attached my notes (copies of log snippets from the webservices logs) to come to this conclusion.
Thanx,
Denise
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide