The work-around mentioned uses a command line program (batch file) to capture information to a file. It is not elegant and has virtually no way to recover is anything goes wrong. The batch file would run the mRcv.exe file with a pipe to a text file. The text file would then need to be parsed to get the data in a usable format. Managing file size and access are the tricky parts.

The real-time data is not stored, even temporarily, in the database (at least not through the views provided). Real-time data is sent out through multicast and unicast (RSMSDK and RTDSDK). There is no option that is easy for a non-programmer. You will need to use one of the SDK's, a less than stable work-around, or a third party product.

Don't dismiss the multicast method too quickly. You do not have to multicast to every agent, you could run multicast to a server or workstation on the same Ethernet switch thus reducing the impact of multicast. Use that feed to store the data in a database and then query from where you need data.

Additional rows are for other media types (web chat, email, etc.)

RTD or RSM API, not direct to web, but can provide the information with lots of options for ensuring connections and handling issues. If you want to go very simple but a little kludgy you could use either ICERTDTRACE.EXE or MRCV.EXE and pipe to a text file that would need to be parsed to your web display.

Late answer...Use the Orchestration Guide to find the options for IVR commands, like interruptible. The guide will also provide insight on the default behavior (if you don't specify the option).

Make the agent part of both skillsets (if we are taking about queuing to the agent). If you are speaking of after the fact then there is a setting for agent desktop (system wide) that allows or disallows agents to see all contacts even if they are not a member.

You need to use Host Data Exchange (HDX) with the Database Integration Wizard. If your production database is too slow or unreliable (don't want real callers waiting) then I have used a nightly download of the CLID from the CRM to a smaller database. You can use the other way too, say giving priority to special callers.

The system cannot estimate how long it will take to answer a call unless there are a couple of things going on. Calls must be waiting and a call has to have been answered. There are two formulas you choose from. Both use "recent" data, for example the last 10 minutes. If there have been no calls answered it will show no EWT because it can't determine the EWT. Not broken, just a part of how it works. The call flow should be setup to handle this factor.

Late answer...In real-time it depends upon the "window". For moving window it is the last 10 minutes. For interval to date it is since the (configured) interval started. This is setup in the configuration area of the CCMA web page. Reports it is for the interval being reported (15 minute, daily, weekly, monthly).

Late answer...Usually a problem of 64 bit driver vs 32 bit driver. There are two separate lists of drivers. If you are able to see in ODBC admin of one and not in the tool, then you likely have the wrong driver for the tool.

That data is not in historical reports. It is available through the Agent Desktop (look up contacts). It is also in the database (just not standard reports). I would start by looking the the Multimedia Database information in the Contact Center Performance Management Data Dictionary guide (part of document collection)

It is hard to tell exactly what you are going to do, but for routing there is the HDX (Host Data Exchange) interface that allows you to pass data off to a query or web request and get back routing information. You may be able to use just this interface or you may need the RSM or RTD API. All of these are available on the devconnect site.

You use Microsoft Visual Studio to then run or compile the SDK tools. These are samples you can then build upon to make your own application. However, you will need to be familiar with C programming language and be prepared for some challenges if you expect the client to be Windows 10 (this SDK is poorly maintained).

I am writing an application using the standards described in

NN44400-212 Contact Center Real-Time Statistic Multicast Programmer’s Guide 20 December 2010

As near as I can tell this is the most recent with some notes on multiplicity added in a web page.

Application and Skillset data work as advertised.

The book states the record size for an agent is 90 bytes. Which based upon my addition, using the fields they define, is off by 1. Either the byte should be 89 or the definition of one or more of the data types is wrong.

On top of the the multicast header includes a record size. The Application and Skillset headers match the book.

The agent multicast header reports a size of 108. It seems that the server I am working with is not matching the standards stated in the guide and of course who knows what the extra 18 or 19 bytes are for or where they fit in with the existing data.

Anyone run into this issue and have an answer?