Are there any pros and cons of using CVP subflows from a CVP application architecture and performance standpoint?
As per my understanding of how the subflows works in CVP, following are the pros and cons of subflow over subdialog:
- Resides locally in the app, so session data is easily accessible for call processing
- Multiple developer can work concurrently on the app by splitting the flow in logical groups (sub flows). Very useful for agile delivery.
- A change in a sub flow requires the sub flow to be re-deployed in the calling app. So, if a sub flow is used across apps, either all the calling apps may need to be deployed or multiple versions of subflows needs to be maintained for each app.
Other than the above, I am interested to know if there are any specific pros and cons (especially Con) because we plan to use the subflows extensively in our CVP application architecture.
Any thoughts, comments and suggestions are really appreciated.
Thanks & regards,
Kindly find the below link for more information.
Thanks for sharing the link, it was very helpful to understand the CVP subdialog option. However, there is nothing specific mentioned about the CVP subflows in that thread which is a new concepts introduced in CVP 10.5
Any information/link which provides details about subflows specifically (pros/cons/impact etc..)?
Also request other in the community to comment based on their experience with CVP Subflows.
Thanks & regards,
Hey Roshan, did you end up using Sub flow or subdialogs? One deal breaker for me was inability to re-use subflows across multiple CVP applications, it seems the subflows must be nested under a specific CVP app. We use subdialogs because of this limitation.
Which is a bummer because as you mentioned a subflow would keep the transfer local to VXMLServer vs sending a new VoiceXML page to the gateway and opening another session with another app when doing a subdialog. There has to be a performance overhead to doing that, however small it may be.
I've found the following 'features' with subflows. None are
deal-breakers, but nice to know!
a. Because element data and local data are only available within a
subflow, they are not available in the End of Call Java class where you
might be trying to access them for reporting.
b. However, element data and local variables are 'persistent' - so if
you call a subflow multiple times, all its variables will RETAIN their
previous values. This is important if using something like Counter
element - it will NOT initialize the 2nd time you call it.
c. An application transfer fails from within a subflow, however
CVP_Subdialog_Return works fine
d. If using getElementHistory() and getExitStateHistory() in End of Call
Java, they do not align correctly for elements within the Subflow - it
seems the SubflowCall element has no exit state until you exit the
subflow, at which point things seem to align correctly again!
e. If using getElementHistory() within a subflow, the element names
include the name of the subflow SubflowName.ElementName. However, if
you then try to use this with the getElementData() method, it fails
because it wants to know 'JUST' the name of the element, so you must
strip off the subflow name.
Wow thanks Janine, that is super helpful to know upfront!