UCCX script to pull XML data

[davismark.s]

Hello,

My goal is to create a UCCX script that will run on a Standard license server. Basically, when a user dials a four digit "speed dial", I want them to be translated to a UCCX route point, that will take the original called number, and the calling number, and use that to create a URL that it will then query and retrieve the actual number that will need to be dialed.

So my plan currently is to have a phone inside of a partition that has a translation pattern of XXXX. The called number gets translated to 1158, which is the trigger of the application on UCCX.

The url I want to query will be something like this:

http://localhost:35798/RestServiceImpl.svc/XML/1017/6314

"Localhost" will eventually become the IP address of the server hosting IIS application that will provide the XML output. 1017 is the "speed dial" or the original called number, 6314 is the calling number.

Going to that URL should return me this output:

<XMLDataResponse xmlns="http://tempuri.org/">

  <XMLDataResult>

  <CallingXML>

  <Extension>6300</Extension>

  <SpeedDial>1001</SpeedDial>

  <PhoneNumber>918005551212</PhoneNumber>

  </CallingXML>

  </XMLDataResult>

</XMLDataResponse>

This is the script as I have written it out so far:

It does not seem to like what I have put together thus far when I try to validate it. I'm just wondering if I'm doing something that's obviously wrong.

The end goal will be to take the NewNumber and dial it, while hiding it from the phone.

Thanks,

Mark

[Aaron Harrison]

Hi Mark

Validate just does very basic checks on the script. If it fails validation you can't debug it or run it at all on the server.

When you validate it, you can click on each error in the messages pane, then it will highlight the offending step. Correct all of them, then you can upload it and run a reactive debug to step through the script.

Validate doesn't check your logic or whether your script will actually do anything useful... but it's a start.

Regards

Aaron

[davismark.s]

Ah, I just needed to add a value to the Delay step. It validates fine now, I'm just wondering more specifically if what I'm doing with the URL modification and the Get XML Data step looks right.

Thanks,

Mark

[davismark.s]

I added a step to it for doing a call consult transfer, and I've attached the script in its current stage to this post.

Thanks,

Mark

[davismark.s]

Here's an update: I have the script retrieving the correct numbers and formulating the URL correctly. It also appears to be delivering the query from the XML.

Here's what the XML looks like when I hit it from my browser:

http://tempuri.org/

">

  http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">63141017918003551111

When I do an Interactive Script Debug session and dial the number, I can see that there are two problems: 1) the NewNumber string is "null" by the time it gets to the step to do a Call Consult Transfer, and 2) the script just shows up a blank Exception.

This tells me I am not parsing the XML correctly.

Here is what I have currently:

NewNumber = Get XML Data (xml, "/descendant::XMLDataResponse/child::XMLDataResult/child::PhoneNumber")

Which based upon what I've read in Cisco's Volume 2 and elsewhere, should be correct.

Notice in the screenshot that the XML data that UCCX pulls in looks different from when I look at it from my browser. I've also attached the script.

Thanks,

Mark

[jasyoung · Accepted solution]

The UCCX XML parser isn't a big fan of namespaces. Can you have your web service return simple XML markup?

I see in your screenshot that the XML response you got back is *partly* URL-encoded (< and so forth) . That is very odd. It might be a result of parsing failures around the namespace problem, but I wonder if your web service is returning a bad URL-encoded response when it shouldn't be. Can you "view source" in your browser or use a sniffer to verify your web service's return result? Your web browser's display of the result might be translating the URL-encoded data for display before you see it.

[davismark.s]

Yes, I should've responded to this a couple weeks ago with an update. Using XPathVisualizer I discovered that the namespace was causing an issue, and the XML app was adding those HTML codes. I had the customer remove those things, and the script worked perfectly.

Thanks,

Mark

[brad.modelle]

Any of you blokes care to upload the winning script along with other pertinent information? The documentation on this is truly bad, and I'm kind of a new kid. Definitely would appreciate seeing how it's done explicitly.

Thanks a heap.