You can deploy versioned SCA modules into the run time.
Each version of a module exists alongside any other versions currently
installed on the server or in the cell.
Before you begin
Make sure you perform the following tasks before installing
a versioned SCA module into your production environment:
- In WebSphere Integration Developer, specify that the module is
versioned and export it for command-line deployment. See Creating versioned modules and libraries for
more information.
- Determine whether you want to co-deploy different versions of
the module on a single server or whether you need to co-deploy multiple
instances of the same versioned module on more than one cluster in
the same cell.
About this task
To install versioned modules, perform the following steps.
Procedure
- Run serviceDeploy against the versioned
module you exported to generate an installable EAR file.
serviceDeploy moduleName.zip
The serviceDeploy command returns an installable EAR file
whose name contains the version and, optionally, cell ID information.
- Install the module using one of the following
methods:
- From within the administrative console, click SCA Modules
and use the Install button on the SCA Modules
page.
- From within the administrative console, click Applications
> Install New Application.
- Use the AdminApp.install wsadmin command.
- If you want to install a versioned module on multiple servers
or clusters in a cell, do the following for each module instance you
require:
- Use the createVersionedSCAModule command
to create an instance of the module.
createVersionedSCAModule -archiveAbsolutePath input_archive_dir
-workingDirectory working_dir -uniqueCellID cell_ID
- Install the resulting EAR file as described in Step 2.
Results
You now have one or more versioned applications in your
production environment. They can all be administered through the administrative
console or through corresponding administrative commands.
Note: To
preserve versioning information, the installation process automatically
modifies the module name to ensure it is unique within the server
or cell through the use of either the
serviceDeploy or
createVersionedSCAModule command.
These commands add the version number, a unique cell ID, or both to
the original module name.
moduleName_vversionValue_uniqueCellID
For
example, if you followed the steps in this topic, deploying version
1.0.1 of the module billingProcess results in a module called billingProcess_v1_0_1
and an installed service application called billingProcess_v1_0_1App.
If you also specify a unique cell ID (for example, Cell5), then the
module is called billingProcess_v1_0_1_Cell5 and the installed service
application is called billingProcess_v1_0_1_Cell5App.