01-19-2016
06:44 AM
- last edited on
03-25-2019
07:29 PM
by
ciscomoderator
Hi , I was wondering what is the best when you want to redirect a caller from script to another.
I have the company reception with an IVR , menu #1 has to go to the AfterSales callcenter.
Right now in the Reception script I Call the SubFlow of the AfterSales
but in a Youtube Video I saw that the dev was doing a Call Redirect from one script to another one , using Session to pass variables.
What's your opinion ?
Thanks !
Alban - Belgium
Solved! Go to Solution.
01-19-2016 04:47 PM
I must respectfully disagree with Deepak here.
The Call Subflow step is probably the most error-prone and difficult to troubleshoot step in the palette. It is very common to see people pull hair out over this step for two reasons:
The most common use cases I see for sub flows in the field are places where highly reusable code will be shared across either multiple scripts within the same system or across multiple installs. For example, most holiday checking logic is implemented as a sub flow: it's self-contained and fairly well understood by an engineer after they build it the first time.
Additionally, the child script within the Call Subflow step continues to increment the Maximum Step Count iterator which caps a script at 1000 step executions. A Call Redirect to another application and script resets that counter.
In fact, since CCX continues to lack a clean "which menu option did the caller press"-style report all these years later, it is fairly common to use the Call Redirect to separate JTAPI Triggers on the same application to track this. In practice this turns into a Switch step with a bunch of Goto labels that jump forward in the script to pick up where the menu step would have logically of advanced to. The difference is that now there will be an incremented value per-trigger on the Application Summary report.
So, at least in my opinion, Call Subflow is roughly analogous to a programming function or library: it does a specific task and is reusable. The Call Redirect to another application/script is far more common when you are changing from one call flow to another. Just be careful that the Call Redirect destination matches the JTAPI Trigger exactly and not a CUCM Translation Pattern or some other middleman. If CCX expects the call to hairpin back to itself it will hold memory open. If CUCM delays or never sends that call back then you have a memory leak.
PS- There is actually a third step that should have been an amazing addition to this topic but Cisco really dropped the ball when they coded it: Trigger Application. It was added in the 7.x days and at first several of us CCX nerds were really excited about it. Not long after a fundamental problem surfaced though: when called synchronously it is unpredictable how exception handling will play out. In random instances the On Exception logic would be caught by the original script but other times it would be caught by the triggered script. There is no clean break, nesting or precedent. It is so handicapped by this that that you can really only use it in the very rare circumstance where you can trigger an application asynchronously. It was a sad day when that answer came down from the DE.
01-19-2016 09:10 AM
You should always be using the Call Subflow step if you want to transfer a caller/call from one script to another as mentioned in the Scripting Guide. Call Redirect should ideally be used if you want to transfer the caller/call to a specific destination/extension.
Refer to below guide for more information on these two steps and others available in the CCX Editor:
http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_11_0/programming/guide/EditorSeriesVol2.pdf
Regards
Deepak
- Rate Helpful Posts -
01-19-2016 04:47 PM
I must respectfully disagree with Deepak here.
The Call Subflow step is probably the most error-prone and difficult to troubleshoot step in the palette. It is very common to see people pull hair out over this step for two reasons:
The most common use cases I see for sub flows in the field are places where highly reusable code will be shared across either multiple scripts within the same system or across multiple installs. For example, most holiday checking logic is implemented as a sub flow: it's self-contained and fairly well understood by an engineer after they build it the first time.
Additionally, the child script within the Call Subflow step continues to increment the Maximum Step Count iterator which caps a script at 1000 step executions. A Call Redirect to another application and script resets that counter.
In fact, since CCX continues to lack a clean "which menu option did the caller press"-style report all these years later, it is fairly common to use the Call Redirect to separate JTAPI Triggers on the same application to track this. In practice this turns into a Switch step with a bunch of Goto labels that jump forward in the script to pick up where the menu step would have logically of advanced to. The difference is that now there will be an incremented value per-trigger on the Application Summary report.
So, at least in my opinion, Call Subflow is roughly analogous to a programming function or library: it does a specific task and is reusable. The Call Redirect to another application/script is far more common when you are changing from one call flow to another. Just be careful that the Call Redirect destination matches the JTAPI Trigger exactly and not a CUCM Translation Pattern or some other middleman. If CCX expects the call to hairpin back to itself it will hold memory open. If CUCM delays or never sends that call back then you have a memory leak.
PS- There is actually a third step that should have been an amazing addition to this topic but Cisco really dropped the ball when they coded it: Trigger Application. It was added in the 7.x days and at first several of us CCX nerds were really excited about it. Not long after a fundamental problem surfaced though: when called synchronously it is unpredictable how exception handling will play out. In random instances the On Exception logic would be caught by the original script but other times it would be caught by the triggered script. There is no clean break, nesting or precedent. It is so handicapped by this that that you can really only use it in the very rare circumstance where you can trigger an application asynchronously. It was a sad day when that answer came down from the DE.
01-20-2016 01:07 AM
Thanks for your answer
I fully agree with you (debugging difficult , steps easily reached , no variable control)
I will think about it and adapt my scripts !
Alban
01-20-2016 01:25 AM
Wonderful comments and explanation Jonathan as always [+5], much appreciated. What all you are saying is true from the obvious reasons that you mentioned and I completely agree with what all you said.
My comment was more from the perspective that is there in the books and being a Cisco representative we always try to abide by the book, even though if there is a better alternative to that. Simple reason for this that during the course of troubleshooting the first thing we look at is "if it had been designed and configured as per the books or not, if not then revert the changes as per the book and then take it further"
I hope I made myself clear here :)
@Alban : Please note what all Jonathan commented is pretty much true and as a customer it is up to you what route you want to take since Scripting is an ocean in itself full of opportunities and there are multiple ways to achieve a single thing.
Regards
Deepak
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