Genesys CTI User Forum

Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: Gef Buneri on March 26, 2019, 04:02:17 PM

Title: Best practice for Call Piority change on already queued call (URS 7.5)
Post by: Gef Buneri on March 26, 2019, 04:02:17 PM
Hi all,
what is the best method to change priority for an already queued call (VQ)?

SelectDN[VQ,PRIORITY,AG] method is used for first target selection, then a SuspendDN[TARGET] is used to drop call at a certain point to change some parameters: Priority, target VQ or target AG.

How I should recompose/mantain target changing some parameters?


Best regards,


Gef.


Title: Re: Best practice for Call Piority change on already queued call (URS 7.5)
Post by: cavagnaro on March 26, 2019, 08:35:08 PM
???  IncreasePriority Function?
Title: Re: Best practice for Call Piority change on already queued call (URS 7.5)
Post by: Gef Buneri on March 27, 2019, 08:02:30 AM
Hi Cav. Yes of course that function works, but it does manage the increment of a certain value every N time interval, but I'm looking to set a specific new priority value from a var, in a specific moment.

Thinking about to invoke the Priority function after the SuspendDN interval, but it seems it does not affect the priority for an already queued call, if the target selection was done using SelectDN.

At the moment, I'm using IncreasePriority function setting the INCREMENT value as ('NEW PRIORITY VALUE' - 'OLD PRIORITY VALUE') if the difference is a positive number and a very long time as interval value, but this works for a priority increment; no way to decrease it. And it seems the IncreasePriority does not execute the increment at the first call, but only at interval's end.
Title: Re: Best practice for Call Piority change on already queued call (URS 7.5)
Post by: Janis on March 27, 2019, 10:09:25 AM
I'm using SetVQPriority[VQ_name,intPriority] while suspending for DN after SelectDN.
Title: Re: Best practice for Call Piority change on already queued call (URS 7.5)
Post by: Gef Buneri on March 27, 2019, 10:53:52 AM
Thank you Janis. Though, according to the URS documentation, the SetVQPriority influences the calls on that specific VQ, but not at global level; I'f I'm not wrong, this does mean that the specified priority isn't matched with other VQ when more VQs are pointing to the same group. Can you confirm?
Title: Re: Best practice for Call Piority change on already queued call (URS 7.5)
Post by: Janis on March 27, 2019, 12:12:37 PM
Didn't test it very carefully. I hope that agent will get the interaction with highest priority, including when it is set with SetVQPriority[]. Let us know if your tests showing different behavior.

In Knowledge Base I found following reply to question about priorities:

"[i]Sorry I don't know any "global priority" or "interaction priority". There is just a call priority. It can be changed by several functions:
- Priority - this function just changes a call priority. Please, note that the place of call in queues is not adjusted! The new priority will affect only place of the call in new queues where the call will be applied.
- Increment - this function increments a call priority and the place of the call in queues is adjusted.
- SetVQPriority - this function changes a call priority for concrete VQ and adjusts the place of the call in all corresponding internal queues.[/i]"
Title: Re: Best practice for Call Piority change on already queued call (URS 7.5)
Post by: Janis on March 27, 2019, 12:18:53 PM
Another article from Knowledge Base. According to it Priority[] is setting some default value which will be assigned when interaction will enter the queue.

[i][b]Question Detail[/b]
What are Internal Queue's in URS?
[b]Answer[/b]
Explanation on Internal Queue.
--------------------
When you select some target set (agent group, skill expression, etc.) for a call and specify a VQ for it, URS creates an internal queue, which is identified by target set name + VQ name, and puts the call into this queue according to its current default priority (the default priority is set by Priority[] function). If an internal queue with such identifier already exists, URS is using existing one.

For example, you put a Call1 to wait for AG1 target in VQ1, then you put this call to wait for AG2 target also in VQ1. Internally URS creates two queues: AG1+VQ1 and AG2+VQ1. In every of these queues the call took its position according to its default priority. When you call a SetVQPriority function for this call in VQ1, URS will recalculate the call position in all internal queues having the "VQ1" in the identifier (both AG1+VQ1 and AG2+VQ1 in our case)  and save the specified priority (N) for this call in these internal queues (please note that the default call priority is not changed by SetVQPriority call). Continuing our example, a Call2 has arrived and is put to wait for AG3 target in VQ3 and AG4 target in VQ4, URS creates two more internal queues (AG3+VQ3 and AG4+VQ4) and puts the call into these queues. Some agent become ready and this agent belongs to, for example, AG1 and AG4. URS takes the call from the head of every internal queue having the AG1 or AG4 (AG1+VQ1 and AG4+VQ4 in our case) and routes the call having the highest N number.
--------------------[/i]
Title: Re: Best practice for Call Piority change on already queued call (URS 7.5)
Post by: Gef Buneri on March 27, 2019, 01:01:09 PM
Very useful Janis, thank you very much.