This section describes some specialized terminology that relates to upgrading Waveset.
Waveset product means the product as shipped, with standard samples, JSP files, JARs, and configuration objects.
Waveset application means the customer’s deployment of Waveset, which will be uniquely configured and might be customized, might include custom code and modified JARs, might be relabeled, and so forth.
A Development environment is where you configure, customize, and use source control to build an image of the Waveset application to be promoted to another environment. You also write an upgrade procedure in this environment that you follow in each target environment.
A QA environment is where you test your upgrade procedure against data, hardware, and software that closely simulate the Production environment and where you allow intended users to test the resulting Waveset application.
In this document, promotion refers to the process of generating a particular version of your Waveset application and moving that version from Development to Test, from Test to QA, and finally from QA to Production.
You should use source-control tools to manage your configuration settings, any custom configuration objects, any custom code, any test plans, and any automated tests. Any source-control tool, such as CVS or Subversion, should allow you to track changes to any number of individual, text, or binary files and to reproduce a particular version of the Waveset application. This document refers to these tools generically as source control.
Some of these source-controlled files must be tailored for each environment. In particular, configuration objects contain values that often change for each environment. A particular Waveset resource object might point to one host machine in your Development environment, to another host machine in your Test environment, and to a third host machine in your Production environment.
Many customers use the Sun Identity Manager plug-ins for NetBeans and Eclipse to generate a tailored version of the Waveset application for each environment. The Identity Manager IDE plug-ins include a Configuration Build Environment (CBE). Some customers use older versions of the CBE that predate the Identity Manager IDE plug-in. A few customers use other tools and approaches, including proprietary or home-grown mechanisms. This document refers to these tools generically, and to the Role Manager IDE specifically, as CBE.
The Identity Manager IDE plug-in and older CBE versions parameterize configuration objects (and can parameterize code) by replacing environment-specific values with placeholder values. To generate an image of the Waveset application that is appropriate to each environment, these tools replace the placeholder values with configured values that are appropriate to each environment. If you manage the parameterized objects in source control, you can “build out” the same version of the Waveset application for each target environment using a process that is predictable and repeatable.
In this document baseline refers to a tagged level of artifacts, which includes configuration objects, libraries, and custom code in source control, that corresponds to a particular version of your Waveset application. Your CBE can generate from this baseline an image of the Waveset application that is appropriate to each target environment. An image is a complete, working copy of the application that has been tailored for a specific environment.
At a minimum, your source control must contain a baseline for the version of your Waveset application that is currently deployed in your Production environment. Your source control can also contain baselines for previous versions of your Waveset application and baselines for versions of your Waveset application that you are still developing in preparation to roll out new functionality (such as modified configurations, modified workflows, modified forms, and new custom code for integrations).
Any baseline should be complete enough that you can use it to rebuild the corresponding version of your Waveset application. Some customers include the Waveset product itself within that baseline. Other customers save the Waveset product image separately and use the baseline artifacts to overlay that product image with their own configurations and customizations.
A skip-level, or multi-hop, upgrade updates your Production environment to an Oracle Waveset product version that is beyond the next major release from its current version. A skip-level upgrade typically requires a series of upgrades, but it is technically possible, and some customers find it feasible, to develop a single upgrade procedure that updates a target environment directly to the target Waveset version.
Chapter 6, Skip-Level Upgrade Considerations describes special considerations for a multi-hop upgrade. If you are uncertain about how to proceed, or if these considerations seem unclear to you, contact Professional Services for assistance with planning and executing your upgrade.
For a description of supported Oracle Waveset upgrade paths, see Oracle Waveset Upgrade Paths in Oracle Waveset 8.1.1 Release Notes
In this document, the term configuration means editing configuration objects in the Waveset product. You can edit configuration objects by using the Waveset Administrator Interface or by editing repository objects in accordance with published documentation. For example, configuration includes specifying values in System Configuration or in a Reconciliation Policy. Configuration also includes defining Resource objects that represent the target systems and applications that Waveset will manage.
For the purposes of this document, the term customization refers to any code, file, or repository object that you write. Customizations include adding your own Java code, adding or modifying JSP files, and writing your own XPRESS code such as workflow, forms, and rules. Creating your own configuration objects or message catalogs is also considered customization.
Note that Professional Services defines these terms somewhat differently. For example, Professional Services might consider customer-specific workflows to be configurations.
In this document, however, the key distinction is that the Waveset product upgrade automatically preserves and updates customer-specified values within certain well-known objects and within instances of certain well-known types of objects. These are configurations. The Waveset product upgrade does not attempt to modify customer-written code or objects. These are customizations.
In this document, upgrade process refers to the upgrade mechanisms that are part of every version of the Waveset product. Each new version of Waveset contains not only updated code, but also an update.xml script. This update.xml script carefully preserves your configuration settings as it updates existing repository objects to work with the updated code. Any full release of Waveset might also contain sample database table scripts. These sample database table scripts carefully migrate existing data and update your database table definitions to work with the updated code.
This document uses the term upgrade procedure to refer to a document that you develop and maintain. An upgrade procedure often takes the form of a checklist. Your upgrade procedure states exactly what you plan to do in each target environment to upgrade your Waveset application. See Task 4: Prepare Your Upgrade Procedure.
This document describes phases in an upgrade project. An upgrade project is your effort to upgrade your Waveset application to work with a new version of the Waveset product on which your application is based. An upgrade project includes your efforts to maintain and retest your configurations and customizations after executing the Waveset upgrade process in your Development environment. An upgrade project also includes your efforts to maintain and retest the upgrade procedure that you will follow in each target environment.