10-06-2011 05:51 AM - edited 03-14-2019 08:40 AM
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
Solved! Go to Solution.
10-18-2011 07:15 PM
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.
10-06-2011 07:17 AM
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
10-06-2011 07:33 AM
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
10-06-2011 08:00 AM
10-10-2011 08:27 AM
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:
">
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
10-18-2011 07:15 PM
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.
10-21-2011 06:16 AM
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
05-29-2013 07:08 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide