 | Level: Intermediate Phani Madgula (mabalaji@in.ibm.com), Software Developer, IBM
Rajiv Madassery (rajiv.madassery@in.ibm.com), Software Developer, IBM
11 Nov 2009 This tutorial shows you how to migrate WebSphere® Process Server configuration data,
application data, and databases from V6.1.2.3 to V6.2.0.1. The tutorial also describes the sub-tasks
involved and shows you how to use migration log files for troubleshooting.
Before you start
As the latest versions of the WebSphere Process Server (hereafter
called Process Server) are released and older versions go out of
support, customers are compelled to move to the latest supported versions.
The latest releases of the product have new functional
capabilities, have fixes for known defects, contain enhancements, and are more
reliable. However, the current running environments and applications
might have been well configured, fine tuned, robustly tested for the
custom requirements of the business. This brings new challenges to
customers when planning for migration. When customers decide to move
to a latest major version of Process Server from the current version,
it is termed as a “version-to-version migration”. Here, the latest
version of Process Server is installed along side the current version.
A set of migration tasks are performed to copy and transform
configuration data, relevant application data, and database schema
from the current version to the latest.
This is different from a Process Server upgrade task where out-of-date
files or data of an existing installation are replaced with the most
current information. Applying refresh packs, fix packs, and interim
fixes are examples of an upgrade.
The migration process is a complex task, which needs to be carefully
planned to successfully move the previous versions of Process Server
environment to the latest versions. The applications running in a
Process Server environment make use of various components, such as
Service Integration Bus (SIB), Business Process Choreographer (BPC),
Business Space, and so on. Each of these components uses databases to
store runtime data. Therefore, the risks involved in the migration process
need to be properly understood and proper backup and restore plans
need to
be in place before the migration. This avoids losing valuable
business data in case of a migration failure.
During the course of migration, various
check-points are presented to verify whether the migration process is being
performed correctly and successfully. It provides information about various
log and trace files created and how to troubleshoot with these files. Along with
the actual procedure, information pertaining to planning the migration process
and considerations to be taken into account are also provided. This tutorial
is targeted for hardcore administrators who monitor and maintain WebSphere Process
Server environments for a sizable organization and frequently perform
migration activities to bring their environments on to the latest versions. It
helps them to get hands-on with migration process and enable them to get
on-board for WebSphere Process Server migrations.
In addition to the above
aspects, administrators must also follow specific recommendations and
procedures if their current Process Server environment has profiles
created with different capabilities, augmentation levels, and
clusters. If users require minimum downtime, there are specific
procedures that need to be followed to perform the migration. For
more information, see the WebSphere Process Information Center topic,
Overview of migration.
In this tutorial
This tutorial discusses step-by-step procedure to migrate from Process
Server V6.1.2.3 to Server V6.2.0.1. It illustrates the procedure as
follows:
- An example deployment environment, configured for gold topology,
Process Server V6.1.2.3 is chosen as the source
environment. The source environment is migrated to Process
Server V6.2.0.1. The migrated deployment environment in Process
Server V6.2.0.1 is referred to as a target environment.
- A sample BPEL application containing a human task is deployed
on to the source environment. Before starting the migration, some
BPEL instances will be started and left in running state. After
performing the migration, these BPEL instances will be worked on
in the target environment. This illustrates the BPC database
schema and runtime data migration.
- Similarly, a sample application that generates failed events is
deployed on to the source environment. A sample set of failed
events are generated before the migration. After performing migration,
the failed events will be retrieved in the target environment.
This illustrates the application compatibility with the new
version.
- The migration wizard tool is used to perform the migration. The
application data and configuration data are migrated using the
tool.
- The database schema and runtime data are migrated using database
scripts.
WebSphere Process Server fix
packs
In this tutorial, we are using Process Server V6.1.2.3 for the source
environment and Process Server V6.2.0.1 for the target environment.
The procedure is the same when migrating from Process Server v6.1.2.x
(from any fix pack) to Process Server v6.2.0.x (to any fix pack). On
the target side, we recommend that you apply the latest fix packs
before starting the migration process.
The tutorial is divided into following sections:
Prerequisites
- You need a good understanding of J2EE concepts and database
concepts.
- You should be skilled in configuring Process Server deployment
environments (gold, silver, and bronze topologies) and performing
administrative activities on the deployment environments.
- You should have good hands-on experience creating and managing
DB2 databases. You should know how to run administrative scripts
on the DB2 databases.
System requirements
For the migration exercise illustrated in the tutorial, the following
environment is required:
- Two Microsoft® Windows 2003 servers or Windows XP Service
Pack 2 desktops with at least 2 GB of RAM
- IBM DB2 Fix Pack 9.5.0.1
- IBM WebSphere Process Server V6.1.2.0 Fix Pack 3
- IBM WebSphere Process V6.2.0.0 Fix Pack 1
Duration
- Configuring the source environment: 4 hours
- Performing the migration: 3 hours
| |
