UCCX lookup on PUB

[tom.miller1]

Hey All

So currently as It stands I have a lookup happening to the publisher which connects to the directorylist to identify callers ringing in.

However there are a number of extensions which are not associated to end users so no directory entry. Currently I am running a lookup to a document in UCCX and manipulating it with XPaths however i need to manually update this ever month or so.

Anyone know of a way or can think of a way to look up directory numbers via UCCX in an easy way, or potentially export it out in a auto method. 

Many thanks  

[Anthony Holloway]

I'm sorry, but I don't quite understand what you are trying to achieve.

Here's what I think I understand.

Today you have a mechanism within your UCCX scripting to take the calling number and perform a lookup against CUCM's directory to obtain a calling name. However, the CUCM directory is not 100% populated or accurate.

But then you say, currently, you are looking up info an a document within UCCX. So, now I'm confused as to which one you are doing? Or are you doing both? And if so, at the same time? Or just testing?

Then lastly, I think you're asking for an easy method suggestion to keep your UCCX local document updated. Is that correct? If so, I would just ask, where is the source of truth for your directory? That will dictate how you update UCCX.

And not that you asked this, but I would rank pulling data from a directory source higher, than reading a local file. Is it just impossible to fix CUCM's directory to be more accurate?

[tom.miller1]

I blame my post on staring at a screen too long today.

So the lookup to the main directory is fine on the "http://xxx.xxx.xxx.xxx:8080/ccmcip/xmldirectorylist.jsp?n="

The issue is that because we have Directory numbers that are not associated to end users but hard set extensions on devices such as generic locations e.g. Front Desk these numbers don't appear in the directorylist part of call manager.

Because of that I have to do a bulk export of numbers and upload them in an XML format to UCCX so that I can look up these missing numbers.

At the moment I am doing both (Duplicating in essence what the first is doing as well, but at least i can be assured end users are correct over generic devices)

The source of truth will always be Publisher, it is more the issue of doing the bulk export and then having to manually manipulate the text into an XML format that can then be read so at the moment.

The only way I could do it would be to create local accounts rather than our LDAP accounts for end users I guess, the issue being the number of generic extensions is crazy high (bit of a legacy build but also think it came down to licensing to a lesser degree).

I have added some screenshots to hopefully explain / show you better what i mean

[Anthony Holloway · Accepted solution]

Ok, now I think I'm 100% on track with your scenario. It would be great if there was a URL for CUCM for which you could pass it a DN/Partition pair, and it would return the Description, or the Alerting name, or the Display name, right? Because then, this would cover you 100%: for both users in the directory as well as non-user DNs.

Unfortunately, I don't think such a URL exists for CUCM, since CUCM is not a RESTful API kind of dude, when it comes to asking for DB config data. It is for user data (via UDS), but that's not good enough.

So, if you had UCCX premium or enhanced, which most likely you do, then you could leverage a custom Java JAR file to access CUCM AXL API, just like TAPS does.

Unfortunately, that's something I'm not able to help with, but perhaps some one else can.  Perhaps @Gergely Szabo can help, but he hasn't been on the forums much lately.

As an alternative, but a stretch, is a tool like AutomationFX from UnifiedFX, which sits in the middle of CUCM and your app (in this case UCCX), and converts SOAP into REST.  Unfortunately, it looks like it's not publicly available yet.

https://github.com/unifiedfx/awesome-automationfx

[tom.miller1]

I had a bad feeling this was going to be the case but thought it was best to throw it out there in case I was missing a trick.

Thanks though for the input into this, will have a look as well to see if i can wrap my head around (Or bribe the java dev guys here with some donuts and coffee) into doing something with Java.

Will keep an eye on that unifiedFx as well.

Thanks for your help again on this Anthony

[Anthony Holloway]

No problem, I hope it works out.

FYI all of the AXL docs are here: https://developer.cisco.com/site/axl/

The most likely method call you will make is the following: getLine, which accepts a DN, and optionally a Parition name, and then can return to you a whole host of items, but specifically the line description and the alerting name.

So, yeah.  If your Dev people are easily bribed, then this shouldn't be too hard.  Now, UCCX can be a bit tricky, when it comes to custom Java, so watch out for that, and search the forums for potential pitfalls.

Good luck.