Number differences between ccp_statserver and datamart db number for VQs

[Adam G]

....sorry - another thought: It looks like CCP is logging on through a Config Proxy - perhaps try logging in centrally?  The proxy might be missing a trick...

[cavagnaro]

[quote author=Gef Buneri link=topic=9975.msg45429#msg45429 date=1481644345]
[url=http://web.tiscali.it/modifiche/cfg_tserver1.7z]http://web.tiscali.it/modifiche/cfg_tserver1.7z[/url]

Here the Tserver1 extract, Cav, can't find an option wich points clearly to abbring; what's the exact optn name?

How it impacts on DCID, if an interaction changes connectid?
[/quote]

Why would it change the ConnID?? Lets say, you have call A1 entering your Queue, there Entered = 1 for both SS, routes to agent, agent doesn't answer so call goes back to Queue, at this point is a new Entered, but as ConnID is the same, the metric that has DCID will not consider it, but the one that doesn't will count it again, so now you have 2 entered calls for the metric without DCID.

[Gef Buneri]

Somethimes, when delivering interation on gvp again, to use a play block with gvp app, ConnID changes (seems to be a normal behaviour in a multiple tserver cfg). By the way, the number of changed ConnID (I trace them with prints, through a comparation between original ConnID and post-play-block ConnID) doesn't matches the differences amount in stats.

***EDIT***

I can add another element, don't know if useful; in strategies, I trace call queuing with a stored procedure to which I send some call data, to write informations on a DB, including GROA and VQ selected for targeting by the SelectDN function. Queued calls from CDRs, never match N_ENTERED for the same virtual queue: CCP counts the bigger number, datamart the middlest, CDRs the lesser. Instinctively I would believe CDRs more, 'cause in my mind they count the real call passage.

[Adam G]

Suggestion: Add a Peg to the Call UDATA as it passes through the Queue(s) and make sure the maximum value cannot be more than "1".  Then create a Stat based on the COUNT of Pegs, rather than the TOTAL calls.

[Gef Buneri]

Hi Adam, thank you for the idea. Ok 'til the peg, but how (and where) can I port the peg result?

[Adam G]

As an item of UDATA, you can set up a Stat with a Filter based on the KVP.

[Gef Buneri]

In wich doc do may I find deeper infos on filter formulas syntax?

[Adam G]

It's been a while since I've used it in practical terms, but:

https://genesys.secure.force.com/support/servlet/fileField?id=0BEU0000000Teqp

Have a look at Chapter 10 - TEvents: <Custom Formulas: Calculating a Local Key-Value List>

[Gef Buneri]

Thanks a lot, Adam, I'll search in that document.

[Adam G]

Please let me know how you get on?

[Gef Buneri]

Hi Adam. CCP numbers are a lot better after reconfiguring stats using DCID as formula in ccp options, and using a time profile set as "00:00" too. Since a couple days ccp n_entered equals datamart (n_entered+n_abb_ring); ccp seems to add abandoned in ring calls to n_entered even if the stat uses only CallEntered as main mask (relative mask is empty, as for DMA stat); ccp process ver. 7.1.

A difference (~2%) remains on certain VQs used to transfer call back to IVR, and I still studying to figure how to use PEG for those VQs, 'cause I never did it before, so I'm trying to understand how to use KVP created with PEG in CCP.  (client ver. 7.5).

Regards.

[cavagnaro]

If connid changes then attach data would be lost also probably.
You sure ISCC is well configured and being used on all your transfers?

Enviado de meu E6633 usando Tapatalk

[Adam G]

cav has a point - if you are losing the ConnID, you are probably losing all of the attached data - so a configured KVP "PEG" for reporting purposes might be useless in this scenario...

[Gef Buneri]

Good point, indeed; by the way, in this case, during the process in wich those VQs work, ConnID does not changes and attach datas remain on the interaction. The only difference between "regular" VQs usage and VQs usage in those strategies, consists in the fact that I use this VQs as "dummy counters", placing two funct. blocks, one to count the event (SelectDN['VQ001',0,'',StatSelectAny,'','','','','','','','','','']), and the other to clear the target (ClearTargets['VQ001']).

[Adam G]

I think I understand - are you saying "regular" for those VQ's which keep the ConnID - and non-"regular" VQ's for where it loses the ConnID? Are you able to determine if it keeps the attached data, even if it loses the ConnID?

In truth, this now sounds more like a routing/ERS/URS/ORS issue than it does a reporting issue.  I think, once you have cleared up the mystery of losing the ConnID, your stats will probably fall into line...