AXL API directory number search

[john.yeung]

Hi

Thanks to posts on this forum I have got AXLAPI working from C# with the modified WSDL I downloaded.

What I want to be able to do is log a user on from the PC. I know how to do this using the EMS if I have the phone name (e.g. "SEP000DED6C2E47").

I know its not possible to find out which device is connected to the PC, but I was hoping that if the user typed in the directory number of the phone e.g. 3322 (user not logged in at this point), I could retrieve the device name. The getPhone method (I can get this working) only seems to work the other way around - i.e. supply the device name and get the lines on that phone.

Can anybody point me in the right direction?

More generally, is there any documentation that describes in detail every method in the AXLAPI? I can only find general documentation about the interface usage rather than a detailed method level spec.

Thanks a lot in advance.

[stephan.steiner · Accepted solution]

Second time I post this today: http://www.cisco.com/cgi-bin/dev_support/access_level/product_support, first dropdown, first option in that dropdown. Alternatively have XMLSpy generate a html documentation from the schema files because in the end that's all cisco posted.

There's an SQL Command called executeSQLQuery.. it allows you to perform queries directly on the database.

On http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_programming_reference_guides_list.html you'll find the schema of the database. Without spending time looking for the query, basically you have the numbers in the NumPlan table and the Devices in the Device table and the schema will tell you how you can link them. Then send your SQL Query via AXL, parse the result and you get the device name for the line.

However, that seems not to be what you're looking for. The user -> DN association is quite tricky. You can have EM in which case the DN is effectively contained in a device profile (afaik they show up in the device table nontheless but don't have sepxyz names), then you have DNs directly on the devices. Finally, a user (users are stored in the DC Directory rather than in the SQL database) can have an extension and phonenumber configured. So which association you need depends on your scenario.

If you are keeping the extension in the users up-to-date, you can do an ldap query on the DC Directory to get the userid from a number. If you can't/don't want to go via the extension field, you can go via the associated profiles. They, too are contained in the DC Directory (basically anything in the Users menu on the ccmadmin pages are in the DC Directory.. except of course devices/dns you select).

I know this isn't a conclusive answer, but it takes more than a few minutes to figure it all out.. I hope this gives you enough info to go on the right road. Just start the dc directory admin and browse the tree.. you'll find the users and profiles and from that you can come up with the proper LDAP query to send to the DC directory.

[john.yeung]

Thanks for your help Stephan.

I had a look at the schema information that you suggested and was able to get the info I need by using the following query with the executeSQLQuery method.

select d.name

from

DeviceNumPlanMap dn,

device d,

NumPlan n

where

dn.fkDevice = d.pkid and

dn.fkNumPlan = n.pkid and

n.DNOrPattern='3322'

Interestingly, the server sends back the ExecuteSQLQueryRes object with the namespace "http://www.cisco.com/AXL/1.0". All the other AXL queries I have used (e.g. getPhone, getUser) send the respones classes with the namespace "http://www.cisco.com/AXL/API/1.0" - so this means I need two versions of the WSDL and XSD files with different namespaces and two separate web references in my C# project.

[stephan.steiner]

It's actually not the only time there's a namespace mismatch. I've started a thread to collect those issues: http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=IP%20Communications%20and%20Video&topic=IP%20Phone%20Services%20for%20Developers&CommCmd=MB%3Fcmd%3Ddisplay_location%26location%3D.1ddb0633

Would you mind adding yours to the list? Eventually we can take the list and forward it to Cisco to point out just how many issues there are with AXL and hopefully somebody will listen.