Subject: RE: Call Studio Dynamic Menu Option
Replied by: Bill Webb on 13-06-2013 01:15:09 PM
Hi Mark -
I'm a fan of using this method of "generic", reusable Studio apps. I suppose that's like replicating microapps in Studio, but that's not altogether bad! ;-)
Anyway, there's more than a couple ways to do this, I'm sure, but I've had good luck doing the following:
1. In your ICM Script, set the valid menu options in a continuous string somewhere in the ToExtVXML array with a tag of some sort, like "opts=13457".
2. In Studio, use a Digits element instead of a Menu element, and just set it to accept only 1 character (max/min length = 1), and no retries.
3. On "done" output of Digits, go to a Decision element where you check to see if the Session Data "opts" (using my example above) and the argument "contains", and the match being Digits_01.value, as an example (whatever your Digits element is named).
4. From there, you can handle your invalid entries and create a Count for looping, or send valid entries back to ICM with your CVP_Subdialog_Return.
- Bill
This document was generated from CDN thread
Created by: Mark Applebee on 13-06-2013 12:56:09 PM
I am trying to convert my macro application to call studio apps. I am trying to use a single Menu app with dynamic menu option instead of using different apps for menu option 1, 2 etc. Anyone have a sample code doing similar work?
thanks
Mark
Subject: RE: Call Studio Dynamic Menu Option
Replied by: Paul Tindall on 13-06-2013 01:08:53 PM
Sample dynamic menu code attached.
Subject: RE: Call Studio Dynamic Menu Option
Replied by: Mark Applebee on 13-06-2013 01:26:20 PM
I think Bill's logic looks easier for me. I need more time to understand Paul's code.I will let you know once I implemented it.
Thanks guys!
Subject: RE: Call Studio Dynamic Menu Option
Replied by: Jin Tiam Loh on 14-11-2013 12:20:15 PM
Hi Paul,
For the sample dynamic menu code, you are using the same set for every menu in the application? I have a similar requirement where
a) Menu 1-2-3-4-5-6-7-8-9-0 as the maximum
b) Menu 1-2-3-4 for some case
c) Menu 1-3-5-8-0 for some other case
There dynamic values is capture from a DB lookup. If there are many areas that require this, would constant DB access be an issue?
a) Users will have simple interface to modify these values and the changes will take into effect immediate without updating application
Thanks!
-JT-
Subject: Re: New Message from Jin Tiam Loh in Customer Voice Portal (CVP) - General
Replied by: Janine Graves on 14-11-2013 04:35:46 PM
JT,
If you're worried about multiple calls to a DB to configure multiple
menus, why not just make one call to the DB but get all the possible
information that you might need and store it into Session data. You
could create your own java class to encapsulate it.
Then when you get the next dynamic menu, just have your Dynamic Config
grab the information from Session data and configure the element.
Subject: RE: Call Studio Dynamic Menu Option
Replied by: Paul Tindall on 15-11-2013 04:38:53 AM
JT,
If I recall correctly, the sample I posted was just to show how to configure the dynamic menu rather than deal with where the data came from so it only had some fixed menu items in the code to build the menu from.
If you're performing backend DB access to fetch menu config data then as you'd expect it's really down to computing the max cps, translating that to max DB hits per sec and building the platform accordingly. Personally, I think I'd use an in-memory NoSQL platform to hold the data given the performance, schema flexibility, simple keying such as app+menu name, and easy web app capability you'd get for user access.
As Janine rightly says, if performance is a challenge to achieve, you can always retrieve with a single hit and cache the data rather than read menus on demand. You can even go a step further than using session data if necessary and read into application or global data, give it a staleness timeout and refresh periodically. Disadvantage there is loss of immediate changes taking effect so it would depend on whether dynamic has to be true real-time or not.
Paul
