cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2241
Views
24
Helpful
4
Replies

Call SubFlow OR Call Redirect ?

alban.faverot
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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:

  • There is no validation of whether the input/output variable mappings will work at runtime. For example, if the parent script is expecting a String but the child script uses an integer. This will pass validation in the editor but throw an exception at runtime.
  • Reactive debugging of a script does not include the sub flow script which executes a single step, pass fail. If there is a problem within the child script that Call Subflow referenced you must debug it separately. This also requires additional code so that you can attach it to a test Application, accept a JTAPI Triggering Contact only in debug mode, and manually set any variables that would normally be set through the input mappings.

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.

View solution in original post

4 Replies 4

Deepak Rawat
Cisco Employee
Cisco Employee

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 -

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:

  • There is no validation of whether the input/output variable mappings will work at runtime. For example, if the parent script is expecting a String but the child script uses an integer. This will pass validation in the editor but throw an exception at runtime.
  • Reactive debugging of a script does not include the sub flow script which executes a single step, pass fail. If there is a problem within the child script that Call Subflow referenced you must debug it separately. This also requires additional code so that you can attach it to a test Application, accept a JTAPI Triggering Contact only in debug mode, and manually set any variables that would normally be set through the input mappings.

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.

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

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: