0911 Madgula PDF

8/6/2019 0911 Madgula PDF

1/58

Migrating to WebSphere Process Server V6.2Migrating from V6.1.2.3 to V6.2.0.1

Skill Level: Intermediate

Phani Madgula ([email protected])Software DeveloperIBM

Rajiv Madassery ([email protected])Software DeveloperIBM

11 Nov 2009

This tutorial shows you how to migrate WebSphere Process Server configurationdata, 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 fortroubleshooting.

Section 1. Before you start

As the latest versions of the WebSphere Process Server (hereafter called ProcessServer) are released and older versions go out of support, customers are compelledto move to the latest supported versions. The latest releases of the product havenew functional capabilities, have fixes for known defects, contain enhancements,

and are more reliable. However, the current running environments and applicationsmight have been well configured, fine tuned, robustly tested for the customrequirements of the business. This brings new challenges to customers whenplanning for migration. When customers decide to move to a latest major version ofProcess Server from the current version, it is termed as a version-to-versionmigration. Here, the latest version of Process Server is installed along side thecurrent version. A set of migration tasks are performed to copy and transformconfiguration data, relevant application data, and database schema from the current

Migrating to WebSphere Process Server V6.2 Copyright IBM Corporation 2009. All rights reserved. Page 1 of 58
mailto:[email protected]:[email protected]://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlmailto:[email protected]:[email protected]


2/58

version to the latest.

This is different from a Process Server upgrade task where out-of-date files or dataof an existing installation are replaced with the most current information. Applyingrefresh packs, fix packs, and interim fixes are examples of an upgrade.

The migration process is a complex task, which needs to be carefully planned tosuccessfully move the previous versions of Process Server environment to the latestversions. The applications running in a Process Server environment make use ofvarious components, such as Service Integration Bus (SIB), Business ProcessChoreographer (BPC), Business Space, and so on. Each of these components usesdatabases to store runtime data. Therefore, the risks involved in the migrationprocess need to be properly understood and proper backup and restore plans needto be in place before the migration. This avoids losing valuable business data incase of a migration failure.

During the course of migration, various check-points are presented to verify whetherthe migration process is being performed correctly and successfully. It providesinformation about various log and trace files created and how to troubleshoot withthese files. Along with the actual procedure, information pertaining to planning themigration process and considerations to be taken into account are also provided.This tutorial is targeted for hardcore administrators who monitor and maintainWebSphere Process Server environments for a sizable organization and frequentlyperform migration activities to bring their environments on to the latest versions. Ithelps them to get hands-on with migration process and enable them to get on-boardfor WebSphere Process Server migrations.

In addition to the above aspects, administrators must also follow specific

recommendations and procedures if their current Process Server environment hasprofiles created with different capabilities, augmentation levels, and clusters. If usersrequire minimum downtime, there are specific procedures that need to be followed toperform the migration. For more information, see the WebSphere ProcessInformation Center topic, Overview of migration.

In this tutorial

This tutorial discusses step-by-step procedure to migrate from Process ServerV6.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. Thesource environment is migrated to Process Server V6.2.0.1. The migrateddeployment environment in Process Server V6.2.0.1 is referred to as atarget environment.

developerWorks ibm.com/developerWorks

Migrating to WebSphere Process Server V6.2Page 2 of 58 Copyright IBM Corporation 2009. All rights reserved.
http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/cmig_vtv_overview.htmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/cmig_vtv_overview.html


3/58

A sample BPEL application containing a human task is deployed on to thesource environment. Before starting the migration, some BPEL instanceswill be started and left in running state. After performing the migration,these BPEL instances will be worked on in the target environment. Thisillustrates the BPC database schema and runtime data migration.

Similarly, a sample application that generates failed events is deployed onto the source environment. A sample set of failed events are generatedbefore the migration. After performing migration, the failed events will beretrieved in the target environment. This illustrates the applicationcompatibility with the new version.

The migration wizard tool is used to perform the migration. Theapplication data and configuration data are migrated using the tool.

The database schema and runtime data are migrated using databasescripts.

WebSphere Process Server fix packs

In this tutorial, we are using Process Server V6.1.2.3 for the source environment andProcess Server V6.2.0.1 for the target environment. The procedure is the samewhen migrating from Process Server v6.1.2.x (from any fix pack) to Process Serverv6.2.0.x (to any fix pack). On the target side, we recommend that you apply thelatest fix packs before starting the migration process.

The tutorial is divided into following sections:

Configuring the source environment

Pre-migration activities

Preparing the target environment

Migration activities

Post-migration activities and verification

Prerequisites

You need a good understanding of J2EE concepts and databaseconcepts.

You should be skilled in configuring Process Server deploymentenvironments (gold, silver, and bronze topologies) and performingadministrative activities on the deployment environments.

ibm.com/developerWorks developerWorks

http://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtml


4/58

You should have good hands-on experience creating and managing DB2databases. You should know how to run administrative scripts on the DB2databases.

System requirementsFor the migration exercise illustrated in the tutorial, the following environment isrequired:

Two Microsoft Windows 2003 servers orWindows XP Service Pack 2desktops 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

Section 2. Configuring the source environment

This tutorial uses two Windows servers, Windows1 and Windows2. On bothWindows servers, Process Server V6.1.2.0 Fix Pack 3 and Process Server V6.2.0.0Fix Pack 1 will be installed. On the Windows1 server, DB2 is also installed for thecommon database and Business Process Choreographer database.

In this section, you perform the following tasks:

Installing WebSphere Process Server V6.1.2.0 Fix Pack 3

Installing IBM DB2 Fix Pack 9.5.0.1

Configuring the deployment environment with gold topology

Deploying the sample modules




5/58


Install Process Server V6.1.2 Fix Pack 3 on both Windows servers. For instructionson how to install Process Server V6.1.2, see the WebSphere Process Server

Information Center topic, Installing and configuring WebSphere Process Server. Youcan install Process Server either interactively or silently. Do notcreate any profilesduring the installation. The required profiles will be created separately after theinstallation task is completed. After installing the base Process Server V6.1.2, applyFix Pack 3 by following the instructions in Technote: WebSphere Process ServerV6.1.2 Fix Pack 3 (v6.1.2.3). We are not going to discuss in detail the installationprocedure in this tutorial as it is already documented in the Information Center.

After installing Process Server V6.1.2 Fix Pack 3, verify the installation by runningthe following command and observing the version in the output.

\bin>versionInfo.bat..Installed Product------------------------------------------------------------Name IBM WebSphere Application Server - NDVersion 6.1.0.23ID NDBuild Level cf230910.10Build Date 3/10/09

Installed Product------------------------------------------------------------Name IBM WebSphere Process ServerVersion 6.1.2.3ID WBI

Build Level o0924.02Build Date 6/20/09..

refers to the directory, where Process Server V6.1.2.3 isinstalled on both Windows servers.

Installing DB2 Fix Pack 9.5.0.1

Install DB2 Fix Pack 9.5.0.1 on the Windows1 server. Go through the product

documentation to understand the prerequisites. It also provides information aboutthe installation procedure and how to apply the fix packs. At the end of this task, youhave installed DB2 Fix Pack 9.5.0.1 on the Windows1 server.

Configuring the deployment environment with gold topology


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r1mx/index.jsp?topic=/com.ibm.websphere.wps.612.doc/doc/welcome_wps_ins.htmlhttp://www.ibm.com/support/docview.wss?rs=2307&uid=swg24023642http://www.ibm.com/support/docview.wss?rs=2307&uid=swg24023642http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.server.doc/doc/r0025127.htmlhttp://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.server.doc/doc/r0025127.htmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.server.doc/doc/r0025127.htmlhttp://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.server.doc/doc/r0025127.htmlhttp://www.ibm.com/support/docview.wss?rs=2307&uid=swg24023642http://www.ibm.com/support/docview.wss?rs=2307&uid=swg24023642http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r1mx/index.jsp?topic=/com.ibm.websphere.wps.612.doc/doc/welcome_wps_ins.html


6/58

In this section, we will configure the source environment. A deployment environmentthat has an application cluster, support cluster, and messaging cluster is created.Each cluster has a cluster member created in the on bothWindows servers. We are not going to discuss in detail this topic as there arealready many developerWorks articles and IBM Redbooks published on this topic.

The following references will help you get the deployment environment ready:

Building clustered topologies in WebSphere Process Server V6.1

IBM Redbook: WebSphere Business Process Management V6.1.2Production Topologies

The WPRCSDB and BPEDB databases are created to store the common databaserepository and Business Process Choreographer data, respectively. Thesedatabases are created on DB2. The name of the deployment environment isWPSTestEnv. The following steps help you create and configure the deploymentenvironment:

1. Create a deployment manager profile Dmgr01 in the on the Windows1 server.

2. Create a managed profile Custom01 in the on theWindows1 server.

3. Create a managed profile Custom02 in the on theWindows2 server.

4. Federate both the Custom profiles to Dmgr01.

5. Create a deployment environment with gold topology with the name asWPSTestEnv.

6. Distribute a cluster member on each of the managed profiles created inthe Windows1 and Windows2 servers for the WPSTestEnv.AppTarget,WPSTestEnv.Support, and WPSTestEnv.Messaging clusters.

7. Specify WPRCSDB as the database name for the common repository andBPEDB as the name for Business Process Choreographer database. TheWPRCSDB database is used for messaging engines as well as forCommon Event Infrastructure (CEI).

8. After generating the deployment environment, the cell topology looks likeFigure 1.Figure 1. Cell topology


http://www.ibm.com/developerworks/websphere/library/techarticles/0803_chilanti/0803_chilanti.htmlhttp://www.redbooks.ibm.com/abstracts/sg247665.html?Openhttp://www.redbooks.ibm.com/abstracts/sg247665.html?Openhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.redbooks.ibm.com/abstracts/sg247665.html?Openhttp://www.redbooks.ibm.com/abstracts/sg247665.html?Openhttp://www.ibm.com/developerworks/websphere/library/techarticles/0803_chilanti/0803_chilanti.html


7/58

In Figure 1, the phani2CellManager01 node corresponds to the Dmgr01profile and phani2Node03corresponds to the Custom01 profile. Thesenodes are created as part of Dmgr01 and Custom01 profile creation

activity on the Windows1 server. The rmadasse3Node01 corresponds tothe Custom02profile created as part of profile creation on the Windows2machine. Once the deployment environment is generated, a similartopology, perhaps with different names for nodes, will be created for youas well. However, the names of the three clusters will be same if you usedWPSTestEnv as the name for the deployment environment.

9. The deployment environment topology looks like Figure 2.Figure 2. Deployment environment




8/58

Deploying the sample modulesTwo sample applications are provided in the article to be deployed in the sourceenvironment. These applications will be used to generate some failed events andcreate business process instances. You will later verify in the target profile whetherthe failed events and process instances are intact during post-migration.

1. Start the node agents for the Custom01 and Custom02 profiles on theWindow1 and Windows2 servers.

2. Start the WPSTestEnv deployment environment. After starting thedeployment environment, all the servers will be started as shown inFigure 3.Figure 3. Starting the servers




9/58

3. After starting the deployment, the clusters will be started successfully asshown in Figure 4.Figure 4. Starting the clusters

4. After starting the deployment environment, the admin console indicatesthat the deployment environment is started successfully as shown in

Figure 5.Figure 5. Starting the deployment environment




10/58

5. Download the HelloWorldWithBOApp.ear and ToDoTaskApp.ear files.

6. Install them on to the WPSTestEnv.AppTarget cluster and start theapplications as shown in Figure 6.Figure 6. Starting the sample applications

7. A full resynchronization of the nodes is performed to get the applicationstatus propagated to Dmgr01.




11/58

8. The ToDoTaskApp.ear application creates a BPEL process template withthe name as RequestProcess. Start several process instances for theRequestProcess template using BPCExplorer. The BPCExplorerapplication is installed on the WPSTestEnv.Support cluster. Find out the

HTTP port of the cluster member of the WPSTestEnv.Support cluster andopen the BPCExplorer using http://:/bpc. If thelink does not open the BPCExplorer application, verify whether the hostname and port are added to the virtual host that is mapped. The processtemplate is displayed on the BPCExplorer as shown in Figure 7.Figure 7. Process template

9. Select the RequestProcess checkbox and start several processinstances as shown in Figure 8.Figure 8. Starting process instances

10. Each process instance has a to-do task that expects user to work on it.The process instances ask a question and expect the user to provide ananswer through the to-do task. Click the My To-dos link on theBPCExplorer to list the tasks. It displays the list as shown in Figure 9.Figure 9. Human task list




12/58

11. You will not work on these tasks now. You will keep these tasks runningand start the migration process. After performing migration, you will comeback to the BPCExplorer to work on the tasks. This exercise will showthat you can perform the migration with the running process instances

and human tasks.

12. Open a browser window and invoke TestAll.jsp in theHelloWorldWithBOApp.ear application with the linkhttp://localhost:9080/HelloWorldWithBOWeb/TestAll.jsp. This JSP filegenerates numerous failed events that you can view in the admin consoleas shown in Figure 10.Figure 10. Failed events

13. After performing the migration, you will verify that failed events arepreserved and can be viewed in the admin console.

Section 3. Pre-migration activities

This section describes pre-migration considerations and corresponding activities.For detailed information, see Premigration considerations for WebSphere ProcessServer. We are not going to elaborate on each of the pre-migration considerationsprovided in that link. However, we highlight general considerations that are relevantfor this migration exercise:


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/cmig_vtv_pre.htmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/cmig_vtv_pre.htmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/cmig_vtv_pre.htmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/cmig_vtv_pre.html


13/58

The migration process performs migration on a profile at the sameaugmentation level. For example, a Process Server profile is migrated toa Process Server profile only. It is not migrated to a WebSphere ESB orWebSphere Application Server profile. The same is true for other profiletypes. In our exercise, all the profiles are of type WPS. Therefore, all the

profiles are migrated to a WPS type only on the target environment.

The migration process cannot modify the profile capabilities duringmigration. For example, a deployment manager profile cannot bemigrated to a managed node profile.

Process Server provides binary compatibility for the applications with priorversions. That is, applications developed for previous versions run withoutany modifications on later versions. In this tutorial, the migration processwill copy and transform configuration data from the source environment tothe target environment. Therefore, the entire WPSTestEnv deploymentenvironment along with the applications is moved from the sourceenvironment to the target environment.

In this tutorial, we use the migration tool to perform migration. Themigration GUI gathers required source and target environmentinformation from the user and invokes migration utilities to performend-to-end migration. The migration tool requires a backup directory,where a backup of the profiles being migrated are copied duringpre-migration. This directory should have sufficient disk space toaccommodate profile configuration and application data.

The migration of configuration and applications has two activities,

WBIPreUpgrade and WBIPostUpgrade. Each of these activities hasstorage requirements as shown Table 1. We will provide the directorylocation to the store configuration data while performing migration in themigration tool.

Table 1. Backup directory storage requirements for WBIPreUpgrade

Command WBIPreUpgrade

Location Backup directory specified as a parameter of theWBIPreUpgrade command. Size of the followingitems for all of the Process Server V6.1.2.xprofiles.

profile_root/installableApps directory profile_root/installedApps directory

profile_root/config directory

profile_root/properties directory

Shared libraries referenced in thelibraries.xml configuration files




14/58

Resource Adapter Archive (RAR)files referenced in the resources.xmlconfiguration files

Table 2. Backup directory storage requirements for WBIPostUpgradeCommand WBIPostUpgrade

Location New configuration relative to the new profile rootdirectory. Size of the following items for the oldProcess Server V6.2.0.x profiles.

profile_root/installableApps directory

profile_root/installedApps directory

profile_root/config directory

profile_root/properties directory

Shared libraries referenced in thelibraries.xml configuration files

Resource Adapter Archive (RAR)files referenced in the resources.xmlconfiguration files

Note: If trace is enabled for WBIPreUpgrade and WBIPostUpgrade scripts, which isthe default, up to 200 MB for each script (depending on the size and complexity ofyour configuration) is required. The traces are saved in the backup directoryspecified.

You can either create the target profiles or allow migration tool to createthem during migration process. The recommendation is to allow themigration tool to create the target profiles. For considerations to be takenwhile creating target profile, see Target profile considerations. In thistutorial, we will allow the migration tool to create target profiles on thetarget environment.Tip: One of the requirements for the target profile is that the Cell nameand Node name need to be the same as the source profile. The ProfileManagement Tool wizard does not provide an option to specify the Cell

name while creating custom profile. Use the manageprofiles commandinstead to create the custom profile. Do notfederate the custom profile.The migration utility will federate it during migration activity.

Note: If you are migrating from a version of Process Server that is earlierthan version 6.0.2.x, you must first migrate to version 6.0.2.x, and thenmigrate to version 6.2.0.x.


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/cmig_vtv_pre_target_profiles.htmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/cmig_vtv_pre_target_profiles.html


15/58

You can either use the migration tool, or a series of command scripts toperform the migration. The migration tool allows you to provide detailsrelated to the migration and to invoke the migration scripts. You candirectly invoke these migration scripts and provide values for the relevantparameters as well. If the migration scripts are used, the following

command line scripts are invoked in the sequence to perform themigration. For disk space requirements, refer to the previous tables.

WBIPreUpgrade: This command, which is run first, saves the existingProcess Server V6.1.2.x configuration and applications into amigration-specific backup directory. In the migration tool, you willprovide a directory location on the file system for themigration-specific backup.

WBIPostUpgrade: This command, which is run next, processes thecontent of the migration-specific backup directory that was createdwith the WBIPreUpgrade command and imports it into the targetenvironment.

WBIProfileUpgrade.ant: This script is automatically invoked byWBIPostUpgrade for all the profiles. This script needs to be runmanually after the WBIPostUpgrade command to upgrade clusters inthe environment. It might also need to be run in special cases wherethe migration did not occur successfully. The script updates enterpriseapplications and configuration settings in a profile. Since the sourceenvironmenthas clusters, you will run this command for the clustersmanually.

Back up the existing Process Server V6.1.2.x databases. Since themigration involves schema upgrade and runtime data migration, thedatabases will be inconsistent to use with the prior environment if the priorenvironment needs to be restored in case of a migration failure.

Normally, if updates are required to any databases supporting ProcessServer components, the update is completed automatically when themigrated server process is started. However, some circumstances requirethat the databases be upgraded manually. You must update thedatabases manually using scripts provided with Process Server V6.2.0.xin the following circumstances:

If the database userID configured for the server does not havesufficient privileges to modify the database tables.

If you used non-default table spaces.

In this exercise, after performing the migration on the profiles, you willperform the migration on WPRCSDB (common database) usingdatabase scripts manually.




16/58

BPC database upgrade is required during the migration. There are twomajor steps.

Schema upgrade using the scripts provided.

BPC runtime data migration using the migradeDB.py script.

For a production system, you must upgrade to the new databaseschema manually. The database server must be running, but theProcess Server servers, where Business Process Choreographer isconfigured, must not be started until after the data migration iscomplete.

In this exercise, after performing the migration on the profiles, you willperform migration on BPEDB (Business Process Choreographerdatabase).

Note: If you are attempting to migrate from Process Server 6.1.2 and

later, the Business Space database migration is required. This part is notcovered in the tutorial. See Postmigration tasks for Business Space.

Application migration:

User applications are binary compatible with the higher versions.They do not need to be modified in any way to run on the latestversions.Note: Before attempting migration on a production or stagingenvironment, we strongly recommend that you test your applicationson the new version of Process Server to make sure the application is

not using deprecated APIs or having JDK related issues.

For all system applications that reside in the /systemApps directory, the newer version of the applications isinstalled.

For all supported applications provided with Process Server V6.1.2.x,such as the Business Rules Manager and Business ProcessChoreographer applications, older versions are updated to ProcessServer V6.2.0.x.

Previous versions of sample applications will be replaced with thelatest version.

Long-running business process instances and human task instances aretaken care of during version-to-version migration as the databases(storing the instances) are migrated. During database migration, thedatabase schema is upgraded and the data is converted to the newschema. After migration, these instances continue to run in the migrated


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/tmig_vtv_post_bspace.htmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/tmig_vtv_post_bspace.html


17/58

environment.

Section 4. Preparing the target environment

In this section, you will install Process Server V6.2.0.0 Fix Pack 1 on both Windows1and Windows2 servers. In the version-to-version migration, the target version isinstalled alongside the previous version. During migration, the configuration data andapplications are copied from the source profiles, transformed, and written into theprofiles created in the target version, which is installed in the same physicalmachine. Migration to a remote location is notsupported in the current releases ofProcess Server. Only standalone profiles can be migrated to a remote location. Thefollowing sub-section provides more information.


In this migration exercise, the Dmgr01 profile in the source environment is migratedto the Dmgr01 profile in the target environment. This is performed in the Windows1server. The Custom01 profile on the source environment is migrated to Custom01profile on the target environment on the Windows1 server. Similarly, the Custom02profile on the source environment is migrated to Custom02 profile on the targetenvironment on the Windows2 server. The details are given in the subsequentsections in the tutorial.

Follow the instructions given in Installing and configuring WebSphere ProcessServer to install Process Server V6.2.0.0 on both the Windows1 and Windows2servers. Follow the instruction provided in Technote: WebSphere Process ServerV6.2.0 Fix Pack 1 (V6.2.0.1) to apply Fix Pack 1. Do not create any profiles duringthe installation. The target profiles are created as part of migration process. Thiscompletes preparation of the target environment.

Section 5. Migration activities

This activity will transform and move the application data and configuration data tothe target environment. The WPRCSDB and BPEDB are upgraded after performingthe migration. The migration activity is best described in the flow chart shown inFigure A. The flow chart provides the general procedure to be followed while


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/welcome_wps_ins.htmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/welcome_wps_ins.htmlhttp://www.ibm.com/support/docview.wss?rs=2307&uid=swg24022185http://www.ibm.com/support/docview.wss?rs=2307&uid=swg24022185http://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/support/docview.wss?rs=2307&uid=swg24022185http://www.ibm.com/support/docview.wss?rs=2307&uid=swg24022185http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/welcome_wps_ins.htmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/welcome_wps_ins.html


18/58

performing the migration on a Process Server environment. In this tutorial, you willfollow this procedure to perform the migration on the source environment.

Figure A. Flowchart describing the migration activity




19/58




20/58

In this section, you will perform the following tasks in the sequence:

Perform migration on the deployment manager

Perform migration on the managed nodes

Perform migration on the cluster

Perform migration on the Business Process Choreographer databasemanually

Perform migration on the deployment manager

During the migration of the Deployment manager profile, the application data (userapplications, system applications, support applications, sample applications) anddeployment environment configuration data (clusters, JMS resources, database

resources of WPSTestEnv) are transformed and copied to the target profile. Thetarget profile is the deployment manager created in .

Table 3. Deployment manager migration

Source profile Target profile Location

/

profiles/Dmgr01

/

profiles/Dmgr01

Windows1 server

The deployment manager has to be migrated before the migration is attempted onthe managed nodes. You will use the migration tool to perform the migration on thedeployment manager. In this sub-section, the Dmgr01 profile in Process Server

V6.1.2.3 is migrated to the Dmgr01 profile of Process V6.2.0.1 (see Table 3).

The steps to perform migration on the deployment manager are:

1. On the Windows1 server, navigate to the/profiles/Dmgr01/bin/ directory.

2. Stop all node agents and servers in the source environment. You can usethe admin console to stop WPSTestEnv and the node agents.

3. Stop the deployment manager by issuing the stopManager.batcommand.

4. Back up all the profiles (Dmgr01, Custom01 on Windows1 server, andCustom02 on Windows2 server) in the source environment.

5. Back up all the databases (in this case, it is WPRCSDB and BPEDB).




21/58

6. Navigate to the /bin/ directory and invoke themigration tool by issuing wbi_migration.bat. The tool opens theMigration Wizard as shown in the Figure 11. Click the Next button.Figure 11. Migration Wizard

7. The migration tool lists all the Process Server installations of the previousversions on the Windows1 server. Select V6.1.2.3 in the list as shown inFigure 12 and click the Next button.Figure 12. Previous versions of WebSphere Process Server




22/58

8. Select the profile to be migrated on the Source profile selection wizard.Since you are performing migration on the deployment manager profile,select Dmgr01 and click the Next button as shown in Figure 13.Figure 13. Source profile selection




23/58

9. On the Target profile selection wizard, select onthe drop down box and click the Next button. This option allows migrationtool to create the target profile (Dmgr01 profile on )as part of the migration process.Figure 14. Target profile selection




24/58

Note: If you have created target profile ahead of time, this is where youselect the target profile.

10. On the Profile creation parameters wizard, provide names for the newprofile and Hostname as shown in Figure 15. Note that the Host namecannot be different from what is provided in the source profile. Click theNext button.Figure 15. Profile creation parameters




25/58

11. On the Migration back directory wizard as shown in Figure 16, providethe directory location for the WBIPreUpgrade task to store the profileconfiguration data. Click the Next button.Figure 16. Migration back directory




26/58

Tip: It is a good practice to use different backup directories for eachprofiles or migration attempt. Some of the files backed up do not have atimestamp and will be overwritten.

12. On the Deployment manager option wizard, note down the warning asshown in Figure 17.Figure 17. Deployment manager option




27/58

13. Provide the deployment manager security credentials on the Additionalmigration options wizard as shown in Figure 18. Click the Next button.Figure 18. Additional migration options - security credentials




28/58

14. On the Migration summary wizard, the tool displays the summary ofactivities as shown in Figure 19. Click the Next button.Figure 19. Migration summary




29/58

15. The migration tool creates a new deployment manager profile with aname of Dmgr01 in the target environment as shown in the next twoscreen shots (Figure 20 and Figure 21). After this step, you can verify thetarget environment (profiles/Dmgr01/logs

directory) for status.16. This task also creates the WBIProfileCreation.Dmgr01.log file in

the Migration back directory/logs directory. Check for anyerrors in the log files. Click the Next button as shown in Figure 21.Figure 20. Target profile created




30/58

Figure 21. Target profile created




31/58

Note: The migration wizard will create a dummy default Dmgr01 profileusing the same source profile template, but will use the Derby databaseas the backend database, irrespective of the database used by the sourceprofile. Do not be alarmed if you see the Dmgr01 profile created for theDerby database. During post-migration, all the configuration files will be

changed to point to the existing database.

17. The migration tool starts the WBIPreUpgrade task. This task takes thebackup of the Dmgr01 profile in the source environment to the backupdirectory as shown in Figure 22 and Figure 23.Figure 22. WBIPreUpgrade task

Figure 23. WBIPreUpgrade task




32/58

18. The WBIPreUpgrade task creates the following log files in theMigration back directory/logs directory. Check for any errors inthese files. Click the Next button.

backupConfig.Dmgr01..log

WBIPreMigrationSummary.log

WBIPreUpgrade..log

19. The migration tool starts the WBIPostUpgrade task as shown in Figure 24and Figure 25. This task restores the configuration from the migrationback directory and moves it to the new Dmgr01 profile created in thetarget environment.Figure 24. WBIPostUpgrade task




33/58

Figure 25. WBIPostUpgrade task




34/58

20. This step also creates several log files in the Migration backdirectory/logs as shown below. Check for any errors in these logsfiles.

WBIMigration.Dmgr01..log

restoreConfig.Dmgr01..log

WBIMigration.Dmgr01..log

WBIProfileUpgrade.Dmgr01..traceout

WBIPostMigrationSummary.log

21. On the Migration status wizard, the tool displays the status of the wholemigration task as shown in Figure 26. Click the Finish button.Figure 26. Migration status wizard

22. The migration task creates several log files, as mentioned earlier, in theMigration back directory/logs directory. Look for any errors inthe log files as shown in Figure 27.Figure 27. Migration logs




35/58

23. As a part of the Dmgr01 profile migration, you also need to upgradeWPRCSDB. This is required because when the deployment manager isstarted, it will connect to WPRCSDB. If the database is not upgraded, thedeployment manager tries to upgrade the database if the user credentialsprovided in the data source have sufficient privileges. However, in thistutorial, you will upgrade the database manually.

24. Navigate to the /dbscripts/CommonDB/DB2/directory and issue the command upgradeSchema.bat 612 WPRCSDB as shown in Figure 28, where is the databaseuser name. You will also have to provide the password on the commandwindow. For detailed instructions, see Upgrading the Common databasemanually.Figure 28. Upgrade CommonDB

Note: The above scripts upgrade the schema to Process Server V6.2.0.0.If you have fix packs installed, use upgradeSchema.bat 620WPRCSDB to upgrade the database schema to the latest fixpack level. If you are using Process Server V6.2.0.1 fix pack for the targetenvironment due to a defect, it is necessary to run upgradeSchema.bat

620 WPRCSDB . See Technote: CWLDB0010E error aftermigrating to WebSphere Process Server V6.2.0.1.

25. Navigate to /profiles/Dmgr01/bin in the Windows1server and start the deployment manager. Verify that it startssuccessfully.


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/tmig_vtv_upg_cdb.htmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/tmig_vtv_upg_cdb.htmlhttp://www.ibm.com/support/docview.wss?uid=swg21391617http://www.ibm.com/support/docview.wss?uid=swg21391617http://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/support/docview.wss?uid=swg21391617http://www.ibm.com/support/docview.wss?uid=swg21391617http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/tmig_vtv_upg_cdb.htmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/tmig_vtv_upg_cdb.html


36/58

26. This is a good time to back up the new Dmgr01 profile if you need torollback in case of managed node migration failure.

27. Start Dmgr01 and make sure there are no errors in the/profiles/logs/Dmgr01/systemout.log

file.

28. Now Dmgr01 is completely migrated from the source environment to thetarget environment.

Note: Now is the right time to back up the new deployment manager. You canrestore the new deployment manager to rollback from a custom node failure. Do notattempt to migrate the node multiple times without restoring the deploymentmanager.

Perform migration on the managed nodes

During the migration of the managed node profile, server specific configurations inthe source profiles are transformed and copied to the profiles in the targetenvironment (Table 4).

Table 4. Managed nodes migration

Task Source profile Target profile Location

1 /profiles/Custom01

/

profiles/Custom01

Windows1 server

2 /profiles/Custom02

/profiles/Custom02

Windows2 server

Perform migration on the Custom01 profile in the Windows1 server

The following steps will perform migration on the Custom01 profile in the Windows1server. Refer to Task 1 in Table 4. This task will perform the following actions:

1. Creates a new Custom01 profile in the target environment() in the Windows1 server.

2. Copy and transform the configuration data from the Custom01 profile inthe source environment () to the Custom01 profilein the target environment.

3. Perform manual synchronization from the Dmgr01 running in the targetenvironment.




37/58

The steps to perform the migration are:

1. Make sure that the deployment manager in the target environment isrunning and the node agent is stopped.

2. Navigate to the /bin directory in the Windows1machine and invoke wbi_migration.bat.

3. The steps are similar to the steps followed while performing migration onthe deployment manager profile Dmgr01. The subsequent steps provideonly screen shots that differ from the Dmgr01 profile migration. Continuenavigating through various wizards and provide the values as shown inthe subsequent steps.

4. On the Source profile selection wizard, select Custom01 profile asshown in Figure 29.

Figure 29. Source profile selection

5. On the Profile creation parameters wizard, provide Custom01 for thename of the new profile. The Host name remains the same as in thesource profile as shown in Figure 30.Figure 30. Profile creation parameters




38/58

6. The migration tool expects that Dmgr01 in the target environment isrunning. You can ignore this message because you have already startedDmgr01 in the previous steps. The WBIPostUpgrade task requiresDmgr01 in the target environment to be running (Figure 31).Figure 31. Deployment manager verification




39/58

7. Provide a directory location for the backup directory on the Migrationbackup directory wizard as shown Figure 32. Provide a directory locationdifferent from what was provided while performing the migration on theDmgr01 profile to avoid mixing up all the log files.

Figure 32. Migration backup directory




40/58

8. The migration tool displays the summary of migration activities. Click theNext button to start the migration as shown in Figure 33.Figure 33. Migration summary




41/58

9. The migration tool performs the following tasks:

a. Creates the Custom01 profile in the target environment.

b. Takes the backup of the Custom01 profile in the WBIPreUpgrade

task.

c. Performs migration of the backup in the WBIPostUpgrade task.

d. Finishes the migration process as shown in Figure 34 and Figure35.





42/58





43/58

10. The log files created as part of the migration are shown in Figure 36.Verify that there are no errors in the log files. The log files are created inthe migration backup directory.Figure 36. Migration log files

This completes the migration of Custom01 in the Windows1 server.

Perform migration on the Custom02 profile in the Windows2 server

The following steps will perform migration on the Custom02 profile in the Windows2server. Refer to Task 2 in Table 4.

This task will perform the following actions:

Creates a new Custom02 profile in the target environment() in the Windows2 server.

Copies and transforms the configuration data from the Custom02 profilefrom the source environment () to the targetenvironment.

Performs manual synchronization from Dmgr01 running in the targetenvironment.

The steps to perform the migration are as follows. These steps are similar to theones followed during migration of the Custom01 profile in the Windows1 server. Wewill only mention the steps where there are differences.




44/58

1. Make sure that the deployment manager in the target environment isrunning and the node agent is stopped.

2. Navigate to the /bin directory in the Windows2server and invoke wbi_migration.bat. Continue navigating the wizards.

3. On the Source profile selection wizard, select Custom02 profile asshown in Figure 37. Continue navigating the wizards.Figure 37. Source profile selection

4. On the Migration summary wizard, the migration tool displays thesummary of migration activity as shown in Figure 38. Click the Nextbutton to start the migration.Figure 38. Migration summary




45/58

5. Like in the case of migrating the Custom01 profile in the Windows1 servershown earlier, the migration tool performs the following tasks:

a. Creates the Custom02 profile in the target environment in theWindows2 server.

b. Performs back up of the Custom02 profile in the WBIPreUpgradetask.

c. Performs migration of the back up in the WBIPostUpgrade task.

d. The migration tool finishes the migration process as shown inFigure 39.Figure 39. Completion of migration process




46/58

6. The log files are created in the backup directory and verified that there areno errors.

Perform migration on the cluster

The migration requires an extra step when there are clusters in the environment. Wehave the following clusters created in the source environment:

WPSTestEnv.AppTarget

WPSTestEnv.Support

WPSTestEnv.Messaging

All the above clusters have their members distributed in Custom01 and Custom02profiles on the Windows1 and Windows2 servers, respectively. As part of themigration process, WBIProfileUpgrade must be run on each of the clusters to

perform the migration at the cluster scope. This transforms or modifies theconfiguration data at the cluster scope.

Notes:

Perform these steps on the machine where the new deployment managerprofile exists.




47/58


48/58

5. Run the syncNode.bat command from the/profiles/Custom01/bin directory on theWindow1 server. Similarly, run the syncNode.bat command from the/profiles/Custom02/bin directory on theWindows2 Server. This step synchronizes changes to the clusters fromthe deployment manager.

6. Do not start the cluster members until the next step is completed.

Perform migration on the Business Process Choreographerdatabase manually

In this sub-section, you will upgrade the Business Process Choreographer database.There are two tasks involved in this process:

Upgrade the Business Process Choreographer database schema

Migrate the Business Process Choreographer runtime data

The source environment uses the BPEDB database for storing the BPEL andHuman Task related data. Before any cluster members of WPSTestEnv.AppTargetcluster are started, you need to migrate BPEDB.




49/58

Upgrade the Business Process Choreographer database schema

The first task is to upgrade the database schema:

1. Open a command window and submit the DB2CMD command. Thisopens the DB2 command window to run the DB2 scripts.

2. Navigate to the/dbscripts/ProcessChoreographer/DB2 directoryon the DB2 command window and submit the following command:

db2 -tf upgradeTablespaces612.sql

3. Open the/dbscripts/ProcessChoreographer/DB2/

upgradeSchema612.sql file in a text editor and replace @SCHEMA@with the schema name where the database objects of BPEL and humantask are created in the BPEDB database. The schema name is the nameprovided against BPEDB on the database configuration wizard, whilecreating the WPSTestEnv deployment environment.

4. On the same DB2 command window, submit the following command:

db2 -tf upgradeSchema612.sql

5. Verify that the scripts can run successfully without any errors.

Migrate the Business Process Choreographer runtime data

The second task is to upgrade the runtime data of the BPEDB. This will upgrade thedata related to BPEL and human tasks instances running in the source environmentbefore the migration is performed. Migrating runtime data will allow these instancesto be valid after the migration. Users can work on these instances in the targetenvironment after the migration. Time to complete this step depends on thedatabase content. See Technote: Complementary data migration documentation.

Migration of runtime data should be run only once from one of the nodes after themigration and before stating the cluster members.

The following steps describe the procedure to upgrade the runtime data:

1. Open a command window and navigate to/profiles/Custom01/bin and submit the following


http://www.ibm.com/support/docview.wss?rs=2307&uid=swg21327385http://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/support/docview.wss?rs=2307&uid=swg21327385


50/58

command:

wsadmin -conntype NONE -tracefile C:\temp\migrateDB.traceout -f\ProcessChoreographer\admin\migrateDB.py-cluster WPSTestEnv.AppTarget -dbUser -dbPassword -dbSchema -slice 5000

a. is the schema in which BPEL/Human tasksdatabase objects are created in the BPEDB database.

b. The migrateDB.py script will gather all the required informationfrom the local configuration repository. Note that dbUSER anddbSchema are optional if the -dbUser configured for the BPCDBdatasource have privileges to modify the database schema.Review all the options for migrateDB.py script in Migrating theBusiness Process Choreographer runtime data.

Section 6. Post-migration activities and verification

In this section, you will examine the target environment and verify if the migrationprocess has successfully created the corresponding objects in the targetenvironment. You will verify the following objects in the target environment:

The profiles are properly created.

The deployment environment is migrated.

The user and support applications are migrated.

The failed events generated in the source environment are migrated tothe target environment.

The pending BPEL and human tasks instances are migrated to the targetenvironment.

The following steps describe the procedure to perform the above tasks:

1. Restart the deployment manager in the target environment.

2. Open the admin console and observe that the nodes are federated andthey show the version as WPS V6.2.0.1 as shown in Figure 41.Figure 41. Verifying the nodes


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/tmig_vtv_upg_bpcdb_mig.htmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/tmig_vtv_upg_bpcdb_mig.htmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/tmig_vtv_upg_bpcdb_mig.htmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/tmig_vtv_upg_bpcdb_mig.html


51/58

3. Verify that the new versions of the enterprise applications are installed asshown in Figure 42.Figure 42. Verifying the enterprise applications




52/58

4. Verify that WPSTestEnv is created in the target environment as shown inFigure 43.Figure 43. Verifying the clusters in the deployment environment




53/58

5. Start the node agents and the WPSTestEnv deployment environment.

6. Verify that all the enterprise applications are started as shown in Figure44.Figure 44. Starting the enterprise applications




54/58

7. Verify that the failed events generated before the migration are listed asshown in Figure 45.Figure 45. Verify the failed events




55/58

8. The BPEL instances, which were in the running state before themigration, can be worked on in the BPCExplorer. Open the BPCExplorerand click the My To-dos link as shown in Figure 46.Figure 46. Verify the human tasks

9. Complete the human tasks by checking the check box and clicking theWork-on button as shown in Figure 47.

Figure 47. Complete the human tasks

You have verified the target environment after the migration and also successfullymigrated the application data, configuration data, database schema, and runtimedata.




56/58

Section 7. Conclusion

This tutorial described in detail the migration process. This involved migration ofconfiguration data, application data, and databases that were performed in aspecified sequence. The tutorial also provided details of various subtasks and thelocations where the migration log files were created for troubleshooting. Thisexercise provided a clear picture of the migration process by highlighting stepswhere administrators need to be extra cautious to avoid losing valuable businessdata.




57/58

Downloads

Description Name Size Downloadmethod

EAR files code_sample.zip 90KB HTTP

Information about download methods


http://public.dhe.ibm.com/software/dw/wes/0911_madgula/code_sample.ziphttp://www.ibm.com/developerworks/library/whichmethod.htmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/developerworks/library/whichmethod.htmlhttp://public.dhe.ibm.com/software/dw/wes/0911_madgula/code_sample.zip


58/58

Resources

Learn

WebSphere Process Server V6.2 Information Center

WebSphere Process Server V6.2 Information Center: Migrating to WebSphereProcess Server

WebSphere Process Server version-to-version migration patterns and bestpractices

Configuring deployment environments in WebSphere Process Server V6.1.2.x

IBM Redbooks on WebSphere Process Server

WebSphere Process Server product support

Complimentary data migration documentation

Technotes/Techdocs on migration

WebSphere Process Server migration planning sheet

Discuss

WebSphere Process Server discussion forum

About the authors

Phani MadgulaPhani Madgula works on WebSphere Process Server Support at the India SoftwareLabs (ISL). He has 6 years experience at IBM. He worked in various product teams,including WebSphere Application Server Community Edition, WebSphere BusinessIntegration Adapters, and DB2. He has experience in developing JEE applications,product support, and database administration. He is an Oracle9i certifiedprofessional.

Rajiv MadasseryRajiv Madassery works as a Principal Software Engineer for the WebSphereProcess Server Level 2 Support Team at the India Software labs (ISL). Rajiv joinedIBM in 2003 and has worked with the WebSphere Business Integration Adapters

http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/welcome_wps.htmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.websphere.wps.620.doc/doc/welcome_wps_mig.htmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.websphere.wps.620.doc/doc/welcome_wps_mig.htmlhttp://www.ibm.com/developerworks/library/ws-wpsmigration/index.htmlhttp://www.ibm.com/developerworks/library/ws-wpsmigration/index.htmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r1mx/topic/com.ibm.websphere.wps.612.doc/doc/welcome_config.htmlhttp://www.redbooks.ibm.com/cgi-bin/searchsite.cgi?query=WebSphere+AND+Process+AND+Server&SearchOrder=1&SearchFuzzy=http://www.ibm.com/software/integration/wps/support/http://www.ibm.com/support/docview.wss?rs=2307&context=SSQH9M&context=SSLLVC&q1=Migration&uid=swg21327385&loc=en_US&cs=utf-8&lang=enhttp://www.ibm.com/support/search.wss?rs=2307&tc=SSQH9M%2BSSLLVC&q=Migrationhttp://www.ibm.com/support/docview.wss?rs=2307&context=SSQH9M&context=SSLLVC&q1=Migration+planning&uid=swg27015595&loc=en_US&cs=utf-8&lang=enhttp://www.ibm.com/developerworks/forums/forum.jspa?forumID=820http://www.ibm.com/developerworks/forums/forum.jspa?forumID=820http://www.ibm.com/support/docview.wss?rs=2307&context=SSQH9M&context=SSLLVC&q1=Migration+planning&uid=swg27015595&loc=en_US&cs=utf-8&lang=enhttp://www.ibm.com/support/search.wss?rs=2307&tc=SSQH9M%2BSSLLVC&q=Migrationhttp://www.ibm.com/support/docview.wss?rs=2307&context=SSQH9M&context=SSLLVC&q1=Migration&uid=swg21327385&loc=en_US&cs=utf-8&lang=enhttp://www.ibm.com/software/integration/wps/support/http://www.redbooks.ibm.com/cgi-bin/searchsite.cgi?query=WebSphere+AND+Process+AND+Server&SearchOrder=1&SearchFuzzy=http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r1mx/topic/com.ibm.websphere.wps.612.doc/doc/welcome_config.htmlhttp://www.ibm.com/developerworks/library/ws-wpsmigration/index.htmlhttp://www.ibm.com/developerworks/library/ws-wpsmigration/index.htmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.websphere.wps.620.doc/doc/welcome_wps_mig.htmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.websphere.wps.620.doc/doc/welcome_wps_mig.htmlhttp://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/welcome_wps.html

Documents

0911 Madgula PDF