|Maintenance Notice - PDF Generation|
|Dynamic PDF generation for web-based content is temporarily unavailable. This maintenance affects dynamic PDF files that are generated from either the HTML-based page or manual that you are viewing. Links that normally allow this functionality have been hidden, and will reappear as soon as the feature is restored.
This section discusses the best practices to use when developing efficient Composer applications. It contains the following topics: Also see:
- Deploying Update.
- Best Practices in the GVP 8.1 VoiceXML Reference Help available within Composer (Help > Help Contents).
Pooling Reusable Subflows
This topic discusses how to share a pool of reusable subcallflows between multiple Composer Projects.
You can have the shared pool exist in a single Project, which contains the set of subcallflows that is the shared pool. Each Project that wants to use these subcallflows uses the Subdialog block. The Uri property can be used to specify the location of the subcallflow VXML, which is deployed on an application server. For example, you could enter something like http://appserver/SharedModules/src-gen/SubFlow1.vxml http://appserver/SharedModules/src-gen/SubFlow1.vxml in the URI field of the Subdialog block (or have the value contained in a variable). This solution works best if you want to keep a shared pool of subroutines at runtime. If you update a subroutine at the shared location on the application server, all applications that reference it immediately start using the updated subroutine.
Design Time Solution
If you need shared subroutines at design time, but want to include a copy in each application and avoid a global update to all deployed applications, you could try the following:
- Identify a folder where shared subroutines will be stored. This can be inside a Project or a folder outside your workspace on your hard drive.
- In any Project that needs to reference subroutines, create a new folder and link it to this shared subroutines folder. This will allow access to all shared subroutines in the referencing Project as if they are a part of the Project. Any changes made to these subroutines will update the master copy and propagate to all other Projects.
- When you generate code and export a .war file, subroutine code will be included in the export allowing a more controlled deployment of shared subroutines. The drawback of this approach is that you will need to update each application individually.
You can also use an SCM tool to create these linked folders, which may allow other features, such as providing read-only access to shared subroutines from referencing Projects.
Multiple Developer Access to Single Project
At times, you may need to have more than one Developer working on different modules of the same Composer Project. For example, you could have a "modularized" Composer application with each module being its own Subdialog/Subcallflow. In this case, you could have the Composer workspace on a shared network drive with multiple workstations accessing the Project without corrupting the Project metadata. In a such a team development scenario, Genesys recommends using a source code management system. Third party plugins specific to the source control system (ClearCase, Subclipse Team Plugin, etc.) can be installed on top of Composer to enable this functionality. The application files need to be structured to allow individual developers to work on different diagrams. Note: Merging updates to the same diagram from different sources has not been tested so currently Genesys recommends not doing that. If a source code control system is not an option, a shared location could possibly be used simultaneously by more than one developer, but this has also not been tested. The Project could remain on the shared drive and imported into the workspace on each developer’s machine. The import is initiated from File > Import > General > Existing Projects into Workspace. Uncheck the option Copy Projects into Workspace so that files remain on the shared drive but can be used from the workspace.
Dynamic Web Projects
After you install Java EE Developer Tools plugins, you can create a Dynamic Web Project containing pages with active content. Unlike with static Web Projects, dynamic Web Projects enable you to create resources such as JavaServer Pages and servlets. Here’s how to get started:
- Composer Help >> Install New Software.
- Click Add. In the resulting box, enter http://download.eclipse.org/releases/galileo/
- Select it to see the available package.
- Select the Web, XML, and Java EE Development Eclipse Java EE Developer Tools entry.
- Install the plugins.
- Restart Composer.
- Create a Dynamic Web Project.
Note: Other missing project types can be similarly enabled.