Created by: Martin Sloan on 20-04-2012 04:50:28 PM Hello, I'm needing to gather caller input for subscribers on our CUCX (8.5.1) cluster and was hoping to get some info on the best approach here. From what I can tell, I need to grab the subscriber URI and then get the call handler URI which will pull the input actions. In the details of that page, something like: https://cucx_ip/vmrest/handlers/callhandlers/c3e58a12-1383-4dc7-9cc4-5c4e122b62ba/menuentries/ I can see actions that are set for different keys, like <TransferNumber>. What I'm wondering is if I should assume a key is set to ignore if there is no <TargetConversation> listed? Also, we have about 7k subscribers and I need to pull this info daily for each one. Would the best approach be to get a list of all subscribers and then iterate through each gathering the caller input actions? I do a decent amount of work with the CUCM API and it seems to be a bit friendlier in accessing the DB with SQLSelects to pull the different tables together. There's also the Subscriber Dump but I'm hoping to schedule a job that runs automagically for us using the API. If anyone has travelled this path and has a recommendation on the most efficient way to gather the info, I would greatly appreaciate the input. Thanks, Marty <a></a>
Subject: RE: Gather Caller Input Key Information Replied by: Jeff Lindborg on 20-04-2012 05:43:44 PM Couple things on this:
Setting up the ODBC proxy to get it running is a little bit of a pain but it's worth it - if you open that up and go to the vw_MenuEntry view you can read what the values in that table are all used for - in this case its the "Action" field you're interested in - an action of 0 is ignor (1 is hang up, 2 sends the call somewhere etc...).
Subject: RE: Gather Caller Input Key Information Replied by: Martin Sloan on 20-04-2012 06:06:27 PM Jeff,
You're all over it! Thanks very much for the info. I certainly didn't know that UDD could be scheduled.... Is their a Linux version that I don't know about :-)? I'll also look further into CUDLI tool.
Just to be sure since I know you're the Unity guru, my aim is really to run this process from a script on a Linux box. Outside of the UDD and CUDLI, is my best bet to grab all the alias's and run through them to grab the info? In the end it's probably easier to use the tools that are available but we're trying to consolidate all of the data gathering for the systems and the API would be the most beneficial to that end.
Thanks again for the info man.
Marty
Subject: RE: Gather Caller Input Key Information Replied by: Jeff Lindborg on 20-04-2012 07:07:43 PM None of the installable tools on the site run in Linux, however the CUPI .NET wrapper (the Fast Start project) does run just fine in Mono on Linux (and Android and iPhone - it's what's behind the Connection CoPiolot iPhone app in fact) - you can easily lift the enitre library which can save a bunch of time - I've done Linux CLI apps using this (the forms stuff in Mono is a little squirly) - if you're curious go look at the "GetActionDescription" method in the ConnectionServer.cs class - it has a very handy method that will let you pass in the action, conversation and target and spit back a nice human readable description of what it's doing, complete with fetching names of target objects and such - if nothing else you can steal the functionality into Java or whatever you're using if you don't care for exploring the joys of the Mono project.
super exciting training videos, link to the public subversion project etc... hours of fun.
As to the data path - you don't need the aliases - you just need the call handler objectIds of the users and you can construct the URIs for the menu entry keys quickly off of that - do a fetch of users and the call handler objectId is in the "short version" of users returned from a search - don't bother then doing a fetch for the handler and a fetch for the menu entries and work off that - waste of fetches and cycles - just construct the URI's on your own and it'll save you some cycles.
But in short yes - you will have to process them in a crunchy list - there's a reason most of my tools use ODBC for bulk operations - it's going to be a little chuggy doing that via REST by comparison. I don't disagree about the superiority of doing SQL type queries - those of us who are professional enough to spend the time to learn how to use SQL properly would prefer to do so but the trend of late is "stateless API" with XML and JSON and blah, blah, blah... it is what it is I'm afraid. I think I'm getting too old for this stuff.
...and no, I've never gotten remote ODBC attachment to Connection to work from Linux. But to be fair I've never really tried either... I'm sure it's possible, IBM's client SDK does include drivers for Linux.
Subject: RE: Gather Caller Input Key Information Replied by: Martin Sloan on 21-04-2012 12:41:19 AM Hey Jeff,
Thanks again for the great information. The fast start project is something new to me and sounds very cool, I'll def check it out along with the hours of video which sounds like a great Saturday to me! I think you just shined a light on something I was missing with your last comment about the ODBC connection (guess I've been too focused on using the API). I'm using Perl with a DBI module to connect with other systems and it has a connector for Informix as well. Seems like I can just connect up with that and query for what I need (responsibly, of course.:-). I'll give it a shot in the lab and see what I get.
I concur on the stateless API. Limitless ambiguity! I thank you for all the great tools man. You've helped here and in more other posts than you know.
Cheers!
Marty
Subject: RE: Gather Caller Input Key Information Replied by: Martin Sloan on 23-04-2012 11:45:25 AM Hi Jeff,
So I found that there's also an ODBC Perl DBI module that I could use to connect as well. Do you know if it would even be possible to connect up with the Informix module, or should I stick with the ODBC? I'm getting the different parts downloaded and installed and will also grab the Linux SDK from IBM's site, just wondering what your opinion would be on this one.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:
