I need to write a UCCX 7.0 application that allows a caller in a queue to press 1 to schedule a callback and then enter the time to be called back in 24 hour clock format - i.e. the caller would press 1 7 3 0 to schedule a callback at 5:30pm.
I want to store the callback data in an XML file rather than in a SQL database.
I am confident that I can write the script to store the callback data but I am not sure how to read the contents of the XML file and sent outbound calls to an agent. I need some way to trigger the system to read the XML file. I also need to know how to remove the XML data once a callback has been made.
Just to clarify I do not have the Outbound option installed on the server although could possibly look at this if it was necessary.
1. Not using a database is going to get you into trouble. It's the way to go. If your reluctance is due to lack of experience with DB access out of CRS, I suggest this is a worthwhile exploration. XML files won't cut it.
2. You have nothing to trigger the reading of the file. You need a scheduler - a clock. I think you will be up against it.
If you had enough calls flowing through the system, you could use these as a poor man's scheduler - at the end of each call, check the DB and see if there are some calls to make, then make them. What a lot of work. Maybe just make one call and leave the others in the DB for the next calls to pick up. God, this is getting ugly.
Honestly, there is so much missing. Get the Outbound option (actually I know little about this, as I'm an Enterprise integrator. I just assume it's competent, like the UCCE Dialer. Assumptions get you into trouble.)
I wanted to use xml rather than a database to allow me to use this option for customers with Enhanced rather than Premium licenses.
I think it may be doable by creating a text file for every callback with the date and callback time in the filename.
I think that you have identified the main problem which is triggering the script to read the file. I thought that maybe using a http trigger and configuring an old PC to load trip the trigger every minute would be possible (but messy). Will have a think about your idea about using inbound calls to trigger the script as well.
I do not think the Outbound dialer would be any use as it needs manual input of data in CSV format to create campaigns.
Scheduled triggers would be a great addition to UCCX!
If ya'll still need to do this, you'd have to understand the "get xml" step in the IVR.
What happens is you write the xml file on the IVR and then the IVR reads that and outputs the info you specify into a variable within the script. Then you can reference that variable to do whatever it is you want.
Well the hardest part of the requirements are triggering the application so that a script can check against a database or XML file to see if it is time to call a patient back or not. Because this needs to be a continuous check, UCCX does not have anything built in that will run a script without some sort of continuous trigger.
Ah, yeah that makes sense. Hmm, well you could Q them and estimate time to call back that way. Make em wait until their time is up. That also takes care of agent delivery. Complicated but it'll work. You do have to be careful with times though because several customers could choose the same time and overwhelm you resources. It's better to let the ACD allocate resources than customers. But customers are customers so I digress..
If it's not a whole lot of these, you could also write try to the file and then present that in a nice format to the admins, so they can look at it and know.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...