ShowTable of Contents
Introduction
Traditionally in the development of fixpacks we must hard-code various version information, and there is a lot of duplicated work, such as extracting and executing JAR commands; thus these fixpacks are appropriate only for small changes. With any large version jumps, such as from IBM® Connections 3.0 to 3.5, the traditional fixpack may involve extensive complex work. Fortunately, the IBM Rational® Installation Manager (IM) provides an easier way to manage product series releases.
Though the Installation Manager provides us with a good way to manage and generate installation scripts during development, we still find many problems in constructing an installation process---especially for the fixpack---because we need to handle the update, backup, rollback and migration tasks.
Meanwhile, different releases need to handle different configuration files, and users may choose to update or roll back to any release point. Handling all the myriad types of files in one IM script is a big challenge.
Generating the structure
First let's discuss an example that illustrates the complexities of a fixpack update in which, from version 4.0 to 4.5, we update one configuration file A, add a new file B, and perform an XSLT transform on another file C (see figure 1). From version 4.5 to 4.7, files A and B are updated again, while file C is transformed and updated.
When we roll back from 4.7 to 4.5, the files A, B, and C on 4.7 must be reverted to their 4.5 versions. When we roll back from 4.7 to 4.0 directly, files A and C must be reverted to their 4.0 versions, but file B needs to be removed. All such operations must be done in a single script.
Figure 1. Example fixpack update process
We've designed a structure to handle all kinds of fixpack processes. Let's consider the details:
- First, we need to save all the data collected from panels to a property file. To do this we use the createFile task.
- Next, we separately package the resource files and unzip them during the install phase, paying attention to the installable unit (IU) version of the zip task. If we want to execute the IU during the fixpack, we must change the IU number.
- Continuing, we define the migration_iu installable unit to handle the XSLT file transfer (see listing 1). In this IU, we call another task to do the actual XSLT transfer; meanwhile, we've set the IU to be executed only in UPDATE operation of the install phase.
Listing 1. Code to define migration_iu
4. Next, we define a backup IU to handle the backup of all changed files, using a technique whereby we create a backup directory for each release and put all changed files into them.
For example, in the 4.5 script, we put files A and C based on 4.0 into the V4.0 backup directory (see figure 2). In the 4.7 script, we put files A, B, and C based on 4.5 into the V4.5 backup directory. If changes to the file D occur in 4.7, we put both file D based on 4.0 into V4.0 backup and file D based on 4.5 into the V4.5 backup directory.
Figure 2. Example backup directory system
5. Then we create an update IU to finish the configuration file changes, including new files, removed files, and XSLT transformed files.
6. Next, we define a recovery IU to process the rollback tasks that will be executed when the action is ROLLBACK in the install phase (see listing 3). For a rollback from 4.5 to 4.0, it will invoke the 4.5 uninstall IU and then 4.0 install IU, which will copy the files from the backup directory.
Listing 3. Code for recovery IU
6. Lastly, we define an update IU to update EAR applications, being sure to pay particular attention to the IU version number (see figure 3). It must be changed; otherwise, the Installation Manager won't be able to recognize it as an update task in the new script.
Figure 3. Update IU to update EAR applications
Conclusion
This IM structure reorganizes the update and rollback sequences and can automatically update or roll back to any release. The developer needs only to focus on what the contents are that must be updated or recovered. The process is totally transparent to users; they can enjoy the update and rollback functions without concern for any other manual steps.
Resources
IBM Installation Manager, Version 1.4.1
Download document
IBM Installation Manager FAQ page
developerWorks
IBM Connections product page
wiki article, “
Developing an IBM Connections 3.x fixpack using the IBM Installation Manager”
About the authors
Yun Yan is a Staff Software Engineer based at IBM's China Software Development Lab (CDL), where his current job focus is on installation development for IBM Connections 4.0. He has a strong background in J2EE development and has extensive experience in Connections installation development. You can reach him at
yanyun@cn.ibm.com.
DeLiang Jiang is a Software Engineer based at IBM's CDL, where he is currently working on the Connections Files and Communities Data Pooling tool project. He has a strong background in Enterprise Application development, and his skills and interests include IBM WebSphere Application Server, IBM Connections, IBM Linked value installers and the ConfigEngine Framework. You can reach him at
dljiang@cn.ibm.com.