Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: Gef Buneri on December 06, 2012, 08:27:35 AM
-
Hi all, I need to route incoming calls to a specific agent (variable) when in particular circumstances.
At the moment I'm using a SelectDN block to try to reach the goal, using this syntax:
SelectDN[VQ001,GetPriority[],'',StatSelectAny,AG001,'','','','','','','','','']
Where VQ is a Virtual Queue object VQ_XXXX like, and AG001 is a xxxx@StatServer75URS.A, but URS seems to not like this last object, telling me the target is not good.
Any tips ?
Regards,
Gef.
-
Why do you not use standard routing block in IRD strategy?! You can set use it and as a target variable with an agent,same is for queue,wait time,etc
-
Hi Kubig, thanks for the answer. Usually I use this method cause in this way interaction continues and I can write down some data in a DB object after the target selection (agent, dn, station, etc.). With the Target Selection usually this can't be done; am I wrong ?
-
Yes, you are wrong. After "selection properties" the strategy continues to the "stop/end" mark.
-
Oh, nice, I'll try this way. In the Target Selection block if I select a variable as target type or virtual queue, I can't use the block to specify other parameters as domain or name, so what is the right syntax for agent and vq ?
agent@statserver.A and vq@statserver.Q ? Or what ?
-
Target format:
[i]targetname[/i]@[i]statservername[/i].GA - for Group Of Agent,A - for agent
Queue format:
queuename without statserver and other parameters
-
Just in case:
- For agents targetname (if specified as targetname@statserver.A or just as targetname.A) is agent's employee ID.
- Agent of course should be ready (no force routing here).
- probably the main limitation for after "Target Selection" - often not possible to attach data to the call, but
operations not related with call (writing to data base for example) are OK.
-
Ok, test done. The routing works finely and as said by Kubig, the interaction goes on and I can write down data to DB. Thanks Kubikle for the detailed tips, I'll test soon the loss of data attachment capability cause we use call transfert service through a dedicated IRD application to route call from an area to another, manipulating some attached data to mantain a call history. Another thing I lost using Target Selection instead of SelectDN, is the destination agent's place name ad a result to this function GetStringKey['place',DESTINATION] where "DESTINATION" is the result of the usual SelectDN function. At the moment, after target selection I no longer have a result from that function.
Any tips ?
-
I am not testing it now,but I think,that you can get this information from attach data,may be it exists any method in IRD..?
-
Gef,
Please look at TargetSelected, TargetObjectSelected, TargetComponentSelected IRD functions that may provide you with information you're after.
R.
-
Thanx Renč, at the momenty I already use that functions, but:
- TargetSelected[] : Ok, gives me the DN (extension).
- TargetComponentSelected[] : Ok, gives me the agentid.
- TargetObjectSelected[] NOK, gives me the agentid again.
-
I think that is ok,cause agentid is selected object.
-
Yes it is, Kubig. Still the "missing place info" remains :D
-
I did quick test and if URS is configured to attach target details (report_targets = true) then it's possible to read 'RTargetPlaceSelected' user data key after call is routed (=leaves Selection block via green port).
If report_targets is disabled and you have URS 8.1.1 (or newer) then you can use FindConfigObject function to find out place to which target DN belongs to.
R.
-
And what problem is create place name from extension,which you get from TargetSelected function?
-
@René: We use URS 7.5. @Kubig: Sadly, in our configuration the extension corresponds to the station phone number, the PLACE to the agent workstation's hostname. Using the SelectDN function I can CAT: STATION(extension):AGENTID:PLACE(WORKSTATION HOSTNAME), using Target Selection, seems I can't.
-
With old URS versions using of ExtensionData['PLACE'] after target selection might help (not related with report_targets option setting).
Also I think original SelectDN aproach also should work (target to be used supposed to be the same as in target selection object) -
if it doesn't then URS logs need to be checked for exact reason - unlikely it is because of target specification.
-
@Kubikle Using SelectDN method with the same targeting object results in a "target too old or invalid" when the function result is used to route call. I'll try the ExtensionData too and will make you know.
***EDIT***
@Kubikle, oh maybe you intended me to use the SelectDN only to extract the PLACE info ?
-
Gef - I believe Rene has the right idea. After the target block just try to read the value of the key 'RTargetPlaceSelected' ( I believe the spelling is correct ). In the event that it is trying to read the key before URS updates it, you may have to proceed it with a WaitForEvent['EventRinging'] before you get the value.
-
The ExtensionData['PLACE'] function after the arget Selection worked like a charm :) it gives the real place wich agentid depends from at the moment of the target selection.
Ok, I think I can write the "solved" word on this post :) Thanxalot to all of you, really.
-
Lets refine the question...
I'm using a scenery with a "ladder" Target Selection sequence. The interaction reaches the 1st step of the ladder:
1 - Target Selection using "VQ001 - AGENT001": TARGET001 is free ? - Yes: Distribute call to target.
- No: Let's try another target.
2 - Target Selection using "VQ001 - AGENT002": TARGET002 is free ? - Yes: Distribute call to target.
- No: Let's try another target.
3 - Target Selection using "VQ001 - AGENT003": TARGET003 is free ? - Yes: Distribute call to target.
- No: Let's try another target.
4 - SelectDN "VQ001 - AGENTGROUP" and stay in queue till 1st Agent free.
This causes each interaction to generate both CallEntered and CallCleared events each failed Select Target, so in case first three steps are negative I'll have 4 CallEntered and 3 CallCleared events on VQ001 Stats...
There's a way to avoid this ?
***EDIT***
Was thinking about a "check if the agentid is in ready state before continuing" function, but no idea about how to.
***EDIT***
Tracing strategy using IRD visual trace, I can see there are times the interaction does not comes out from the Target Selection block, in wich conditions this may happen ?
-
Gef,
The easiest solution would be using SelectDN function or Selection block to report call on VQ before targeting agents.
1. SelectDN[VQ001] [i](do not specify any agent group as target or agent group that is always empty)[/i]
2. Target Selection using TARGET001 is free ? - Yes: Distribute call to target.
- No: Let's try another target.
...
R.
-
If the VQ is the same in all target selection obejcts then should be only single CallEntering (of course if Clear Target checkbox is unchecked).
-
Thanks guys.
I'm trying a sdata approach based on the agent:
sdata AGENT00X.A using StatAgentsAvailable, then if result is >= 1 (1 is the expected value on single agent) I send the interaction to the targeting block (Target Selection using queue+agent).
I'll let you know if all works fine.
-
All working fine. In this way the queue is engaged only if the resource is free.
Think I reached a fine working scenery... thanx again to all of you.