07-11-2019 07:25 AM
Hello Experts,
I have been having an issue for several months and I don't seem to understand why this is happening.
Some days the Aborted Rejected Call Detail Report shows that we have more than 100 aborted calls and they are all destined to a single CSQ. Please see the attached screenshot.
Anybody has any idea why this is happening? I have validated almost everythin including:
1) CCG
2) Partition and CSS
In the normal situation a calls falls into the Call Routed CSQ but in this case all aborted calls fall into Other CSQs.
Other CSQs means that If the call is put on hold (queued) in multiple CSQs. I don't seem to understand how a call can be quequed in more than one CSQ!
It would be very much appreciated if someone could shade some lights on this.
Thanks,
MK
Solved! Go to Solution.
07-12-2019 08:20 AM - edited 07-12-2019 08:26 AM
Your script is failing because the step inside of the Connected branch of the Select Resource step is referencing a null value for the user variable.
Two ways to fix this:
1) Like i've shown in the screen shot, put the user variable in the Select Resource step's Resource Selected property field
2) Delete the Get User Info step from the Connected branch, since it doesn't look like you're using it for anything meaningful anyway (Also, that's not a required step to make the script work, simply End is all that is needed)
You have some other problems with your scripting too, that I can see. For example, after the Connected branch is executed, and assuming you fixed the Get User Info step, you would mark the contact as handled, which is unnecessary, as it's already handled at this point, and then you attempt to terminate the contact, which actually throws another error, because the contact would already be terminated at this point. You only need to use the terminate step when you want to hang up on the caller, which, I can only think of like 1 or 2 good reasons you should ever do that. You should really let the caller decide when they're done interacting with you.
Bonus: Use exception handlers in your script to help save your script from aborting when errors like this occur. The On Exception WFExecutionException Goto step is the most powerful one, and I've written a lot about exception handling here: https://community.cisco.com/t5/collaboration-voice-and-video/uccx-discovering-exceptions/ta-p/3124590
07-15-2019 12:27 PM
The report only tells me two things:
1) Part of the exception message is "com.cisco.wfapi.WFExecutionException: Too many transfer failures"
This is definitely a different error than your previous error with the Get User Info step.
2) The Application the failure is happening in is, LQ_MIG_SUBLOFWS
I'm going to guess it's an Agent's DN which cannot be reached by UCCX. I know you said you checked the Partitions/CSS, but there could be something you missed.
If you share the script, I can look for improper handling of call redirects, but my guess is its with the Select Resource/Connect step.
I don't know how many Agents you have, or how busy your call center is, but one elementary way of testing this, is to have all Agents go Not Ready, and then one at a time, place a call to each Agent individually, by asking them to go Ready for you. I suspect one or more of them you will not be able to reach.
If the problem is intermittent, then it's possible it's a setting which gets changed semi-regularly. I'd check things like max calls/busy trigger on Agent ACD Lines, as well as Agent ACD Line forwarding, and possibly shared lines too.
07-11-2019 11:28 AM
07-11-2019 01:33 PM - edited 07-11-2019 01:35 PM
This is a similar error from RTMT. It does not mention the reason why the call has been aborted.
: 2962: SCCC50008P.XYZ-XYZ.com: Jul 01 2019 05:39:18 PM.193 UTC : %UC_APP_MGR-3-TASK_ABORTED: %[app.trigger=ContactApplicationTrigger[time=1562002731715,locale=fr_CA,cfg=JTAPITriggerConfig[schema=ApplicationTriggerConfig,time=2018-08-30 ][exception=com.cisco.wfapi.WFExecutionException: Task:37001837286 GetUserInfoStep: user: is NULL.][UNKNOWN_PARAMTYPE:Task id=37001837286][app=App[name=SEJQ_BINGO_PLUS,type=Cisco Script Application,id=0,desc=SEJQ_BINGO_PLUS,enabled=true,max=7,valid=true,cfg=[ApplicationCo][task.class=class com.cisco.app.impl.WFWorkflowAppDebugTaskWrapper][ClusterID=][NodeID=XYZ]: Application task aborted
Thaks,
MK |
07-11-2019 01:50 PM
Can we be facing the bug CSCvg01856?
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvg01856/?rfs=iqvred
Thanks,
MK
07-11-2019 07:18 PM
The problem was revealed in the error message;
: 2962: SCCC50008P.XYZ-XYZ.com: Jul 01 2019 05:39:18 PM.193 UTC : %UC_APP_MGR-3-TASK_ABORTED: %[app.trigger=ContactApplicationTrigger[time=1562002731715,locale=fr_CA,cfg=JTAPITriggerConfig[schema=ApplicationTriggerConfig,time=2018-08-30 ][exception=com.cisco.wfapi.WFExecutionException: Task:37001837286 GetUserInfoStep: user: is NULL.][UNKNOWN_PARAMTYPE:Task id=37001837286][app=App[name=SEJQ_BINGO_PLUS,type=Cisco Script Application,id=0,desc=SEJQ_BINGO_PLUS,enabled=true,max=7,valid=true,cfg=[ApplicationCo][task.class=class com.cisco.app.impl.WFWorkflowAppDebugTaskWrapper][ClusterID=][NodeID=XYZ]: Application task aborted
The WFExectionException was thrown because of the Get User Info step inside your SEJQ_BINGO_PLUS script. The script wasn't able to "execute" this step because the user value was NULL. What are you trying to do exactly?
07-12-2019 06:01 AM
07-12-2019 08:20 AM - edited 07-12-2019 08:26 AM
Your script is failing because the step inside of the Connected branch of the Select Resource step is referencing a null value for the user variable.
Two ways to fix this:
1) Like i've shown in the screen shot, put the user variable in the Select Resource step's Resource Selected property field
2) Delete the Get User Info step from the Connected branch, since it doesn't look like you're using it for anything meaningful anyway (Also, that's not a required step to make the script work, simply End is all that is needed)
You have some other problems with your scripting too, that I can see. For example, after the Connected branch is executed, and assuming you fixed the Get User Info step, you would mark the contact as handled, which is unnecessary, as it's already handled at this point, and then you attempt to terminate the contact, which actually throws another error, because the contact would already be terminated at this point. You only need to use the terminate step when you want to hang up on the caller, which, I can only think of like 1 or 2 good reasons you should ever do that. You should really let the caller decide when they're done interacting with you.
Bonus: Use exception handlers in your script to help save your script from aborting when errors like this occur. The On Exception WFExecutionException Goto step is the most powerful one, and I've written a lot about exception handling here: https://community.cisco.com/t5/collaboration-voice-and-video/uccx-discovering-exceptions/ta-p/3124590
07-15-2019 09:05 AM
Thanks Anthony,
Very helpful as always.
I am attaching a report that I got while ago which has 100+ aborted calls within few hours. They all have the same exception errors. The errors in the attached document are from a different script which has no Get User Info statement. What could be causing these many errors within few hours? I have already verified all Partitions, CSS, CCG etc...
Thanks,
MK
07-15-2019 12:27 PM
The report only tells me two things:
1) Part of the exception message is "com.cisco.wfapi.WFExecutionException: Too many transfer failures"
This is definitely a different error than your previous error with the Get User Info step.
2) The Application the failure is happening in is, LQ_MIG_SUBLOFWS
I'm going to guess it's an Agent's DN which cannot be reached by UCCX. I know you said you checked the Partitions/CSS, but there could be something you missed.
If you share the script, I can look for improper handling of call redirects, but my guess is its with the Select Resource/Connect step.
I don't know how many Agents you have, or how busy your call center is, but one elementary way of testing this, is to have all Agents go Not Ready, and then one at a time, place a call to each Agent individually, by asking them to go Ready for you. I suspect one or more of them you will not be able to reach.
If the problem is intermittent, then it's possible it's a setting which gets changed semi-regularly. I'd check things like max calls/busy trigger on Agent ACD Lines, as well as Agent ACD Line forwarding, and possibly shared lines too.
07-15-2019 12:55 PM
Thanks Anthony,
I see the script calling the LQ_MIG_SUBLOFWS has a Get User Info step. But Under Select Ressource step the Resource Selected field is blank. I guess by either removing this step or adding the user variable in the field the way you showed in your previous post will help to resolve this issue as well. Will try and let you know.
Thanks again,
MK
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