cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2967
Views
0
Helpful
18
Replies

CVP - Should we use Sub Dialog or Sub Flow or App Jump to move between CVP Applications

DEWAYNE BRANDON
Level 1
Level 1

All,

Looking for design input and/or recommendations on best approach for moving between call studio applications.  We are in the process of creating complex self-service applications in call studio (10.5) and want to have a modular design where we can have reusable functionality contained in smaller applications that can/will be called multiple times from the main applications.  We are not sure if the best approach is to use the Sub Dialog Start and Return Elements as the method to move between the applications or if we should the new Sub Flow functionality or Application Jump functionality.

The concern with using the Sub Dialog approach is a possible performance impact to the JVM if we go with that approach vs the concerns with the limited use of the Sub Flow approach by users because of the relative newness of the feature.  It appears that using the application jump is the more common approach that we hear about, but wanted to get input and/or recommendations from users who have used any of the approaches.

Any input that could be provided would be greatly appreciated.

Thanks,

18 Replies 18

Chintan Gajjar
Level 8
Level 8

I would recommend to use Sub dialog application to achieve this function.

the reason i would avoid using application transfer is the problem with coming back to the source application at the point it was called. its still possible but you have code complex call flow.

Thanks for the reply!  Sub Dialogs are our preferences, but had concerned that there might some  JVM overhead associated with using Sub Dialogs?  Our concern is that when you call a Sub Dialog that it would cause an additional session to be spun up and in our case we could have up to 7 or 8 Sub Dialog calls in a single call flow.  Do you know if there is any additional overhead with the Sub Dialogs.

Thanks again.

I am not aware of any java overhead that is associated with Sub dialogs.

we have been running many sub application and calling them from source application multiple times. haven't seen any issue with JVM or VXML memory leak. have you read this in any cisco document or somewhere on forum?

That is great news! 

No, I have not seen or heard of anything related to there being a performance impact with using them, but had not heard of too many people using them and was wondering if there was a reason why they were not using them. 

Another question for you...how do you get around the limitations of not being able to test Sub Dialogs calls in Call Studio debugger?

it's a limitation and you cant debug multiple application in single debug session.

but may be you can give a try running source application in debug mode in your PC and calling subdialog on one of your LAB VXML server.

Thanks again!  We will try that.  Hopefully, you don't mind, but have a couple of other questions:

1.  What version of CVP are you running?  We are running 10.5.2

2.  How many VXML licenses do you have per server?  I am not looking for an exact number, but looking to see if you are close to the 600+ licenses per server that we will be running.

we are running 9.0 and set to upgraded to 10.5 in very near future.

regarding license, we are running full port licenses (900 VXML ports)

Hi,

Is it possible to invoke "subdialog invoke or application transfer" from on End java class?

Thx

Hi Dewayne, FYI in Studio 11.0, you can configure the Debugger to work with multiple applications for Subdialog Invoke and App Transfer. I see you're using Studio 10.5 so that might not help you much right now. But, it's something to look forward to. :-)

Janine

Hi Janine,

I am trying to run Subdialog invoke in the debugger, running into 'out of ports' issue. I am using an eval version of 11.5 CallStudio, could that be because it is eval version?

Starting in CVP 11.0 the Studio Debugger can be configured to work with multiple applications (for subdialog invoke and app transfer). It basically deploys the SelectedApps whenever you run the Debugger on the main app.

In the Studio Navigator,

1. Right-click the name of the main app (eg, MyApp) and select DebugAs> Debug Configurations...

2. In this window, click the tab named Dependencies

3. You'll see a list of apps that are in the Navigator. Select the apps that are being invoked or transferred to. And move them from the AvailableProjects to the SelectedProjects portion of the window. Then press Apply.

4. If you later Delete or Close one of the SelectedProject apps from Studio, the Debugger will not run unless you come back here and remove the closed app from the SelectedProject window.

Thanks, Janine. I figured that part. We have a main app that calls multiple Subd's but the problem is that when it gets to loading the Sub dialog, i get error.

Browser log in the runtime folder shows:

<?xml version="1.0" encoding="UTF-8"?> <vxml version="2.0" application="/CVP/Server?audium_root=true&amp;calling_into=LookupPhoneSd&amp;audium_busy=1"> <var name="audium_busy" expr="'1'" /> <form> <block> <prompt bargein="false"> <audio src="/CVP/audio/onhold_initial.wav">We are experiencing a heavy call volume. Please hold, and your call will be answered in the order it was received.</audio> </prompt> <submit next="/CVP/Server" method="post" namelist="audium_busy" /> </block> </form> </vxml>

Looks like the one licensed port is occupied by the main app and subd doesn't have ports.

Callstudio comes with only one "Vxmlserver" port license? Is there a way increase that?

A subdialog invoke does NOT require the system to use another vxml server license, so long as you configure the Setting named  'Local Application' to 'true' in the Subdialog_Invoke element.

If you're seeing that you are 'out of licenses' - then it probably means that there was an error getting to the invoked app and unfortunately, that usually causes the original license to 'hang' or not be released until the SessionTimeout (under Project/Properties/Studio/General) expires.

Often if there's an error getting to the Subdialog App (or a mismatch between the data passed and what's asked for in the Subdialog_Start element) then you have to look in the CallStudio/eclipse/plugins/com.audiumcorp.studio.debug.runtime/AUDIUM_HOME/logs/GlobalErrorLogger to determine why.

If you want to post screen shots of the Subdialog-invoke settings tab, and also the subdialog application's Subdialog-Start and Subdialog-Return element, I can look to see if anything jumps out at me as being wrong.

Note that you can NOT have any spaces or line-breaks in the URI.

And if the Subdialog_Start requests a parameter, it MUST be passed with the same name in the Subdialog-invoke's setting named Parameter