cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2797
Views
21
Helpful
16
Replies

UCCX Select Resource and Connect steps query

James Hawkins
Level 8
Level 8

Hi,

In the CCX step reference guide there is a warning which states "Never insert a Goto step in the middle of a Select Resource step flow. (Doing so can cause an active agent to enter a Reserved state that can only be exited by logging out of the system.)"

I am getting some agent stuck in reserved issues with a script that I have written and I am wondering whether I have fallen foul of this issue.

 

In my script the Select Resource step has Connect set to No

The script then has a Set step that does some calculations to work out how how the caller queued for followed by a Set Enterprise Call Info step which passes the queuing time and some other stuff through to be presented in Finesse.

I then have a Connect step and under the Failed branch I use a Goto step to send the call back to the queue.

 

Is this setup ok? - I have also tried dequeuing the call, increasing the priority then using a Goto to queue it but see the same issues.

What is the best practice for the Connect > Failed branch?

2 Accepted Solutions

Accepted Solutions

Here are the links I mentioned.

The following explain the operational parameters for the "Select Resource" and "Connect" steps and branches:

https://developer.cisco.com/docs/contact-center-express/#!select-resource-step/select-resource-step

https://developer.cisco.com/docs/contact-center-express/#!connect-step/connect-step

Example scripts in script_repository\script_repository_902\ (select the link all the way at the bottom -- it's a .zip file containing many useful sample scripting examples) at:

https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-express/products-implementation-design-guides-list.html

The sample scripts in the script repository show examples of how to use the "Select Resource" step with the Connect option set to "No" and the Failed branch with the "Go To" step.  Review the scripts in the "release3" folder; script "BaseLineMesageCallback.aef" as an example...

This is how I found this, and started using it...  I also use this method for advanced resource selection (Agent and CSQ based...).

Sincerely,

Sean

View solution in original post

"...The Failed branch should GOTO (or go back to) the SELECT Resource step so the system processes can select another resource..."

Actually, that's not accurate. The Failed branch of the Connect step does not execute any steps at all, provided, there is at least one more ready resource who can be reserved. In which case, the Select Resource step becomes the active step in the script, and your Failed branch steps never execute. I'll see if I can put up evidence online about this, because it's come up a few times now, and I'd rather just show people, than keep explaining it. Here is a video showing it in action: https://youtu.be/kwEVBkka_Mo

 

In the meantime here's a screenshot of a sample script:

uccx-connect-failed-branch-example.png

 

And the logs showing that the first Agent where we failed to connect to them, both:

  1. Never executed the step inside of the Failed branch
  2. Didn't need a Goto step to help it back to the Select Resource step (the interruption handler did that for us).

Then the logs show that the second Agent we failed to connect to, which also happened to be the last Agent available in that moment, did execute the step inside the failed branch.  In which case, what you really want in that step is to go into the queue loop you've created for yourself, and not back to the Select Resource step.

 

13:16:25.055: Execute step of Task 32000615282 : Start
13:16:26.652: Execute step of Task 32000615282 : Accept (--Triggering Contact--)
13:16:27.319: Execute step of Task 32000615282 : Select Resource (--Triggering Contact-- from "QueueAlways")
13:16:30.851: Execute step of Task 32000615282 : Connect (--Triggering Contact-- to selected_resource)
13:16:49.412: Execute step of Task 32000615282 : Interruption Handler: Select Resource (--Triggering Contact-- from "QueueAlways")
13:16:53.034: Execute step of Task 32000615282 : Connect (--Triggering Contact-- to selected_resource)
13:17:04.770: Execute step of Task 32000615282 : Set did_this_get_set_to_true = true
13:17:07.964: Execute step of Task 32000615282 : End

PS To get script steps executed from logs, you can follow my steps here.

 

Try it for yourself, it's pretty obvious what happens during a reactive debug.  The step inside the failed branch will be highlighted in red, post the first failure, but if you've ever reactive debugged a script, you'll know that the step has not yet executed when it's red, it only executes after you step over it.  In which case, the next red step will be the Select Resource step.  Again, I'll see if I can make a short video for evidence of this.

View solution in original post

16 Replies 16

Sean Lynch
Level 7
Level 7

Unfortunately, YES you are creating your problem.  The Failed branch should GOTO (or go back to) the SELECT Resource step so the system processes can select another resource--and if another resource is NOT AVAILABLE, then the system can process the contact by sending it to the QUEUING branch:

2019-1022-simpleQueueExample.PNG

Hope this helps.

 

-Sean

 

Sean,

Thank you for responding to my query.I will test this and see if it resolves the issue.

Do you know of anywhere that this recommendation is shown in official Cisco documentation? - I have had someone else look at my script who thinks that the dequeue, increase priority then requeue is a valid option. TBH I prefer your option as it seems simpler.

Thanks

James

Yes, this is discussed in the Cisco official scripting development guides--where I learned it.  If I have some time, I'll try and find the exact reference, and post it.

 

 

-Sean

Here are the links I mentioned.

The following explain the operational parameters for the "Select Resource" and "Connect" steps and branches:

https://developer.cisco.com/docs/contact-center-express/#!select-resource-step/select-resource-step

https://developer.cisco.com/docs/contact-center-express/#!connect-step/connect-step

Example scripts in script_repository\script_repository_902\ (select the link all the way at the bottom -- it's a .zip file containing many useful sample scripting examples) at:

https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-express/products-implementation-design-guides-list.html

The sample scripts in the script repository show examples of how to use the "Select Resource" step with the Connect option set to "No" and the Failed branch with the "Go To" step.  Review the scripts in the "release3" folder; script "BaseLineMesageCallback.aef" as an example...

This is how I found this, and started using it...  I also use this method for advanced resource selection (Agent and CSQ based...).

Sincerely,

Sean

Thanks Sean - really useful info.

"...The Failed branch should GOTO (or go back to) the SELECT Resource step so the system processes can select another resource..."

Actually, that's not accurate. The Failed branch of the Connect step does not execute any steps at all, provided, there is at least one more ready resource who can be reserved. In which case, the Select Resource step becomes the active step in the script, and your Failed branch steps never execute. I'll see if I can put up evidence online about this, because it's come up a few times now, and I'd rather just show people, than keep explaining it. Here is a video showing it in action: https://youtu.be/kwEVBkka_Mo

 

In the meantime here's a screenshot of a sample script:

uccx-connect-failed-branch-example.png

 

And the logs showing that the first Agent where we failed to connect to them, both:

  1. Never executed the step inside of the Failed branch
  2. Didn't need a Goto step to help it back to the Select Resource step (the interruption handler did that for us).

Then the logs show that the second Agent we failed to connect to, which also happened to be the last Agent available in that moment, did execute the step inside the failed branch.  In which case, what you really want in that step is to go into the queue loop you've created for yourself, and not back to the Select Resource step.

 

13:16:25.055: Execute step of Task 32000615282 : Start
13:16:26.652: Execute step of Task 32000615282 : Accept (--Triggering Contact--)
13:16:27.319: Execute step of Task 32000615282 : Select Resource (--Triggering Contact-- from "QueueAlways")
13:16:30.851: Execute step of Task 32000615282 : Connect (--Triggering Contact-- to selected_resource)
13:16:49.412: Execute step of Task 32000615282 : Interruption Handler: Select Resource (--Triggering Contact-- from "QueueAlways")
13:16:53.034: Execute step of Task 32000615282 : Connect (--Triggering Contact-- to selected_resource)
13:17:04.770: Execute step of Task 32000615282 : Set did_this_get_set_to_true = true
13:17:07.964: Execute step of Task 32000615282 : End

PS To get script steps executed from logs, you can follow my steps here.

 

Try it for yourself, it's pretty obvious what happens during a reactive debug.  The step inside the failed branch will be highlighted in red, post the first failure, but if you've ever reactive debugged a script, you'll know that the step has not yet executed when it's red, it only executes after you step over it.  In which case, the next red step will be the Select Resource step.  Again, I'll see if I can make a short video for evidence of this.

...as I said in my earlier post, sample scripts in the Cisco repository demonstrate this method--consistently, on multiple scripts. Perhaps this is a best practice?  Maybe.  Maybe not.  I didn't publish any of the scripts in the repository.  I borrow from them liberally, though.  ;-)

They do not ever demonstrate using a "Go To" step to a label in the event of a "Connect" step "failed" branch outcome. 

I do not think a new "Resource Select" process will happen correctly if this is done.  Just because the script allows the path of the contact to "jump to/go to" a different place in the flow--I don't think it will properly register with the resource selecting mechanisms in the program that cause it to drop down into the queue branch or selected branches by design.  The goal is to get the contact connected to a resource; queued if none are available.  Does this make any sense?  Putting a "Go To" step in the failed branch of the "Connect" step and dropping it in the "Queue" branch of the "Select Resource" step, to me, is illogical.

I haven't done this, but I may try it in my lab just to see what happens -- <reserved>...  

YMMV

-Sean

Actually you were pretty blunt, telling the OP they were doing it wrong and causing their own problem, and that's false.

Also, there is a lot wrong with Cisco's scripts, and the documentation of the scripts/steps.

This is an open invitation for Cisco to reach out to me. I can fix all of the sample scripts, modernize them, and correct the documentation. Heck, I'll even fix the API documents too, since those are also junk.

Hey Anthony,  now that you work for Cisco

<ducks>

It is unfortunate that all of my past posts now look like a Cisco Employee wrote them.

Anthony Holloway
Cisco Employee
Cisco Employee
Basically, you just don't want to use the Select Resource step, and then never ever use the Connect step. The Agent selected will be stuck in the reserve state. It's that simple. Of course you can use a Goto step in there, just as long as, at some point, you then also use the Connect step to actually ring the Agent's phone.

How you have it now, with the Goto in the failed branch, going to the Queuing area, is just fine.

Thanks Anthony,

I did some more troubleshooting and traced the issue that caused me to post this question to the fact that transferred calls to the application trigger number were be routed through a Translation Pattern rather than hitting the trigger directly - rookie mistake!

It would be really useful if Cisco took you up on your offer to optimise some of the sample scripts and API documentation.

I struggle with the latter - there are lots of cool things that could be done with the API but my enthusiasm wanes when things do not work as documented.

Do you ever attend the CCX Partner Summits that Cisco run? - they would be a good opportunity to pitch your offer to the CCX product management team.

 

Tell me more about this summit. I've never been to one.

Anthony have sent you a PM

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: