10-21-2019 07:54 AM
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?
Solved! Go to Solution.
10-22-2019 08:15 AM - edited 10-22-2019 08:18 AM
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:
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
10-22-2019 11:18 AM - edited 10-22-2019 11:58 AM
"...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:
And the logs showing that the first Agent where we failed to connect to them, both:
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.
10-22-2019 05:57 AM
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:
Hope this helps.
-Sean
10-22-2019 06:36 AM
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
10-22-2019 07:19 AM
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
10-22-2019 08:15 AM - edited 10-22-2019 08:18 AM
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:
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
10-22-2019 08:51 AM
Thanks Sean - really useful info.
10-22-2019 11:18 AM - edited 10-22-2019 11:58 AM
"...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:
And the logs showing that the first Agent where we failed to connect to them, both:
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.
10-22-2019 03:53 PM
...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
10-22-2019 08:55 PM
01-05-2023 05:10 PM
Hey Anthony, now that you work for Cisco
<ducks>
01-05-2023 10:03 PM
It is unfortunate that all of my past posts now look like a Cisco Employee wrote them.
10-22-2019 12:18 PM
10-24-2019 02:51 AM
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.
10-24-2019 05:55 AM
Tell me more about this summit. I've never been to one.
10-24-2019 06:15 AM
Anthony have sent you a PM
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