This tutorial is presented in similar lines as Migrating to WebSphere Process Server V6.2. However, WebSphere Process Server V7.0 (hereafter called Process Server) brings forth an improved set of tools and commands that help in performing the migration. It also presents a new set of terminology that helps customers understand the whole migration process clearly, thereby reducing the chances for any mistakes being committed while performing the migration. Different migration methods are recommended according to requirements or constraints that customers may have on their running deployment environments. The migration types distinguish migration of a standalone profile from migration of a clustered environment. In summary, the migration process takes a unique procedure, depending on the requirements or constraints and the source type environment. Based on experience over the years, the Process Server development team has accumulated significant improvements in the V7.0 migration process.
With the release of the latest versions of Process Server and older versions going out of support, there is always an urge to move the running environments to the latest supported versions. The latest releases of the product will bring new functional capabilities along with fixes for known defects. They are generally more reliable than earlier versions. However, the current running environments and applications might have been well configured, fine tuned, and robustly tested for the custom requirements of the business. This is a challenge for customers if there is no automatic way of performing migration on the configuration and application data from the current version to the latest version. Manually creating the same environment in the latest version is laborious and error-prone. To help customers move to the latest versions automatically, a set of procedures along with the tools and commands are available in the latest versions. 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 have to be in place before performing the migration. This avoids losing valuable business data in case of a migration failure. 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, Migration overview.
This tutorial provides a step-by-step procedure to migrate from Process Server V220.127.116.11 to V18.104.22.168. It illustrates the procedure as follows:
- An example deployment environment, configured for gold topology on Process Server V22.214.171.124 is chosen as the source environment. The source environment is migrated to Process Server V126.96.36.199. The migrated deployment environment in Process Server V188.8.131.52 is referred to as a target environment.
- A sample BPEL application containing a human task is deployed onto 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 or 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 migration. After performing the 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 this tool.
- The database schema and runtime data are migrated using database scripts.
The tutorial is divided into the following sections:
- Configuring the source environment
- Pre-migration activities
- Performing migration on the deployment manager
- Performing migration on the managed nodes
- Post-migration activities and verifications
- You need a good understanding of J2EE concepts and database concepts.
- You need to be skilled in configuring Process Server deployment environments (gold, silver, and bronze topologies) and performing administrative activities on the deployment environments.
- You have good hands-on experience in creating and managing DB2® databases. You know how to run administrative scripts on the DB2 databases.
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 184.108.40.206
- IBM WebSphere Process Server V6.2.0 Fix Pack 2
- IBM WebSphere Process V220.127.116.11 Fix Pack 1
- Configuring the source (WebSphere Process Server V18.104.22.168) environment: 8 hours
- Performing the migration: 6 hours