[cisco-voip] Check on calls in queue for a team?

Fri Mar 23 16:39:59 EDT 2018

If I understand correctly your goal is to check for any queue to have more
than 3 contacts waiting, and if so; dial a phone number that rings a light.
What I am unsure of is if the light remains on after the connection is made
(picks up) or if it is only on during the ring phase. Depending on the
answer to that you will modify the script accordingly (longer ring timeout,
or a delay in the success branch).

You've already got the logic for checking the contacts in queue, 22 IF
statements is kind of crazy and of course there are better ways to go about
it but if that setup is maintainable for you that matters most.

Here's what I propose for your situation that doesn't require insane
amounts of state management and session manipulation.

First, create a new script. Add a variable, type = "Throwable", name =
"tError";
Drag a Get Trigger Info step to the script, set Aborting Reason to your
tError variable

Next, insert an IF node with the expression tError != null, under the true
branch insert an Trigger Application step configure it as shown below,
substituting "MyAppName" for a variable name (String type, mark as
parameter). After the Trigger Application step insert an End (so all
branches end). See below

Under the false node do nothing, we'll simply end. Now, save this
application as Catch_Errors.aef, upload it to the script repository

Now create a new application, this one is where you will put your 22 IF
nodes and dialing logic. See below for an example. What you want to node
here is the label placement and the looping. This is intentional.

Once completed, save your application to the Script repository. Call it
MagicLight.aef

Next, create a new application, perhaps call it "Magic Light" (I'll use
that for this example).

Select the Might Light script, put Max Sessions to 2 (screen shot below is
wrong).

Next, before hitting SAVE or anything else, under the "Default Script"
select the Catch_Errors script you saved a moment a go. Now here is where
you will enable the parameter and as a string put the name of the
application; in this example we'd use "Magic Light"
See below

Congratulations, you've just created a recursive application! Now some of
you are thinking, won't that run forever? won't that hit the max step
count?! YES! That's what we want it to do.

This setup works by checking the queues and dialing the light number when
there is a match to the desired logic and repeats again. This avoids
needing to make any changes to existing scripts, or troublesome 'race
conditions'. This also avoids the ugliness of managing session state and
the concurrency problems that goes along with it.

If you put this logic in your application script (invoked by your
customers), you could have dozens of scripts invoking the same logic all at
the same time; dozens of scripts calling your light all at once. That's not
ideal!

This application runs forever, and when it hits the max step count, it
invokes the default script "Catch_Errors" which ensures it was invoked due
to an error, then restarts the process. To put it simply, when the main app
crashes due to step count, this app restarts it.

Now you could be wondering, what if I want to shut it down? Well, all you
have to do is uncheck "sAppName" (in the above example) and it won't
restart the app any more.

What about all those extra resources when running an application this long?
Truthfully, its trivial. The memory impact to this is less than 100kb. If
your call center is under such strain you have other concerns.

Isn't running until the max steps exception is thrown bad? No. This limit
exists as a way to prevent tasks from endlessly looping and running up the
CPU.

*Now that is out of the way, I should  mention that you should put a Delay
on your very last IF node, something like Delay 60, this will cause the
script to check the queues once a minute and prevent the CPU from going
nuts.*

So last but not least you might be wondering, how do i invoke my new
script? Well, you could assign a trigger to do so, this is certainly the
easiest. The other alternative (how i tested all the above) is to create a
quick throwaway script with the Trigger application step, and run it:

So there you have it, with a little bit of setup and know-how you can avoid
all the ugliness of state management, race conditions and concurrency
issues in a neat little package leaving your main applications free from
clutter.

Happy hacking!

Regards,
Tanner Ezell

On Fri, Mar 23, 2018 at 11:29 AM, Anthony Holloway <
avholloway+cisco-voip at gmail.com> wrote:

> First, this is 6 of one, half dozen of the other.
>
> Second, let's agree that with the If statement, and likely any solution,
> there is a race condition, such that by the time you're pulling and
> checking the 22nd CSQ metric, volumes could have changed in the other 21
> CSQs, so you may decide to light the light incorrectly.
>
> Ok, so with that out of the way, perhaps you could still use the hashmap
> and global sessions, but then you track one more metric which is and
> increment/decrement of calls in queue for each team.  Yes, the reading,
> manipulating, and storing of that metric could result in a race condition,
> but no worse than what you're already doing.
>
>
> On Fri, Mar 23, 2018 at 10:21 AM Matthew Loraditch <MLoraditch@
> heliontechnologies.com> wrote:
>
>> Well my biggest problem is I’ve never done it and have no idea how to do
>> it. I see some stuff here: https://supportforums.cisco.
>> com/t5/contact-center/uccx-custom-classes-arraylist-usage/td-p/2633938
>>
>> That I sort of get..
>>
>>
>>
>> But the Call Center manager just brilliantly decided he only wants things
>> lit if 3 or more calls exist for the team (which actually makes more sense
>> from a usage standpoint). I feel like this may make the hashmap idea non
>> workable?
>>
>>
>>
>>
>>
>>
>> Matthew Loraditch
>> Sr. Network Engineer
>> p: *443.541.1518* <443.541.1518>
>> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>  |
>> e: *MLoraditch at heliontechnologies.com*
>> <MLoraditch at heliontechnologies.com>
>> [image: Facebook] <https://facebook.com/heliontech>
>> [image: Twitter] <https://twitter.com/heliontech>
>> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>> *From:*
>>
>> Anthony Holloway <avholloway+cisco-voip at gmail.com>
>> *Sent:* Friday, March 23, 2018 10:43 AM
>>
>>
>> *To:* Matthew Loraditch <MLoraditch at heliontechnologies.com>
>> *Cc:* Bill Talley <btalley at gmail.com>; cisco-voip at puck.nether.net
>> *Subject:* Re: [cisco-voip] Check on calls in queue for a team?
>>
>>
>>
>> You may not like this solution, but I think you could just use a HashMap
>> to map your CSQs to Teams, and then another HasMap to map your Teams to
>> Light Directory Numbers.  Then use global sessions to track if a light is
>> currently being lit for a team or not.  Limit your checking to PIQ === 1
>> and that should be pretty efficient and easy to administer....which is
>> relative.
>>
>>
>>
>> On Thu, Mar 22, 2018 at 2:53 PM Matthew Loraditch <MLoraditch@
>> heliontechnologies.com> wrote:
>>
>> The light needs to be on if ANY queue for the team has a call in it.
>>
>> We have around 40 queues. One team has 22 CSQs assigned.
>>
>>
>>
>> So my logic was call the app once we have a call form the main script,
>> ring the light, hang up and then check all the queues once any queue has
>> contacts waiting > 0, call and begin again. I can’t keep the call ongoing
>> as I have no way to break in and terminate it.
>>
>>
>>
>> So it’s if CSQ1 has calls, call light if not check CSQ2 and so on.
>>
>>
>>
>> Am I being crazy?
>>
>>
>>
>>
>>
>> *Matthew Loraditch***
>>
>> *Sr. Network Engineer*
>>
>> p: *443.541.1518* <443.541.1518>
>>
>> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>>
>>  |
>>
>> e: *MLoraditch at heliontechnologies.com*
>> <MLoraditch at heliontechnologies.com>
>>
>> [image: Facebook] <https://facebook.com/heliontech>
>>
>> [image: Twitter] <https://twitter.com/heliontech>
>>
>> [image: LinkedIn] <https://www.linkedin.com/company/helion-technologies>
>>
>> *From:* Anthony Holloway <avholloway+cisco-voip at gmail.com>
>> *Sent:* Thursday, March 22, 2018 3:50 PM
>> *To:* Matthew Loraditch <MLoraditch at heliontechnologies.com>
>> *Cc:* Bill Talley <btalley at gmail.com>; cisco-voip at puck.nether.net
>>
>>
>> *Subject:* Re: [cisco-voip] Check on calls in queue for a team?
>>
>>
>>
>> Why so many conditionals?
>>
>>
>>
>> If you're simply trying to map a CSQ name to an Extension to call, you
>> could use a HashMap.
>>
>>
>>
>> Link for example usage of HashMap
>>
>>
>>
>> https://supportforums.cisco.com/t5/contact-center/route-
>> customer-call-to-a-specific-agent-based-on-calling-number/td-p/2176574
>>
>>
>>
>> On Thu, Mar 22, 2018 at 1:45 PM Matthew Loraditch <MLoraditch@
>> heliontechnologies.com> wrote:
>>
>> It’s a sip phone, it lights on a ring or on a call.
>>
>>
>>
>> I managed to program the nearly 40 nested ifs (broken up into 3 copies of
>> the script) in about 30 minutes. So I guess I’m done for now in that
>> respect. If I could make it more programmatic I might. I’ve done no API
>> work, so not sure if that would work or not or be any easier.
>>
>>
>>
>>
>>
>> *Matthew Loraditch***
>>
>> *Sr. Network Engineer*
>>
>> p: *443.541.1518* <443.541.1518>
>>
>> w: *www.heliontechnologies.com* <http://www.heliontechnologies.com/>
>>
>>  |
>>
>> e: *MLoraditch at heliontechnologies.com*
>> <MLoraditch at heliontechnologies.com>
>>
>> <https://facebook.com/heliontech>
>>
>> <https://facebook.com/heliontech>
>>
>> <https://facebook.com/heliontech>
>>
>>
>> *From: Bill Talley <btalley at gmail.com> <https://facebook.com/heliontech>*
>>
>> *Sent: Thursday, March 22, 2018 2:22 PM <https://facebook.com/heliontech>*
>>
>>
>> *To:* Matthew Loraditch <*MLoraditch at heliontechnologies.com*>
>> *Cc:* *cisco-voip at puck.nether.net*
>> *Subject:* Re: [cisco-voip] Check on calls in queue for a team?
>> <https://facebook.com/heliontech>
>>
>>   <https://facebook.com/heliontech>
>>
>> I’m behind all of the emails but am curious about how the light gets
>> triggered.  Is it a SIP device registered to CUCM or how does that work?
>>  What version of CCX are you running? <https://facebook.com/heliontech>
>>
>> I’m wondering if you could do a REST call to the CCX database for
>> contacts waiting and parse the XML?  Might be easier to capture the data
>> that way? <https://facebook.com/heliontech>
>>
>> Sent from a mobile device with very tiny touchscreen input keys. Please
>> excude my typtos. <https://facebook.com/heliontech>
>>
>>
>> On Mar 22, 2018, at 11:20 AM, Matthew Loraditch <
>> *MLoraditch at heliontechnologies.com*> wrote:
>> <https://facebook.com/heliontech>
>>
>> I'm setting up that light system I’ve talked about and the managers wants
>> their lights to come on if any queue assigned to a team has calls waiting.
>> I can't think of any way to do that but iterate through every queue in a
>> very long nested if of get reporting statistics steps and anytime we add a
>> queue I will have to modify the script...
>> <https://facebook.com/heliontech>
>>
>>   <https://facebook.com/heliontech>
>>
>> One team has 22 queues assigned… <https://facebook.com/heliontech>
>>
>>   <https://facebook.com/heliontech>
>>
>> If anyone has a better idea, I'd love to hear it!
>> <https://facebook.com/heliontech>
>>
>>   <https://facebook.com/heliontech>
>>
>> *Matthew Loraditch <https://facebook.com/heliontech>*
>>
>> *Sr. Network Engineer <https://facebook.com/heliontech>*
>>
>> p: *443.541.1518* <https://facebook.com/heliontech>
>>
>> w: *www.heliontechnologies.com* <https://facebook.com/heliontech>
>>
>>  |  <https://facebook.com/heliontech>
>>
>> e: *MLoraditch at heliontechnologies.com* <https://facebook.com/heliontech>
>>
>> <image905466.png> <https://facebook.com/heliontech>
>>
>> <https://facebook.com/heliontech>
>>
>> <https://facebook.com/heliontech>
>>
>> <image374618.png> <https://facebook.com/heliontech>
>>
>> <https://facebook.com/heliontech>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> *cisco-voip at puck.nether.net*
>> *https://puck.nether.net/mailman/listinfo/cisco-voip*
>> <https://facebook.com/heliontech>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> *cisco-voip at puck.nether.net*
>> *https://puck.nether.net/mailman/listinfo/cisco-voip*
>> <https://facebook.com/heliontech>
>>
>>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180323/f0f2d6f4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2018-03-23 13.12.47.png
Type: image/png
Size: 58225 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180323/f0f2d6f4/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2018-03-23 13.15.20.png
Type: image/png
Size: 39791 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180323/f0f2d6f4/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2018-03-23 12.55.09.png
Type: image/png
Size: 32406 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180323/f0f2d6f4/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2018-03-23 13.35.44.png
Type: image/png
Size: 27496 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180323/f0f2d6f4/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2018-03-23 12.57.32.png
Type: image/png
Size: 57292 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20180323/f0f2d6f4/attachment-0004.png>