cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5238
Views
20
Helpful
9
Replies

UCCX aborted calls Issues

mightyking
Level 6
Level 6

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

 

2 Accepted Solutions

Accepted Solutions

uccx-aborted-user-null.png

 

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

View solution in original post

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.

View solution in original post

9 Replies 9

marshs
Level 1
Level 1
you say some days, are these busy times? is it reaching the call control group limit? check for errors in rtmt for application aborted messages in the syslog

 

 

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

 

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?

Hi Mark,

Thank you for replying. Please find attached the script.

 

MK 

uccx-aborted-user-null.png

 

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

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

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.

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: