One of the major activities in any implementation of an Oracle Utilities Application Framework based product is to manage extensions to the product. These are customizations that partners, customers or consultants have built to extend or alter the product to suit the needs of an individual site.
There are typically a number of components that constitute extensions:
- Oracle Utilities SDK code - These are java or javascript pieces of code that are extensions to the product. In older versions of Oracle Utilities Customer Care And Billing we also supported COBOL based extensions. All these objects are typically managed using the Oracle Utilities SDK deployment utilities that allow you to apply extensions to a staging area, build full releases from a staging area and build patches between releases from a staging area.
- ConfigTools objects - In newer versions of Oracle Utilities Application Framework special configuration based objects were introduced to allow implementers to build configuration based objects such as Business Objects, Business Services, Service Scripts, Data Areas and UI Maps. These are typically managed using Bundling, Configuration Migration Assistant or ConfigLab. The latter is available for older versions of Oracle Utilities Customer Care And Billing as Configuration Migration Assistant was introduced in Oracle Utilities Application Framework V4.2 and above.
- Administration Data - One of the major features of the Oracle Utilities Application Framework is the ability to define business values, business rules and business logic in administration data. This data is typically available from the Administration menu of the product and is managed using Configuration Migration Assistant or ConfigLab. The latter is available for older versions of Oracle Utilities Customer Care And Billing as Configuration Migration Assistant was introduced in Oracle Utilities Application Framework V4.2 and above
- Database Scripts - Database changes are new database objects delivered with the extensions that conform to the guidelines in the Oracle Utilities SDK and DBA Guides shipped with the products. They are typically managed by the database tools of choice at a site.
- Miscellaneous Files - One of the facilities in the Oracle Utilities Application Framework is the ability to extend the technical configuration with a set of custom templates and custom user-exits which include any extensions related to the technical configuration of the product. These are typically managed manually.
Now to minimize the impact of all these changes the following guidelines are recommended:
- For SDK based files use the Oracle Utilities SDK tools to deploy your customizations. Avoid directly undeploying and manually building WAR/EAR files. This will avoid manual effort and also reduce manual errors. Do not manually splice and dice your code into the product files. Whilst it is technically possible to manually use jar and ant to build files, using the SDK utilities are lower risk and ensure the customizations, regardless of complexity, are placed in the right locations.
- When using the SDK utilities, always build full releases but use the patch build facility to build smaller deployment files. Using these patches will greatly minimize the build times and subsequent deployment times.
- Avoid deploying the appViewer, unless necessary. The appViewer is only a tool helpful for developers and administrators, it is not recommended for production use or even for environments where developers are not working regularly. Administrators and other people can use the appViewer deployed on a local server, in offline mode, rather than included in your implementation. The main reason is that the appViewer is a large set of documentation and takes time to rebuild. This will greatly reduce outages in patch installation as well as deployment. In newer versions of Oracle Utilities Application Framework, appViewer is now a completely optional installation.
- If using ConfigLab or Configuration Migration Assistant, run the comparison ahead of time. This will mean that the application of the changes will be the only thing that needs to be applied. Ensure all changes have been preapproved or at least approved by the business prior to the application. If you are a customer that has access to both ConfigLab and Configuration Migration Assistant then use the latter as it is more logical and quicker for application of changes. Note: ConfigLab has been removed from Oracle Utilities Customer Care And Billing V2.5 and above.
- Use the Database Lifecycle Management Pack to manage database changes. Oracle ships an extension pack to track and manage database changes across your enterprise. Additionally third party solutions are also available to manage database change history.
- Centralize your templates and user exits for deployment. Custom Templates and Custom user exits can be environment specific or global depending on individual needs. If they are global, using commonly used configuration management practices can be used to copy them. It is recommended that copying of these files be done in the initial phases of the migration to take advantage of any rebuilds.
- Avoid multiple rebuilds. The application of changes in EAR/WAR files requires a rebuild of the files and so do other activities such as patching. By using the options on the initialSetup utility you can minimize the build and deployment process. This is documented in the Server Administration Guides (or Operations and Configuration Guides) shipped with your product.
- Consider using native installations rather than embedded installations. This is quite a saving. In the embedded installation the product must be down to build the EAR/WAR files as they need to be updated and are actively being used by the Oracle WebLogic server. You cannot update open files. In the native installation, the files are deployed in the Oracle WebLogic domain through the deployment (or update deployment process). This means you can build the EAR/WAR files when they are being used as they are copied during the deployment or update deployment process. The update deployment process can be executed from the WLST command line, Oracle WebLogic console or Oracle Enterprise Manager (on the Oracle WebLogic targets). This update process will take a far shorter time than a full load and deployment. In some cases this can be done live. Customers using Inbound Web Services already use this technique as it updates the deployment (effectively it is being copied to Oracle WebLogic's staging area to be used). For example, on test systems we notice that update deployment takes less than a minute (depending on the hardware of course).
These are a summary of the techniques outlined in the Software Configuration Management Series (Doc Id: 560401.1) available from My Oracle Support. This series includes the following documents:
- Concepts - General Concepts and Introduction.
- Environment Management - Principles and techniques for creating and managing environments.
- Version Management - Integration of Version control and version management of configuration items.
- Release Management - Packaging configuration items into a release.
- Distribution - Distribution and installation of releases across environments.
- Change Management - Generic change management processes for product implementations.
- Status Accounting - Status reporting techniques using product facilities.
- Defect Management - Generic defect management processes for product implementations.
- Implementing Single Fixes - Discussion on the single fix architecture and how to use it in an implementation.
- Implementing Service Packs - Discussion on the service packs and how to use them in an implementation.
- Implementing Upgrades - Discussion on the the upgrade process and common techniques for minimizing the impact of upgrades.