I have been chasing the root cause of this issue with TAC now. But I want to write an exception handler on the script that will catch this error because sometimes customers call in and get the " sorry we are currently experiencing system problems. " I would like to catch this error and throw the call back into the queued step. I am just trying to find out which exception class I should select from the list. Here is the error I'm getting below for this UCCX 11.5 SU3 single node server. I see an RNA message below but the phone was not busy at the time.
GMT %MIVR-SS_TEL-7-UNK:[MIVR_ENG_TASKS-31-17-TASK:0x684f0624b_Main/MainIVR_v3.aef] CallImpl: Call.transferFailed(519, RESOURCE_NOT_ACKNOWLEDGING) JTAPICallContact[id=46767,implId=1248447/5,state=STATE_ANSWERED_IDX,inbound=tru
%MIVR-SS_TEL-7-UNK:[MIVR_SS_TEL_TPG_EXE-40-339569-CALL_EVENT_LOG:1994206] RequestImpl: CallID:46767 MediaId:1248447/5 Task:28000150091 Got (P1-JTPI_1) 189309/1 TermConnDroppedEv UCCX-_1994206 [#7007629]
MIVR-SS_TEL-7-UNK:[MIVR_SS_TEL_TPG_EXE-40-339569-CALL_EVENT_LOG:1994206] RequestImpl: CallID:46767 MediaId:1248447/5 Task:28000150091 Got (P1-JTPI_1) 189309/1 TermConnDropped
PT-CCX-PORTS:1 [#7007632] Cause:100 CallCtlCause:100 CiscoCause:16 FeatReason:12, (P1-JTPI_1) 189309/1 CallInvalidEv [#7007633] Cause:100 CallCtlCause:0 CiscoCause:16 FeatReason:12, events on the AddressCallObserver.
MIVR-SS_CM-7-UNK:[MIVR_SS_RM_RmMsgProcessor-181-0-RmMsgProcessor] CTIPort: The Resource to which the transfer failed is murrn in CTIPort 1994206 .processSessionNotAnsweredMsg (46767, 85134527 [1248447/5
GMT %MIVR-SS_RM-7-UNK:[MIVR_SS_RM_RmMsgProcessor-181-0-RmMsgProcessor] RsrcMgrMsgProcessor: Processing msg: SessionCancelledMsg (Rsrc:1248447/5 Cause:SESSION_CANCELLED_CAUSE_DEST_RNA)
Can you please expand your script and provide a screenshot of your Consult Transfer step?
It looks like, the call exceeds the timeout value (default: 10 seconds) within the Consult Transfer step. If you already increased the timeout value, then perhaps you need to extend the timeout value again. Also, what happens when you analyze your script via Debug > Reactive Script? Which branch of the Call Consult Transfer step does it take (i.e. Successful, Busy, Invalid, Timeout or Unsuccessful)? And, what happens to the call under each outcome?
Honestly, there's no reason to handle this exception. From the list of default exceptions, this would likely be WFExectionException. However, if you knew this call was timing out... technically, you could reassign this call to another CSQ and then, loop this call back via GoTo step, prior to the Select Resource. Once you get into handling exceptions, you really need to understand what you're doing and all of the possible outcomes in which might invoke this exception because you can unknowingly cause problems with your scripts.
Please see an extract of the script below. To answer your question; I only do transfers during out-of-office hours. This exception happened when the queue was open. I thought if the Time-out occurred the call would come back to the queue node of the script. I've tried TAC with this in the past and no joy :-( so I want to catch the exception as a plan B before find root cause.
Please try the following first;
1. Increase the timeout value from 10 seconds to 20 seconds.
Remember, each ring cycle is roughly 4 seconds long - meaning, if the timeout value is 10 seconds, then callers and agents would only hear 2.5 ringbacks before the agent is placed into a Not Ready status. This is the default behavior when agents don't answer inbound ACD calls before the timeout threshold is reached. If so, the call is presented to the next agent or queued.
Typically, when do callers experience this problem? Less than a minute after reaching the queue? Couple of minutes? 15+ minutes?
2. (Optional) You can track connection failures between UCCE/UCCX and agents, using the Connect step. To do so, you need to create a new variable and add a couple of steps. Nothing big. Within your script, add the following;
User, SelectedResource, null
- Open the Select Resource step
> Connect = No
> Resource Selected = SelectedResource
//Under the 'Selected' branch of the Select Resource step, add the Connect step.
- Open the Connect step
> Resource Selected = SelectedResource
> Timeout = 20
Notice, the Connect step has two branches... Connected and Failed. Under Connected, place a GoTo label and send this call to the END of the script. Under Failed, create another variable to track and report these failures - if you want. If so, then place a GoTo label and send this call back to AgentAnswer for handling. If not, then you can open the Select Resource step and click on the label icon within this step to create a label back so you can send callers back to this step. Then, make sure the GoTo step is pointing to this label - that's all.
Waaayyyyyyyy back when, I had a problem with agents using unsupported phone features (i.e. DND and iDivert). If your agents have these phone features, remove them asap. Check the release notes if you haven't already done so... list of unsupported (supported) actions, configurations, features, etc.
Thanks Mark Swanson,
I like this action. I will implement this. I only see positives here. If this does not happen again in three months, I'll come back and give feedback so other can benefit from this too.
The WFExectionException catches ALL exceptions thrown by your script. Again, you must be extremely careful about using this exception because if you don't clear this exception and later on, your script throws an exception not defined by you... well, guess what... this call takes a detour.
This is just my humble opinion, it's better programming (scripting) to manage and properly distribute these calls rather than relying on exceptions to handle unknown errors. You don't want to cause loops within your scripts, right?
The problem is the the queue to agent step is simply a Cisco standard step. I have made no modifications here so it should , on paper, simply work.
Ok, what if i catch the error , transfer the call away from the primary script and into the secondary script . The secondary script would receive the queue name that the caller selected and queue the call again.
But you are correct, WFExectionException is far too general. I need the use the exception class that will catch my specific error. This is the class that I am trying to detrimin
What are you trying to accomplish by introducing a second script to only re-queue callers? This would add needless complexity to your overall design and likely, you would introduce other problems... not to mention, metrics would be impacted. Right now, your metrics is likely skewed if you really think about it. How much, well, that depends on how often this problem occurs and how your script handles these events.
If you loop calls back to the Select Resource step via script exceptions or GoTo labels after the results of Transfers or Redirects. This counts as 1 presented call(s) and 0 handled call(s). When you loop calls back, the same call event is counted again... 2 presented call and perhaps, 0 handled call(s). This doesn't resolve the problem. We simply created another problem... incorrect metrics.
Can you enable a couple of DEBUGS? Login to CCX Serviceability, under Trace > Profile... check and enable the "CallStuckInQueue" profile. These debugs should be good enough to troubleshoot this problem.
And, one more thing... please make sure ALL of your steps (i.e. prompts, delay, etc.) in the queue are interruptible.
validation shows no errors. It's worked for almost year with zero issues. now its gone crazy on me.
Have you recently upgraded? In your original post, you mentioned UCCX v11.5 SU3 but I think you meant to say v11.5(1) ES3 - right? Unless this was a typo and perhaps you're running v10 something. If you recently upgraded, you should open and save ALL of your scripts with the new editor if you jump versions.
Did you review the script changes I proposed? The transferFailed "RESOURCE_NOT_ACKNOWLEDGING" is generally caused by agents allowing the Select Resource (or Connect) step to exceed the timeout value. If your timeout value is 10 seconds, agents have a small window to answer calls. As I previously suggested, I recommend changing the timeout value to 20 if you haven't already done so.
Like most call centers, you likely have good agents and bad agents. Perhaps a high turnover rate as well. Maybe this wasn't a problem before because your helpdesk had enough 'good' agents on staff, agents were trained and regularly received training, and supervisors monitored/evaluated agent activity. Unfortunately, we can only resolve some of these problems but other problems must be resolved by the helpdesk (supervisors or upper management).