When designing your speech application, design considerations need to be taken into account for when and where it is better to create sub flows or reusable modules in your application. To best understand the differences, refer to the following table for side-by-side considerations.
|
Modules
|
Sub Flows
|
|---|
- Project resources are self-contained.
- Reusable across projects.
- Better for multiple developers.
- Developers can work separately on their modules with out much concern that it will impact other developer's work.
- Separate application contexts at runtime.
- Session data is independent.
- (Dialog Designer runtime has mechanisms to share Java objects across modules).
- Voice browser fetches as VXML <subdialog>.
| - Share project resources (such as prompts, grammars, variables).
- Reusable only within a project.
- Not good for multiple developers.
- Multiple project files are shared and updated by various editors (such as variables, web.xml). Trying to merge updates to these files is difficult.
- Same application context at runtime.
- Requests forwarded entering or exiting sub flows- no round trip HTTP request or response.
- All VXML is part of the same dialog.
|
In general, creating and working with Sub Flows is very similar to creating and working with main flows. However, following are a few differences:
- Palettes are similar with all modules listed. Return items are different however.
- Sub flows have a Begin node which is the entry point to the flow. There is no "app root" on a Sub Flow. AppRoot is defined in main.flow.
- Sub Flows support multiple return points, forwarding the request to the next node in the calling call flow. Main flows only allow one return (exit).
Some considerations about sub flows:
- Always contained within the same application scope as the main flow.
- Share resources, such as prompts, grammars, DB operations, WS operations.
- Share application context (and session objects at runtime).
- Sub flows can be nested (that is, call other sub flows or call modules).
- There is no limit to the number of sub flows that can be in a project; however they are not intended to replace modules. The developer should design the application appropriately with proper common sense when designing large applications.
- Implicit variable items (For example, Menu, Prompt & Collect, Transfer items) names must be unique across all flows in a project. When adding or renaming these items, the Call Flow Editor and project variables will enforce uniqueness.
- Sub flow code is generated in a separate package. For example, "MySubflow.flow" will generate Java code in "flow.subflow.MySubflow" package.
- Servlet names/mappings changed (web.xml). For example, "MySubflow.flow" will have servlet names starting with "MySubflow-<node name>"; servlet mappings start with "/MySubflow-<node name>".
- With sub flows, there should be no impact on runtime performance. Servlets are all part of the same web application, and requests are forwarded when entering or returning from sub flow.
For more details on working with Sub Flows, see the following sections:
