UCCX Scripting Best Practices

[will.alvord]

Just curious if anyone has any (documented or otherwise) best practices for UCCX scripting. Specifically wondering if every step's output branch should be handled (not marking a contact as handled) for the purpose of error handling.

cheers,

will

[Chakshu Piplani · Accepted solution]

Hi Will,

Not sure exactly what you are looking for, however I have attached a doc for handling exceptions.

Regards,

Chakshu Piplani

-rate helpful posts-

[will.alvord]

Thanks for that doc. What I was referring to though, was more toward steps with multiple output branches (ie Call Redirect step with Successful, Busy, Invalid, Unsuccessful branches). Do you typically 'do something' under each of those conditional output branches? Is that considered a best practice? ...or do you rely on exception handling via the On Exception Goto step as your doc describes?

[Bill Mungaven]

Will,

If I don't need to use a particular section (such as the false branch of an IF step), I will put an Annotate step there so if I'm doing reactive debug, at least I can see I fell into the false branch. The annotate will have something like, "Continue." Without something there, the reactive debug just skips the branch and continues; you can assume you passed through the false branch but I want to make sure I see the step through the false branch. I feel it makes my code more readable for the next guy who has to look at my code when I'm long gone. It shows I didn't overlook the false branch, rather it shows I don't actually use it.

If I don't use the "Default" branch of a Switch step, I will annotate the Default step with something like, "Default. Should not end up here" if I really shouldn't land in the Default branch.

I don't use place call or call redirect steps very often, but when I do, I will usually place a call to a subflow which will email the customer that a call was successful, unanswered, busy, invalid, etc. For the section "No resource," I will email my group rather than the customer. That indicates a systemic problem and I don't want the customer to know about that. Most of the time, they want to know if a call was answered or not via email.

Something else I do is in a Menu step, I will have something in each option (connection) even if I don't use it. In the Filter tab, I have connections for each number. For example, for option 1, I name the connection, "1-Confirm." If I don't use option 2 through 0, I make the connection, "2-Unused, 3-Unused," etc. I have the connection named but I don't assign a key to it if it's not used; invalid options are handled by the Unsuccessful branch. I do this for each option 1-9, 0, * and #. whether they're used or not. I put the connection there to show it's not used. In the future, if I need to add a connection, the placeholder is there (in numeric order) and I can change the connection name and assign the key to it. It makes the script more readable and I can see at a glance what keys I have assigned and which ones are available without opening the menu step. I find it more difficult at a menu step that has connections that just has a label that says "Main menu" and I don't know which key that is. I have to open the menu step and look at the filter to see which key press corresponds to that connection. I think following this convention makes my scripts more readable and somewhat self-documenting.

I don't typically use the On Exception Goto steps. I'm in a UCCE/ICM environment where UCCE does the call routing. When the caller hangs up, the call and whatever script is running is terminated. There are a few scripts I have that need to keep running after the caller has hung up. For these, I need to create a trigger rather than use UCCE/ICM to handle the call routing. In those cases, I will use the on exception steps to handle the caller hanging up and keeping the script running.

I haven't been scripting very long but that's the way I do things. I'm sure there are many other opinions.

Bill

[will.alvord]

Thanks Bill and also Chakshu! Exactly what I was looking for. +5 to you both

It also would be great to hear from anyone else, so leaving the correct answer unmarked for now.

cheers,

will

[Deepak Rawat]

Adding to the great inputs both by Chakshu and Bill, there are no pre defined best practices when it comes to Scripting since it on its own is a whole ocean of possibilities altogether. Still I would recommend you to take some time and go through the Scripting Guides available at below link which are updated with latest piece of information in regards to UCCX scripting:

http://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-express/products-programming-reference-guides-list.html

Secondly Will, personally speaking based on my experience when someone asks for best practices when it comes to UCCX scripting somewhere it always let me feel that there is something wrong happening in the reports which the end customer is not happy with and feels it is something to do how you are using a particular step in the script. This most of the times is true as well and the best way round this to play with the steps and see how it effects the reporting stats and then leave it as it suits best for the end client/customer in terms of  reporting.

Regards

Deepak

[will.alvord]

Thanks Deepak. There haven't been any reporting-related issues reported to me at least. I'm just trying to improve my scripting. There's always room for improvement. :)

[Gergely Szabo]

Will,

here's my list of best practices:

1. KISS - "Keep it simple, stupid".

- keep focused on the business logic;

- use as few steps as possible;

- use common programming techniques as loops (instead inserting the same steps multiple times);

- always implement a logic for all branched steps (especially for errors).

2. Do not optimize (yet). First make sure it works and then try to make it faster and/or more elegant.

3. Reuse code - modularize. Do not build monoliths. Create modules for one single piece of task and chain these modules, using parameters.

G.

[will.alvord]

Thanks Gergely! That was exactly what I was looking for. Thanks and +5 to everyone else as well for their insights.

cheers,

will

[James Hawkins]

This is not exactly what you asked about but may be of interest.

Variable Naming

It links to Sam Womack's article on variable naming within UCCX which I have found useful to follow.

The other articles on his site are very interesting too although, as a non programmer (UCCX drag and drop is as far as I go atm) some of the content goes above my head.

[will.alvord]

Thanks James! I've seen Sam's site before, but definitely worth a re-visit. What's most interesting about his UCCX scripting articles is that they're presented from the perspective of a programmer vs a network engineer unlike roughly 99.999% of the available self-published content.

One last thought/question... Is there a general rule of thumb about chaining subflow calls? How deep can/should you go? It's certainly more difficult to troubleshoot, but beyond that I mean.

[Gergely Szabo]

Hi, subflows are the root of all evil IMHO should be used with care. It's not easy to debug an application with subflows. And you just don't see the whole picture if you take a look at the script.

I know this is not an argument but I have been writing UCCX and UCCE scripts for 11 years and I never had to use subflows.

G.

[James Hawkins]

Will,

I have never called a subflow from a subflow and have never had the need to do so. What case do you have where this might be a requirement?

Gergely,

I use subflows to cover things like date/time/holiday checks and find that they save a lot of time for me. If the UCCX editor supported cut and paste of blocks of code then I guess that they would not be so useful.

If you do not use subflows do you have any other way of modularising your code? - I know it is possible to call separate applications and map data between them using session variables and that this allows easier debugging - is that what you do?

[Gergely Szabo]

James,

for date and time and holiday checks I use one Set step containing Java code, returning a Boolean value. I am not a fan of having an XML file or a database call just to check holidays, as I don't see any added value and "administration is simpler" is not a good tradeoff here. Yes, I do application "chaining" (Trigger Application step), but only if it is necessary.

G.

[will.alvord]

Hi Gergely,

Making administration simpler seems like a pretty important goal to me. This particular deployment has about 75 separate contact center groups, each with it's own scheduling (separate day/time/holiday requirements). ...and in typical fashion, requests come in sub-optimally to change those day/time/holiday requirements. There is zero opportunity to have a single maintainable scheduling script or to have any copy/pasting.

Unlike all of that though, my goal is pretty simple. I'll be standardizing the current configurations and turning it over with full documentation to Ops. Ease of administration in a perfect world leads to less error and less punting of tickets to a higher tier. I understand that it's not a perfect world, but I'll take troubleshooting uncomplicated configurations with errors over complicated configurations with errors any day of the week.

My 2 cents anyways