When I was working for Avaya business partner building call centers, one of the most frequent questions of my customers was: how do you copy files to and from CMS? Every time I had to go to explanations and wished I just had a tutorial I could point people to. Now, here it is.
Did you remember my old post about tracing on AES side. It was little bit difficult. You need to change file and bla-bla-bla. Now we have more easier way, just type trcedt servicename set [on|off|bits] bit[1-8]. ie. for trace TSAPI “trcedt TSAPI set on 1”
Following my previous article, I decided to expand on this topic; I feel it may prove useful for people who don’t want to (or can’t) mess with ODBC in CMS to still have access to historical and administrative data.
Here’s how to do it.
Following a discussion on Avaya Users forum, here’s how to use standard Informix utility dbaccess to query CMS database and get the list of users defined in CMS, with their logins, names and locations:
. /opt/informix/bin/setenv dbaccess cms@cms_ol - <<! select l_name, f_name, room, telephone from users !
You need to run this as root since only root account has read permissions on users table by default. Also note that there is no typo in the first line, there should be a space between dot and path name.
Avaya Call Management System is very good as a standalone reporting solution, but it has its drawbacks, too. Besides having very outdated architecture and performance limitations, its lack of openness for external applications was always one of the major concerns for anybody who wanted to make the most of their call center. For example, people are often interested in cradle-to-grave call analysis or collecting “warm” sales leads or detailed agent statistics or detailed customer profiles or inter-switch call flow analysis; the list is very long–but the point is, there are actually only two ways of collecting that data. The one is by utilizing CTI applications and monitoring everything in the system, which is grossly ineffective, resource consuming and prone to incurable headaches; the other is by utilizing an obscure CMS subsystem called External Call History Interface. Unfortunately, Avaya have always positioned this mechanism as fit-to-purpose and there were very limited purposes, so many people don’t even know that their CMS can export loads of data they’re looking for! And even more of that, since November 7th 2005–almost five years ago, my, the time goes fast!–ECHI comes as standard, free of charge, with every CMS server sold by Avaya, so if you have CMS R13 or later you’re almost guaranteed to have this function enabled. The Big Question is: how to utilize it? This article is an answer to the first part of the equation: how to extract External Call History data and make it available for further processing by 3rd party applications–or just viewing in Microsoft Excel, plain and simple.
A little foreword: although ECHI can be utilized for various purposes and can benefit any call center of any size and complexity–there is always a need for warm sales leads collection, for example–I will assume typical setup for a midsize call center. In this case, CMS server exports ECHI data to an external database server running Microsoft SQL server, data is imported in the SQL Server with standard tools and is reported upon with standard reporting services. There are no specific requirements for Windows Server nor for SQL Server, although I would recommend using SQL Server 2005 or later, they have reporting services built in the software and it is quite adequate in my opinion. Of course, you can use old SQL Server 2000 and report with old Crystal Reports, it will be perfectly fine. Or use Oracle database with its reporting services, or even free database engines like PostgreSQL, it doesn’t really matter. What matters is that in this article, I will cover only data extraction, conversion and export. The second part of the answer to the Big Question, i.e. what to do with the data, how to process it and what kind of results to get from it, will be discussed in subsequent articles.
Well, enough talking! Let’s dive in!
Using CMS terminal UI is easy; in some aspects it is even easier than CMS Supervisor application. There are lots of different terminal emulators out there, simple and complex, free and paid. Some require extensive learning, some do not. I will show how to use TuTTY, a freeware SSH and Telnet client software, with CMS terminal. TuTTY has many advantages, one of them is that you don’t even have to install it–it’s so small that you can just download the executable file, drop it on your desktop and run it, nothing more. Besides being small and easy to use, TuTTY has several enhancements aimed specifically at Avaya users. One of them is native support for Sun xterm terminal type, it means you won’t have to mess with settings. Well, not much anyway. :)
An accidental but fantastic find: Benjamin Roy posted an article describing ready Perl module he wrote for managing his Avaya PBXes. Well, actually the module is the back end and he’s talking about Web service utilizing that back end to provide application interface. Code looks a bit incomplete but that’s definitely a start, I think I could improve on that if need be. I don’t grok the need for reinventing the wheel–I mean, if someone needs a Web service for managing their CMs, why don’t they just use AES with SMS?–but there were times when I felt I could do something pretty and useful with OSSI terminal if only I had it documented somewhere. Well, I wish I had it like five years ago but what the heck, it still can be useful at times. And as a ready Perl module! Just like Christmas present, it really feels like that. :)
Anyway, I couldn’t pass by and not post a link: http://tools.cac.washington.edu/2010/04/avaya-pbx-admin-web-service.html. I hope Ben will submit this module to CPAN and there it’ll live forever. Amen.
P.S. Updated the link. Thanks, Ben!
As follow-up to a recent post regarding DMCC developer’s guide, I have found another very interesting and useful document on the same topic. It is a DevConnect publication called “Mastering Device, Media and Call Control Using Avaya DMCC Dashboard”. It’s not only a guide, it’s a whole tutorial that I think is a must have for any DMCC developer.
Another white paper I found in my archive. I don’t know why all these useful documents are disappearing from Avaya website but somehow they do. This one I had saved in my email folder as file rather than link so here it is.
Did you know that CMS Supervisor licenses are used exactly as their name suggests, only for CMS Supervisor application instances? Yes, they are–and it means that terminal access is not limited. Teach your supervisors or managers to use that “scary text interface” and you can save your company a chunk of $$ on supervisor licenses.
Agent licenses are different, though, they work in more complicated way. CMS has means of enforcing the number of concurrent agents working to licensed amount–but only for skills monitored by CMS itself. Let me put it this way: if you have X agents licensed on CMS and define some skills on ACD with “Measured” field set to “external” or “both”, then you can have X agents working simultaneously have these skills assigned to them, either one skill or several, it doesn’t matter. What matters is the number of agents across the skills monitored by CMS. An X+1 agent trying to log in the ACD will hear reorder tone and CM will throw a denial event.
Now consider how many agents in your call center really need all the CMS data. Probably not all: IVR ports, reception desk, HR, internal technical support–whatever skills are not critical, can be spared from CMS monitoring. Set their hunt groups to be measured only for “internal” and voila, they won’t utilize CMS agent licenses any more. You can still monitor these agents’ performance with BCMS reports and BCMS Vue, though, so there’s not much lost this way–except agent administration, agent trace, detailed call history and other CMS features, that is. But it’s a question of costs vs. gains all over again.