| Migration Guide |    
|
| Migration Guide |
|
| C H A P T E R 1 |
|
Migrating the Content Delivery Server |
This chapter walks you through the steps involved in transitioning from the Sun Java
System Content Delivery Server, version 2004Q1PU1 to the Sun Java System Content Delivery Server, version 2005Q4.
The migration procedure consists of the following phases:
1. Performing preliminary migration steps, for example, integration of properties and migrating branding and localization information
2. Migrating the Catalog Manager
3. Migrating the Vending Managers
4. Starting the new version of the Catalog Manager and Vending Managers
After starting the new version of the Catalog Manager, you might want to perform some testing to ensure that the migration is successful. See Section 1.4, Testing the Migration for more information.
It is not necessary to shut down the entire Content Delivery Server system during migration. You can reduce the total down time of the system by following the outlined procedure. While you are migrating the Catalog Manager database, the Catalog Manager is put into READ ONLY mode and access to the Developer Portal and the Catalog Manager is restricted.
Vending Managers can continue to run, providing service to customers. After the Catalog Manager migration is complete, Vending Managers can be migrated in parallel or one at a time. Use the strategy that is most efficient for your needs.
For detailed procedures on migrating the Content Delivery Server, see Chapter 5.
For the rest of this chapter, the term "old version" refers to the Content Delivery Server, version 2004Q1PU1, Product Update 1. The term "new version" refers to the Content Delivery Server, version 2005Q4.
Prior to migrating the Catalog Manager database, you must perform these high-level preliminary migration steps:
1. Apply back-up safety procedures.
For example, back up the database for the old version of the Content Delivery Server and copy the old version of the Content Delivery Server's installation directory to a backup directory).
2. Install the new version of the Content Delivery Server with a default database following the instructions in the Sun Java System Content Delivery Server Installation Guide.
The database initialization for the migration procedure is different from the one used for the default deployment. The cdsi db init command creates empty database and tables. It then populates some of the database tables with default data. The migration process requires a clean database, which has absolutely no table data and has no foreign key constraints imposed between tables. To accomplish this requirement, you need to create the database using the following two commands:
$cdsi db users
$cdsi db schemas_noc [-conf {dbconf}] [-cs] [-vs {vending}]
The first command creates users on the database server. The second command creates all the tables without creating any intertable constraints. The cdsi db users command completely erases any information associated with the database users specified in the DBConf.xml file, so if you have already created an empty database with cdsi db init, start over by running cdsi db users.
|
Note - The cdsi db schemas_noc command is not documented by cdsi help. |
3. Configure your new deployment to connect to your basic integration components.
For instance, such components can be the Wireless Access Protocol (WAP) and Push Proxy Gateway (PPG), Lightweight Directory Access Protocol (LDAP), Short Message Service Center (SMSC), Senders and Receivers, and Notification and Email Server.
This integration migration step consists of modifying custom adapters to use them with the latest version of the Content Delivery Server. Typically, the following adapters need to be migrated:
A default implementation instance is provided for each adapter.
Configure the properties migration file, $CDS_HOME/cfg/migration/props_migration_2004Q1PU1_2005Q4.xml, to migrate properties and existing localization data from the old version to the new version of the Content Delivery Server. You must migrate any new localization information.
4. Run the cdsi migrate props command to migrate the configured properties.
For detailed information on configuring and running the properties migration file, see Chapter 2. For information on directory and file structure changes, see Chapter 3.
5. Migrate all branding information to your new Content Delivery Server deployments.
You must manually migrate all branding information so that the branding information in version 2004Q1PU1 of the Content Delivery Server is preserved. Run and test branding in a separate thread prior to live migration so can you see how branding is deployed in version 2005Q4 of the Content Delivery Server. Branding migration can be time consuming depending on the complexity of the customization and the number of sites to be branded.
Branding migration can include, but is not limited to, the following operations:
(JSP) technology
This step assumes that you are familiar with branding and customizing the Content Delivery Server. See the Sun Java System Content Delivery Server Branding Guide and Sun Java System Content Delivery Server Customization Guide for details.
6. Test the core Content Delivery Server functions, including old and new services, all branded portals, and your basic integration components.
7. Deploy any custom integration adapters.
This step assumes that any custom adapters are compliant with the Content Delivery Server or have been extended to work with Content Delivery Server prior to the migration phase.
8. Test the fully integrated Content Delivery Server deployment.
Note that the server must be fully configured to the your specification, which includes configuring the workflows before the migration is executed. See the Sun Java System Content Delivery Server Installation Guide for information on how to edit the SubmissionVerifiedWorkflow.xmlfile to meet your deployment needs.
Try performing a preliminary migration test on your designated system to determine the approximate length of time it takes to migrate your configuration of the Content Delivery Server.
Create a new database even if the same database server is used as the schema for the new version of the Content Delivery Server could differ from the schema used in the old version.
|
Note - The Vending Manager can continue to run and service customers during this phase of the migration. |
During the migration of the Catalog Manager database, the following requirements must be met:
Note though, that for Vending Managers, content can be freely stocked and unstocked.
Schedule the beginning of the migration in accordance with their affiliates to set expectations and to determine when to stop the Catalog Manager.
This phase consists of the following high-level steps:
1. Stop all managers and servers that are running the new version of the Content Delivery Server deployed during the preliminary phase.
2. Restrict access to the Catalog Manager database by putting the Catalog Manager into READ ONLY mode.
READ ONLY means that no modifications can be made to the Catalog Manager database, that is, developers cannot submit any content and administrators cannot make any modifications. The Catalog Manager and the Developer Portal are considered frozen. Do not make any changes that would affect the database. The following actions can help you to prevent changing the database:
3. Migrate the Catalog Manager database to the new version of the Content Delivery Server.
For detailed steps on migrating the database, see Chapter 5.
4. (Optional) Run the migration verification script.
Verify the database migration after each migration step. For information on running the script, see Section 5.13, Verifying Migration Completion in Chapter 5.
5. Stop the Catalog Manager and the Vending Manager that are running on the old version of the Content Delivery Server.
a. If the Catalog Manager and the Vending Manager are on the same server, shut down both managers.
b. If the Catalog Manager and the Vending Manager are on different servers, shut down the Catalog Manager.
The Vending Managers can continue to run but vending services (for example, Event, Messaging, Postpaid, and Monitoring) must be stopped.
6. Migrate the Vending Manager database to the new version of the Content Delivery Server.
During the migration of the Vending Manager, no activity can take place on the Vending Manager or its associated subscriber portals.
7. (Optional) Run the migration verification steps.
8. Start the managers in the new version of the Content Delivery Server.
a. If the Catalog Manager and the Vending Manager are on the same server, start both managers in the new version of the Content Delivery Server.
b. If he Catalog Manager and the Vending Manager are on different servers, start the Vending Manager only after the Catalog Manager is running in the new version of the Content Delivery Server.
9. Shut down any other Vending Managers that are still running on the old version of the Content Delivery Server and stop all their services.
10. Migrate the other Vending Manager databases to the new version of the Content Delivery Server.
11. (Optional) Run the migration tests.
12. (Optional) Set specific content types to be read only.
During the migration process, some content types might not have an attribute that allows the content type to be edited or to be read only. To ensure that certain content types are not editable, follow these steps after the migration and migration verification processes have completed for all catalog and vending managers:
a. Make sure all deployments are stopped.
b. Run the following SQL command:
update content_type set editable=0 where name is ('bundle', `midlet', `text', `iappli');
The SQL command must be run against the catalog database (_PS_APP suffix) and all respective vending databases (_VS_APP suffix).
After deployment of the new version of the Content Delivery Server, the content types specified in the SQL command are treated as read only.
13. Start the other Vending Managers in the new version of the Content Delivery Server.
You can now start the Vending Manager services and stop the Service Outage counter. You are now running version 2005Q4 of the Content Delivery Server. Do not attempt to reuse the version 2004Q1PU1 server because any changes made in that database are not reflected in the new database.
To ensure that the migration of the Content Delivery Server was successful, a thorough testing of the following migration areas are essential:
Finally, test a fully integrated and branded version of the Content Delivery Server after the migration of each of the listed areas is completed.
The migration testing includes, but is not restricted to the following areas:
For information on migration verification, see Section 5.13, Verifying Migration Completion in Chapter 5.
| Migration Guide | 819-3217-10 |
|
Copyright © 2005, Sun Microsystems, Inc. All Rights Reserved.