Limitations of GIS for RTR?

[tony]

Some of you may have used GIS for Real-Time Reporting interfaces and I we have been attempting to gauge its limitations.  We have some figures for providing RTR stats at set intervals to a number of clients but I wondered if anyone else has gone through the same exercise, in order that we might compare results?

PM or email would be good...

Thanks!

Tony

[victor]

Hi, Tony,

I have not been using GIS for RTR but only to access config server, and here are my experiences so far:

Bad things:
1. limited XML capabilities that are very hard to debug
2. it has a tendency to time out (you have to keep you client pinging GIS every 10 second or so to make sure that you do not lose your session)
3. even on the LAN, reply times are taking seconds, not milliseconds you would usually expect
4. dealing with large amount of data requires multiple submits, significantly destroying the performance
5. no packet compression, meaning if you have 5000 agents you want to get info for, you get a LOT of data sent your way over the wire. If you have 10 clients trying to do it at the same time, things get ugly

Good things:
1. easy to install an operate
2. XML documentation can be better, but you get xml file that pretty much tells you everything
3. allows you to work directly with config server
4. (My favorite) I love .NET and I found that GIS and .NET usually work very well because of XML support built into .NET

Have not dealt with RTR but after seeing the price tag, I am having second thoughts, because most of the stats can be retrieved via URS (poor man's way )

Hope it helped!
Vic

[tony]

Thanks Vic - We've noted quite a few limitations in the number of stats and the request times, so I guess we are pretty much the same in that respect.

This "poor mans way" with URS - what's that all about?

[Genecist]

Haven't used GIS for RTR, but...

Part of a CTI 'toolbar' that I developed for a client included 3 text boxes in which the agent can select a queue and have it's wait time displayed in seconds/minutes.

The solution is written in .net, is a fat client toolbar that resides on all agent desktops and utilizes GIS to access CurrMaxCallWaitingTime from stat server for each queue.

This was done for a multi-thousand agent call centre.

Refresh rate is 1 min, and we haven't experienced the timeouts indicated by victor above.

.net support for web services is second to none, IMHO...and worked very well with GIS.  Great .net examples in the Genesys supplied Stat Server/GIS SDK documentation.

In regards to performance, well...all of this stuff runs over HTTP, and HTTP was never meant to be a high performance protocol.  So you better take that into consideration.

Otherwise, with 3 queue wait times selectable by 2000 agents =~ 6000 subscribed stats refreshed every minute,  the solution has been in place for 1+ years now and not a single glitch.

[victor]

Thanks Vic - We've noted quite a few limitations in the number of stats and the request times, so I guess we are pretty much the same in that respect.

This "poor mans way" with URS - what's that all about?

Oh, this is pretty simple! If you look at IRD, you will see that there are a lot of stats that you can use.  And if there is not one you need, you can always define one using "Statistics" tab conveniently enclosed in IRD (see screen shot). I have found it very useful on more than one occasion, because you can get EWT, VQ count, agent status or anything else for that matter and then either attach the result to a call, insert it into DB or pass it on to broadcast server via Custom Server. (Of course, you can also have you application check DB every sec or 5 secs and transmit the value inserted there by URS)

Of course there are times when you need to use GIS, but I usually make sure that our people make use of what is offered first beofre dolling out more cash for license-related fees and adding yet another variable into an already complex solution.

Don't get me wrong, I am not advocating that Genesys products should not be used, but I hate to see all the functionality built into the product go to waste because some sales guy was too eager to make a quick buck and we did not know better.

[tony]

Thank you both for your input - I'm sure we will look into "other ways" very soon!

Tony