Accepted Solutions
Without knowing what exactly you are having difficulties with regarding "Persistent Language" between scripts, I would like to offer some assistance.
I have had considerable success working with multi-language environments. I do not think you necessarily need to transfer a "variable" with a stored language attribute from script to script, but rather, learn to leverage the use of the Contact Language Attribute. Your script if written properly can evaluate, and re-evaluate, this if it is set when the contact selects their language preference--use a "Set Contact Info" step for the Language attribute. After being set, this attribute stays with the Contact as it traverses your applications and sub-flows. No real need to create Session Mapping (however, this could work as well..).
The UCCX Engine also knows to select recorded prompts from the appropriate Language directory in the Prompt repository, when this is done. All you have to do is name the prompts with the EXACT same name (and dot wav suffix)--so you only have to write one script.. In a few cases you may need to evaluate the Contact Language attribute to set variables appropriately--and evaluate with custom logic, but you will develop techniques over time to improve consistency and efficiency.
Here is a screen shot of a script that I developed to create Text To Speech in multiple languages (works not just for English and Spanish--but however many Languages you have configured on your UCCX server).
Image:
The power and flexibility in this method lies in using a "Get Contact Info" step for the language attribute (which I usually assign to an internal script variable 'langContact' -- usable for the duration of the time the script is active) and use the logic to evaluate it:
IF langContact.equals(langSelectedAltLangForPrompts) ... TRUE/FALSE ...the sky is the limit from there!
...let me know if this looks applicable to what you are trying to resolve.
Sincerely,
Sean
Thanks for the reply. ...and also, thank you for the explanation and link on "marking the contact as handled" after a successful redirect. This was a good refresher for me. I actually do use this. I just am very selective about when and where. In our environment, we are very cautious about marking a call as handled. In this example, I agree, it would be appropriate, because this is what you designed the script to do--transfer a call.
Regarding the explanation on why I changed the location of the "Goto" in the Failed branch of the connect step; short answer, this is a Cisco Best Practice, I learned.
This is my take on why it is done this way... (Just out of curiosity, was your original script4 working as desired using the steps and target you had selected? I actually didn't even try it...).
By definition the Select Resource step and Connect Steps, states:
https://developer.cisco.com/docs/contact-center-express/#!select-resource-step/select-resource-step
https://developer.cisco.com/docs/contact-center-express/#!connect-step/connect-step
In your original original script I noticed:
In the above Select Resource step you have the "Connect" parameter set to "Yes" and by definition, it is my understanding in this scenario, you do not need to use a "Connect Step" the output branch for this is, the agent is connected.
When using the "Connect - No" parameter in the Select Resource step, this allows you to place additional step items under the "Selected" output branch in sequence prior to adding the "Connect" step, where the resource and call is then connected. As in the image above, a Set Enterprise step is placed so that Peripheral and Expanded Call Variables can be made available to Finesse from the Enterprise Data Manager (or even other logic can be added). In these items, I also have learned to make sure that the Timeout setting is at least 1 second less than the Ring No Answer timer on the CUCM Line Setting for the agent device. You want to make sure that RMCM maintains control of the call in a Return on No Answer (RONA) scenario. I noticed you had yours set at 20 seconds. That equates to nearly 5 ring cycles(correct?). You want to make sure your agent lines are above this...if so; because if the line times-out for RNA on the telephone line on the CUCM side before the timeout period in your UCCX script parameter, strange things can happen in the land of JTAPI and CTI call control for the contact...
Which leads to the final explanation to your question: "Why 'Goto' Select Resource instead of Queue?" ...because you want the system to make sure it retains control of the contact (caller in this case). In the case of a "Failed" output branch on the "Connect" step--you want the system to first check and re-select a new agent resource; and then if one is not available, you want the system to place the contact back in the queue. Remember, queuing happens when an agent is not available. Essentially, we can't just place a caller in queue without first attempting to select and find an available resource. If no resource available--queue the caller. So that logic is what I was concerned about in your original step(s).
Did you test this in the interactive debugger? When the call is placed in queue after a failed branch output, does the next available agent answer and able to connect? ...just curious.
I wish for you happy scripting...
-Sean
