Sure, BIN[00] would not be valid for playback, but I was referring to Delay Prompt objects. DP[milliseconds] produces a playable silent prompt of the requested length. I assume that DP[0] is valid but I have not tried it. Unfortunately I have been stuck on a year-long project with a customer that doesn't have UCCX and my lab isn't up at the moment. Anyway, I don't mean to detract from your fine work here, just chatting. ... View more

I think the Prompt Template code above is a fantastic demo of how the feature works. As you say, you could go nuts in there with any conditional you have available in the script. It's a definite bookmark for me. For the particular business case you talked about (mostly-identical bulk sites) I think the Language feature provides a nice set of tools to do that in a simple, well-organized and self-explanatory way. I think the Prompt Template feature is a big hammer to use on that particular nail, and Languages are beneficial for code other than Play Prompt. In addition to Documents, you could use DTMF-only Grammars to tweak menu options and ordering at individual sites. However, that's definitely my artistic opinion and not objective fact. I like your cast-to-Document method for measuring prompt length. I've wanted to be able to measure prompt length in the past and couldn't find a good way to do it. I also like your 56-byte BIN[] null Prompt, but shouldn't DP[0] be functionally identical? I don't have a UCCX system available at the moment to test. ... View more

Very cool work!! I was kind of aware that Prompt Templates existed, but I have never tried to use one and never knew of a good use case. I have solved similar customer needs by [ab]using sub-languages. Many people know UCCX will search something like en_US, then en, then default for a Document or Prompt. You can actually add another level on top of that. We have mainly used this to support situations where we want more than one "voice talent", either permanently or in transition from one to another. It comes in especially handy when we want to have them record updated system prompts like numbers and ordinals and dates. If you set your Language to "en_US_Alice", your search path looks something like this: en_US_Alice en_US en Default I'm not sure how many extra levels it will search; I've only had a need for one. It has the advantage of keeping your scripts very simple. All you have to do is set your Language, either at the Trigger level or using Set Contact Info in the script. Taking the example of your 150 store retail situation, if you have a prompt "mainmenu.wav" in en_US_Store5039, that gets played. Otherwise we play it from en_US or whatever. This affects Documents as well, so if you have XML config files that might vary by store, you have default/override options. Prompt nulling or Prompt Templates are probably better solutions if you need to automate deletion or inactivation of a prompt from a script. However, the new REST API call for deletion might be useful. ... View more

There was a change in one of the UCCX 8.5 service releases, SR1 or SR2 if memory serves, that broke backward compatibility and the symptoms looked a lot like this. The moment you save a script with an upgraded Editor, the script can't be read by an older Engine. I've gotten gotten bit by that a few times. Deinstall your CRS Editor and install a fresh copy directly from the UCCX cluster you're working with to make sure you have a matching version, and try again. ... View more

It's possible to do math on time values, but it's very cumbersome and it's difficult to do correctly. Bear in mind things like seasonal time changes, timezones, leap years, leap seconds, etc. The "Get Reporting Statistic" step would answer your question easily and directly. You can call that at any point during your caller's hold loop to see how long they've been waiting, in seconds. Naturally, if you'd like minutes, just divide the result by 60. If you're using that for some sort of holding-too-long escalation threshold, then that should be all you need. If there's some reason you need the hold time at the moment the call goes to the agent, you should be able to use Select Resource with Connect set to "no" and call it in the Selected branch, and then Connect the call, but I'm not sure why you would need that. If this doesn't solve your problem, please let us know exactly why and when you need the time in queue and we might be able to help more. ... View more

What it's returning, the value U"\n\t\t", means a Unicode string consisting of a newline and two tabs. That so happens to be exactly what's in your XML file for the one child node in each area-code element. Here's an example from your file:         <--- it's the stuff between here     and here-->         The main thing I puzzled over when looking at your script is how this was working before? Are you sure that's your original script? It might be possible to craft an XPath query to return the first node NAME below an area-code element, but I'm not sure how off the top of my head. You're almost always looking for the contents of a node. What I'd suggest you do, if possible, is use a better XML schema. Something like this:   MidWest   NorthEast   West   ... Which can then be referenced using a simple fast XPath query like this: /arearoutes/route[@AC='111'] The result would be what you're looking for today in your Switch statement, a simple string "MidWest" or similar. If you're absolutely married to your old XML schema, we can try to help, but do the above if you can. You might also check out the W3 Schools XPath Tutorial. ... View more

Sounds like you've been having fun! Some things you should be aware of, if you're not already: Any time that anything changes with your database setup, including table and field names in the databases, be sure to hit Refresh Database Schema . That will be necessary to see your updated list of DSNs. This could easily have gotten confused or corrupted with your duplicate data source names. That database schema is NOT stored in your script; it gets dropped in a folder on your Desktop. If it's acting weird for you, try deleting that folder and refreshing again. If you're concerned about damaging your production script, create a new script and drag in a DB Read, and use Refresh Database Schema on that. Then it'll be available to the Editor to use with your production script. You definitely want unique Resource names for every series of DB steps. Think of it like a unique transaction ID and data cache key for that query. You can have more than one database query open at the same time; that's how DB Get and Release and such know which DB Read data set you're referring to. Even if one query is finished and released, you're NOT free to recycle that resource name in another part of your script. Your "unsupported version format 7" error is what you see when a UCCX 8.0 Editor (or Engine) tries to open a script saved by a UCCX 8.5 Editor. ... View more

Based just on the piece of your script you took screenshots of, I don't see anything immediately amiss. I am assuming the string variable "CSQ" is, in fact, representing the queue they're in. I can't verify that from your screenshot. It's very possible to query the wrong queue, and I believe it's valid to look up your position (which will be last in line) for queues the caller isn't in. What is your evidence of their "real" position in queue? What are you comparing the script-reported position to? Also, bear in mind it is possible for a caller's position in queue to go up if higher-priority callers enter the queue. Are you using Priority steps to manage callers in this or any other script on your system? ... View more

The Create URL Document step is just a helper to create a Document variable of type URL. In POST mode, it puts together the POST string for you, out of the parameters you specify. You can go around the Create URL Document step and make your own Document variable containing whatever POST text you like, such as your XML request. Here's some quick and dirty examples. ... View more

I wrote a toolkit to do this 5 or 6 years ago, and wrote up some actual documentation about 3 years ago. The code itself isn't the prettiest thing I've ever written, but it's in production at dozens of customers with zero bug reports. I've always meant to add a few features and clean it up and make it available, but I never have gotten around to it. I guess you're the lucky guy who gets it dropped on him as-is. The toolkit supports: Full date and time management, replaces Day of Week and Time of Day steps Attaching of arbitrary tags to time ranges, allows things like special announcements "closed for lunch" Fractional holidays; special hours for any given date, for things like half-day on Christmas Eve State management, open/closed management and read/write of arbitrary stored data strings on behalf of your script In its simplest form, provides a single answer for "open/closed" true/false after processing all normal scheduled operations, special dates and over-ride open/close data as needed For Cisco partners who have cheap customers and enjoy pain, will run on UCCX with standard licensing (no Java expressions) Download the toolkit here: UCCX-SM-Toolkit.zip Things that need to be done: I've meant to separate out the "normal" day of week schedule and the holiday schedule into separate files, so one system that might have different hours for different groups might share the same holiday schedule file. I also want to add proper time zone support now that UCCX plays well with time zones. I think this particular package has been edited with a UCCX 8.0/8.5 editor. Somewhere I have a mostly identical version of this that will run on IPCCX 4.0(something) that I can try to track down if it's needed. I'll do what I can to help if you have questions on how to use it. In your specific case, you can use the SPECIALDATE elements to control your fractional holidays, and set TAG elements on those days that come back to your main script and let you pick a special prompt to play. ... View more

Area-code lookups really shouldn't be a taxing thing for the XML query steps unless you're doing something very strange. The only XML scaling concern I've ever heard of is trying to parse multi-megabyte documents. There are only about 360 active area codes in the North American Numbering Plan. You could attach a ton of data about each and still be hard pressed to break 100KB. If you structure your files correctly, you should be able to discover everything you need in exactly one query. If you're running into a number-of-steps limitation, there's probably an opportunity to streamline your script. An example XML file might look something like this:       OH     Cincinnati     Blue         MO     St. Louis     Red   And some quick and dirty UCCX code to query it might look like this: ... View more