How should I determine which server to run a real time report query from? UCCX 9 in HA.

[steakandeggs]

UCCX 9 in HA. Currently I have two DSNs pointed to two different servers and I can statically query one server just fine; what method should I use for determining the active server? The method isn't in the database schema documentation.

[Gabriel Saavedra]

Hi, you can go to  https://:8443/uccxservice , log in. Go to Tools>Control Center - Network Services and you can see a little blue box with a "M" for the master in that moment and a "S" for the slave

Gabriel

[Anthony Holloway · Accepted solution]

Make an HTTP GET call to the following URI:

http:///uccx/isDBMaster

Example Output:

  1.0 
  true

EDIT: Reading Gabriel's reply made me realize that I made an assumption that you were looking for a way to do this programmatically.  With that said, if you have not already enabled the Real Time Snap shot config for your real time data access, then you may not know that there is a Wallboard server IP field, which basically acts like an ACL to prevent just any computer from accessing this service.  That includes the URI I mentioned above.  So, if you test this from your own PC, and not the wallboard server, you will likely be greeted with an error, versus the XML output I have shared with you.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[steakandeggs]

Thanks Anthony, your first intuition was right, I needed a programmatic way to do this. Thanks for taking the time to respond, Gabriel.

So... since Cisco only supports querying RtCSQsStatistics and RtICDStatistics tables (I assume for performance reasons), and since the only other way I know of to get at all the good stuff (all the other tables) is to use the historical report uccxhruser, what is the accepted way to make a wallboard server work? Copy out the tables accessible to uccxhruser every so often (like once an hour or once a day), and put it in our own database, and then query that?

[Anthony Holloway]

In my experience you will not get support from Cisco to go ahead and use the hrc user to query the DB in real time, but several people are doing it.  If you are ok with accessing the copied data once a day, then you would be ok querying the hrc user tables once a day also, making it not a real time grab, and thus not falling into the category of pulling real time data.  I would use a cache mechanism on the wallboard to set a last pulled timestamp, and only pull again once 24 hours have elapsed.  The added complexity of duplicating the tables is not really worth it...in my opinion.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[steakandeggs]

Do you know the official method for running a wallboard? How do all the commercial wallboard offerings do it?

[Anthony Holloway]

Yes, the official method is to only query the two Real Time (Rt) tables.

I would think that any vendor offering a supportable solution would be wise to adhere to that.  Otherwise, they would risk their solution breaking on the next major release, if Cisco chose to prevent real time access, or access all together.

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[steakandeggs]

Huh, how would a real time report access useful information such as agent names and whatnot? Is it all in those tables?

[Anthony Holloway]

An Agent name is not real time date though.  That's configuration data.  Now the state of the Agent is real time data, and that could be gotten from CTI.  Think about how CSD gets Agent state pulled in to it at real time.  So, your high end wallboard vendors could leverage CTI to get more details than your standard Rt tables.

Here's a point in the right direction, but I should disclaim that I am not affiliated with this company, I just know about their products.  Very good products too, I might add.  Ask for Stephen Welsh, and tell him Anthony sent you. 

http://www.unifiedfx.com/products/WallboardFX

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[steakandeggs]

Thanks for the followup Anthony. Now a little musing and soapboxing: Yeah, I thought the point of the (relatively) new x86 LAMPish architecture was to simplify integrations by specifically getting away from "computer-telephony" integration model which was necessarily required with old architectures, having systems with no native mechanisms for transmission of data between them. Everything is simply data: http gets with xml returns, open database access, and the like. There must be some serious performance issues to make it so complicated to get at and properly format this data.

[Anthony Holloway]

I'm not sure I understand you, on the CTI topic.  CTI is a fundemental protocol when it comes to CUCM/UCCX, which is the future of telphony.  No old school PBX's here, just packets.

I was just looking at the UCCX 9.0(2) REST API and it looks like there are some stats to be farmed there, however, it's so new, I cannot really speaek to it from experience.

Check it out:

http://developer.cisco.com/documents/11218258/11219470/Cisco-uccx-developer-guide-902.pdf?redirect=http%3A%2F%2Fdeveloper.cisco.com%2Fweb%2Fuccxapi%2Fhome%3Fp_p_id%3Ddoc_library_summary_portlet_WAR_doclibrarysummaryportlet_INSTANCE_b8N60ctZVvHc%26p_p...

Anthony Holloway

Please use the star ratings to help drive great content to the top of searches.

[steakandeggs]

Traditionally, integrating "computers" with "telephony" meant getting analog or digit line states out of big 'ole PBXs running operating systems that were self contained, and utilitizing input and output that left the world of binary computation long before the handset or headset was encountered. When speaking of integration in such a world, it is more expensive and has less features. Then everything got fully digitized, connected via IP networks, and cost and complexity to integrate dropped a lot.

Strictly speaking, in either world CTI isn't really a protocol but an unfixed set of methods.. Which is why it is kind of confusing that someone decided to call an actual protocol the "UCCX CTI protocol"... Thanks for the link to the API