process server migration

© Copyright IBM Corporation 2010 TrademarksMigrating to WebSphere Process Server Version 7 Page 1 of 62

Migrating to WebSphere Process ServerVersion 7Migrating from WebSphere Process Server V6.2.0.x toV7.0.0.x

Phani Madgula ([email protected])Software EngineerIBM

Rajiv Madassery ([email protected])Principal Software EngineerIBM

Skill Level: Intermediate

Date: 03 Mar 2010

This tutorial provides instructions on migrating from WebSphere® Process ServerV6.2.0.2 to V7.0.0.1. It highlights steps where administrators need to be cautiousto prevent losing valuable business data.

Section 1. IntroductionThis tutorial is presented in similar lines as Migrating to WebSphere Process ServerV6.2. However, WebSphere Process Server V7.0 (hereafter called Process Server)brings forth an improved set of tools and commands that help in performing themigration. It also presents a new set of terminology that helps customers understandthe whole migration process clearly, thereby reducing the chances for any mistakesbeing committed while performing the migration. Different migration methods arerecommended according to requirements or constraints that customers may have ontheir running deployment environments. The migration types distinguish migrationof a standalone profile from migration of a clustered environment. In summary, themigration process takes a unique procedure, depending on the requirements orconstraints and the source type environment. Based on experience over the years,the Process Server development team has accumulated significant improvements inthe V7.0 migration process.

With the release of the latest versions of Process Server and older versions goingout of support, there is always an urge to move the running environments to the

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

http://www.ibm.com/developerworks/ibm/trademarks/

mailto:[email protected]

mailto:[email protected]

http://www.ibm.com/developerworks/websphere/tutorials/0911_madgula/index.html

http://www.ibm.com/developerworks/websphere/tutorials/0911_madgula/index.html

developerWorks® ibm.com/developerWorks/

Migrating to WebSphere Process Server Version 7 Page 2 of 62

latest supported versions. The latest releases of the product will bring new functionalcapabilities along with fixes for known defects. They are generally more reliablethan earlier versions. However, the current running environments and applicationsmight have been well configured, fine tuned, and robustly tested for the customrequirements of the business. This is a challenge for customers if there is noautomatic way of performing migration on the configuration and application data fromthe current version to the latest version. Manually creating the same environment inthe latest version is laborious and error-prone. To help customers move to the latestversions automatically, a set of procedures along with the tools and commands areavailable in the latest versions. When customers decide to move to a latest majorversion 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 sidethe current version. A set of migration tasks are performed to copy and transformconfiguration data, relevant application data, and database schema from the currentversion 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 thelatest versions. The applications running in a Process Server environment make useof various components, such as Service Integration Bus (SIB), Business ProcessChoreographer (BPC), Business Space, and so on. Each of these componentsuses databases to store runtime data. Therefore, the risks involved in the migrationprocess need to be properly understood and proper backup and restore planshave to be in place before performing the migration. This avoids losing valuablebusiness data in case of a migration failure. In addition to the above aspects,administrators must also follow specific recommendations and procedures if theircurrent Process Server environment has profiles created with different capabilities,augmentation levels, and clusters. If users require minimum downtime, there arespecific procedures that need to be followed to perform the migration. For moreinformation, see the WebSphere Process Information Center topic, Migrationoverview.

In this tutorial

This tutorial provides a step-by-step procedure to migrate from Process ServerV6.2.0.2 to V7.0.0.1. It illustrates the procedure as follows:

• An example deployment environment, configured for gold topology on ProcessServer V6.2.0.2 is chosen as the source environment. The source environmentis migrated to Process Server V7.0.0.1. The migrated deployment environmentin Process Server V7.0.0.1 is referred to as a target environment.

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/topic/com.ibm.websphere.wps.doc/doc/cmig_vtv_bpmmig_ovw.html

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/topic/com.ibm.websphere.wps.doc/doc/cmig_vtv_bpmmig_ovw.html

ibm.com/developerWorks/ developerWorks®


• A sample BPEL application containing a human task is deployed onto thesource environment. Before starting the migration, some BPEL instances willbe started and left in running state. After performing the migration, these BPELinstances will be worked on in the target environment. This illustrates the BPCdatabase schema or runtime data migration.

• Similarly, a sample application that generates failed events is deployed on tothe source environment. A sample set of failed events are generated beforemigration. After performing the migration, the failed events will be retrieved inthe target environment. This illustrates the application compatibility with the newversion.

• The migration wizard tool is used to perform the migration. The application dataand configuration data are migrated using this tool.

• The database schema and runtime data are migrated using database scripts.

Note on WebSphere Process Server fix packs

In this tutorial, we are using Process Server V6.2.0.2 for the sourceenvironment and Process Server V7.0.0.1 for the target environment. Theprocedure is the same when migrating from Process V6.2.0.x (from anyfix pack) to Process Server V7.0.0.x (to any fix pack). On the target side,we recommend applying the latest fix packs before starting the migrationprocess.

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

Prerequisites

• 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 onthe 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.

System requirements

For the migration exercise illustrated in the tutorial, the following environment isrequired:

• Two Microsoft® Windows 2003 servers, or Windows XP Service Pack 2desktops with at least 2 GB of RAM



• IBM® DB2 Fix Pack 9.5.0.1• IBM WebSphere Process Server V6.2.0 Fix Pack 2• IBM WebSphere Process V7.0.0.0 Fix Pack 1

Duration

• Configuring the source (WebSphere Process Server V6.2.0.2) environment: 8hours

• Performing the migration: 6 hours

Section 2. Configuring the source environment

We will use two Windows servers in this tutorial. We refer them as Windows1 andWindows2 servers. On both Windows servers, Process Server V6.2.0 Fix Pack 2 andProcess Server V7.0.0 Fix Pack 1 will be installed. On the Windows1 server, DB2is also installed for the common database, the Business Process Choreographerdatabase.

In this section, you perform the following tasks:

• Installing WebSphere Process Server V6.2.0 Fix Pack 2• Installing IBM DB2 Fix Pack 9.5.0.1• Configuring deployment environment with gold topology• Deploying the sample modules

Installing WebSphere Process Server V6.2.0 Fix Pack 2

Install Process Server V6.2.0 Fix Pack 2 on both Windows servers. For instructionson how to install Process Server V6.2.0.2, see Installing and configuring WebSphereProcess Server. Do not create any profiles during the installation. The requiredprofiles will be created separately after the installation task is completed. Afterinstalling the base Process Server V6.2.0.0, apply Fix Pack 2 by following theinstructions in Technote: WebSphere Process Server V6.2.0 Fix Pack 2 (V6.2.0.2).We are not going to discuss in detail the installation procedure in this tutorial as it isalready documented in the Information Center.

After installing Process Server V6.2.0 Fix Pack 2, verify the installation by running thefollowing command and observing the version in the output:

http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.websphere.wps.620.doc/doc/iins_choose_install.html

http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.websphere.wps.620.doc/doc/iins_choose_install.html

http://www-01.ibm.com/support/docview.wss?rs=2307&uid=swg24024492



<WPS6.2.0.2_home>\bin>versionInfo.batInstalled Product---------------------------------------------------------------------

Name IBM WebSphere Application Server - NDVersion 6.1.0.25ID NDBuild Level cf250922.06Build Date 6/1/09

Installed Product---------------------------------------------------------------------

Name IBM WebSphere Process ServerVersion 6.2.0.2ID WBIBuild Level of0936.02Build Date 9/11/09

Here, <WPS6.2.0.2_home> refers to the directory where Process Server V6.2.0.2 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 productdocumentation 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 goldtopology

In this section, you will configure the source environment. A deployment environmentthat has an application cluster, support cluster, and messaging cluster iscreated. Each cluster has a cluster member configured in the profiles created in<WPS6.2.0.2_home> on both Windows servers. We are not going to discuss in detailthis topic as there are already many developerWorks articles and IBM Redbookspublished on this topic. To help you get the deployment environment ready, seeBuilding clustered topologies in WebSphere Process Server V6.2.

The WPRCSDB and BPEDB databases are created to store common databaserepository and Business Process Choreographer data, respectively. These databasesare created in DB2. The name of the deployment environment is WPSMgEnv. Thefollowing steps help you create and configure the deployment environment:

1. Create WPRCSDB and BPEDB databases in DB2 as shown in the Figure 1.

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.server.doc/doc/r0025127.html

http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.server.doc/doc/r0025127.html

http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wps.620.doc/doc/ctut_buildingclusteredtopologies.html



Figure 1. Databases created in DB2

2. Create the deployment manager profile Dmgr01 in <WPS6.2.0.2_home> on theWindows1 server. Specify WPRCSDB for the common database while creating theprofile.

3. Create a managed profile Custom01 in <WPS6.2.0.2_home> on the Windows1server.

4. Create a managed profile Custom02 in <WPS6.2.0.2_home> on the Windows2server.

5. Federate both the Custom profiles to Dmgr01.6. Create a deployment environment with a golden topology with a name of

WPSMgEnv. Follow the steps provided in Building clustered topologies inWebSphere Process Server V6.2.

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

8. 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 for CommonEvent Infrastructure (CEI).

9. Configuring Business Space as part of the Deployment EnvironmentConfiguration wizard explains how to configure Business Space in ProcessServer V6.2. The database objects must be manually created for BusinessSpace. If the database objects are not created, support cluster members throwSQL exceptions while they are starting. These errors do not block any otheractivity in the Process Server unless Business Space components are usedin the applications. In this tutorial, we do not cover the migration activity forBusiness Space component. However, the procedure remains similar to othercomponents.

10. After generating the deployment environment, the cell topology will look likeFigure 2.



http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wbpm.bspace.config.620.doc/doc/tcfg_bsp_depenv.html

http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/index.jsp?topic=/com.ibm.websphere.wbpm.bspace.config.620.doc/doc/tcfg_bsp_depenv.html



Figure 2. Cell topology

Note on the topology in the source environment: In Figure 2, thephani2CellManager01 node corresponds to the Dmgr01 profile and phani2Node05corresponds to the Custom01 profile. These nodes are created as part of theDmgr01 and Custom01 profile creation activity on the Windows1 server. Thermadasse3Node06 corresponds to the Custom02 profile and created as part of theprofile creation on the Windows2 machine. Once the deployment environment isgenerated, a similar topology, perhaps with different names for nodes, will be createdfor you as well. However, the names of the three clusters will be the same if you haveused WPSMgEnv as the name for the deployment environment.

Deploying the sample modules

You can deploy in the source environment two sample applications in the providedEAR_file_samples.zip file. These applications will be used to generate some failedevents and to create business process instances. We will later verify in the targetenvironment whether the failed events and process instances are intact during post-migration.

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



2. Start the WPSMgEnv deployment environment. After starting the deploymentenvironment, the status is shown as in Figure 3.

Figure 3. Starting the deployment environment

3. Check the logs of all the cluster members for any errors. If there are any fatalexceptions, fix those errors before proceeding further.

4. Download the HelloWorldWithBOApp.ear and ToDoTaskApp.ear files.5. Install them on to the WPSMgEnv.AppTarget cluster and start the applications

as shown in Figure 4.



Figure 4. Starting the sample applications

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

7. The ToDoTaskApp.ear application creates a BPEL process template withthe name as RequestProcess. Start several process instances for theRequestProcess template using BPCExplorer. The BPC Explorer applicationis installed on the WPSMgEnv.Support cluster. Find out the HTTP port of anycluster member of the WPSMgEnv.Support cluster and open the BPC Explorerusing http://<hostname>:<port>/bpc. If the link does not open the BPCExplorer application, verify whether the host name and port are added to thevirtual host that is mapped.

8. After starting several process instances, click on the My To-dos link andwork on a few tasks to finish, and leave the remaining tasks as running. Eachprocess instance has a to-do task that expects the user to work on it. Theprocess instances ask a question and expect the user to provide an answerthrough the to-do task. For the finished tasks, the corresponding processinstances will also indicate their status as finished.



9. The process instances created or finished are displayed on the BPC Exploreras shown in Figure 5.

Figure 5. Process instances in the source environment

10. The task instances, which are kept running, show in the BPC Explorer as shownin Figure 6.

Figure 6. Human tasks running in the source environment

11. You will not work on these tasks now. You will keep these tasks running andstart the migration process. After performing migration, you will come back tothe BPC Explorer to work on the tasks. This exercise will show that migrationcan be performed with the running process instances and human tasks.



12. Open a browser window and invoke TestAll.jsp in theHelloWorldWithBOApp.ear application with the link http://localhost:9080/HelloWorldWithBOWeb/TestAll.jsp. This JSP file generates numerous failedevents that you can view in the admin console as shown in Figure 7.Figure 7. Failed events in the source environment

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

Section 3. Pre-migration activitiesVersion-to-version migration process refers to a set of activities that move theconfiguration data, applications, and database data from a previous release toProcess Server V7.0. The migration tools or commands help migrate the entireproduction configuration, applications, and databases. By default, Process Server isbackward compatible for applications developed on previous releases. That is, nomodifications are required for the applications running in the previous versions to runon the latest version. However, the user applications will not be able to use the newfeatures available in the latest release until they are upgraded using the developmenttools. The system applications are upgraded during the migration process.

As indicated earlier in this tutorial, Process Server V7.0 brings new terminology andtools or commands to help performing the migration.

In this section, you will perform the following:

• Migration concepts



• Runtime migration procedure• Runtime pre-migration checklist• Preparing the target environment for migration

Migration conceptsThe fundamental concept in version-to-version migration in Process Server V7.0is the migration methods. The selection of a migration method depends on therequirements or constraints that you may have on the running source deploymentenvironment. There are three types of migration methods to choose from:

• Runtime• Manual• Artifact

Runtime migration (production environment)

In this method, migration procedures or tools are used to move the configurationdata, applications, and database data from the source environment to the targetenvironment. Both the database schema and runtime data are upgraded inline.The source environment is replicated in the target environment. After the migrationprocess completes, the source environment becomes unusable. This methodsupports migration of both clustered environments as well as stand-alone servers.It moves the user applications as-is from the source environment to the targetenvironment. Therefore, they will not be upgraded to make use of the new featuresavailable in Process Server V7.0. The long running process and failed events, whichwere in the state of running in the source environment while migration is beingperformed, are worked on in the target environment after the migration processcompletes. Users prefer this method of migration as it replicates the whole sourceenvironment as-is on the target environment.

On the other hand, downtime of the applications is required to complete themigration. End-to-end testing and validation are to be performed on a stagingenvironment before attempting on the production environment. Administratorsperforming this task must be aware of rollback procedures and chart out a plan toexecute it, in case there is a migration failure.

Manual migration (parallel production environment)

This method is more of a manual process. For more information, see Migrationmethods.

Artifact migration (parallel production environment with development toolmigration)

This method is the same as the manual migration (parallel production environment).In addition, the user applications will also be upgraded using WebSphere IntegrationDeveloper V7.0 to make them compatible with Process Server V7.0.

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/topic/com.ibm.websphere.wps.doc/doc/cmig_vtv_migtypes.html

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/cmig_vtv_migtypes.html

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/cmig_vtv_migtypes.html



In this tutorial, you will perform the runtime migration on the source environment.

Migration tools

In the case of runtime migration, users will have to use the migration tools orcommands to perform the migration. The tools are categorized as follows:

• Profile migration tools• Database upgrade and migration tools

Profile migration tools

These tools or commands help to migrate each source profile from the sourceenvironment to the target environment. Migrating a profile is a three step process:

1. Snapshot the configuration files from the source profile.2. Create the target profile in the target environment.3. Migrate the configuration in the snapshot directory to the target profile.

The following command line tools help to perform the above tasks:

• BPMSnapshotSourceProfile command-line utility• BPMCreateTargetProfile command-line utility• BPMMigrateProfile command-line utility

Process Server V7.0 also provides a profile migration wizard GUI that performsall the above tasks in a sequence. However, the profile migration wizard is notavailable in all the platforms or cannot be used in certain cases of migration. Formore information, see Runtime migration tools.

In this tutorial, you will use the profile migration wizard to perform the migration on allthe profiles.

Database upgrade and migration tools

WebSphere Process Server uses the following databases for operations:

• Business Process Choreographer database• Business Space database• Common database• Common Event Infrastructure database• Messaging Engine database

In this tutorial, you will use the supplied tools and manual procedures to migrate thecommon database and Business Process Choreographer database. The procedureto migrate the other databases is similar in nature. For more information, seeRuntime migration tools.

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/cmig_vtv_tools_ovr.html

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/cmig_vtv_tools_ovr.html



Migration types

Process Server V7.0 introduces the term migration type to distinguish betweenmigration on a stand-alone environment and a deployment environment:

• Stand-alone migration: These are procedures that perform migration on astandalone profile.

• Network deployment migration: In this type of migration, there is adeployment environment involving clusters that need to be migrated. Thedeployment environment may have multiple managed nodes, which may bepart of clusters also. For a deployment environment having clusters, thereare additional steps to be performed to migrate the configuration data at thecluster scope. Since our source environment involves several nodes, we usethe procedures that are mentioned in this category to perform the migration.

Runtime migration procedure

The migration activity is best described in a flow chart shown in Figure 8. The flowchart provides the procedure to perform the migration on the source environment.Each task in the flowchart represents a specific set of actions to be performed. Foreach task, the corresponding reference in the tutorial is also mentioned.

There are tasks in the flow chart that mention taking the backup of profiles at variousstages. The backups are taken when a significant task in the whole migration processcompletes. When the migration process fails at a particular point, the correspondingprofile on which the current activity is being performed might become corrupt. Thebackups help you to restore the profiles from the previous consistent state and re-initiate the migration process from the previous consistent point. During the migration,the source environment is totally shutdown. The procedure consists of steps requiredto perform the runtime migration of a deployment environment, which is configuredfor gold topology with full downtime.

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/cmig_vtv_migenviron.html



Figure 8. Flowchart describing the migration activity

Runtime pre-migration checklistThe Runtime pre-migration checklist topic lists out considerations to be taken inaccount before starting the migration. For our sample source environment created

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/cmig_vtv_premigchecklist.html



in this tutorial, we have to consider storage requirements for the target profiledirectory and the source profile snapshot directory. The database user has sufficientpermissions to execute the database migration scripts.

More importantly, you need to back up the profiles and databases in the sourceenvironment. The databases will be upgraded inline. Hence, taking a backup ofdatabases before starting the migration is paramount and helps you to restore thesource environment, if the migration cannot proceed due to unexpected events. Inthis section, you will perform the following tasks:

• Backup profiles in the source environment• Backup databases in the source environment

Backup profiles in the source environment1. On the Windows1 server, navigate to the <WPS6.2.0.2_home>/bin directory

and submit the following command to back up the Dmgr01 profile:<WPS6.2.0.2_home>\bin\manageprofiles.bat –backupProfile -profileNameDmgr01 -backupFile <target_backup_dir>\Dmgr01.zip

2. Similarly, on the Windows1 server, navigate to the <WPS6.2.0.2_home>/bindirectory and submit the following command to back up the Custom01 profile:<WPS6.2.0.2_home>\bin\manageprofiles.bat –backupProfile-profileName Custom01-backupFile <target_backup_dir>\Custom01.zip

3. Similarly, on the Windows2 server, navigate to the <WPS6.2.0.2_home>/bindirectory and submit the following command to back up the Custom02 profile:<WPS6.2.0.2_home>\bin\manageprofiles.bat –backupProfile-profileName Custom02 -backupFile <target_backup_dir>\Custom02.zip

Backed up profiles can be restored using the –restoreProfile option. For moreinformation, see manageprofiles command.

Note on SOAP Connector propertiesDepending on the size of the applications deployed on the sourceenvironment, we recommend that you set the proper value for the SOAPrequest timeout property in the source profiles. This avoids timing out in theSOAP connector. For more information, see Java Management Extensionsconnector properties.

Back up databases in the source environmentYou need to use the database specific procedures to back up the Process Serverdatabases. In our source environment, we created WPRCSDB and BPEDB in DB2.Backup overview explains backup and recovery procedures in DB2.

Preparing the target environmentIn this section, you will install Process Server V7.0.0 Fix Pack 1 on both Windows1and Windows2 servers. In the version-to-version migration, the target version isinstalled along side 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 physical machine.Migration to a remote location is not supported in the current releases of Process

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/rxml_manageprofiles.html

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/ragt_rconnector_customp.html

http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/ragt_rconnector_customp.html

http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp?topic=/com.ibm.db2.udb.admin.doc/doc/c0006150.htm



Server. Only standalone profiles can be migrated to a remote location. The followingsub-section provides more information.

Installing WebSphere Process Server V7.0.0 Fix Pack 1In our 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 Process Serverto install Process Server V7.0.0.0 on both the Windows1 and Windows2 servers.Follow the instruction provided in Technote: WebSphere Process Server V7.0.0Fix Pack 1 (V7.0.0.1) to apply Fix Pack 1. The fix pack should be installed usingInstallation Manager. Do not create any profiles during the installation. The targetprofiles are created as part of the migration process. This completes the preparationof the target environment.

Section 4. Performing migration on the deploymentmanagerDuring the migration of the deployment manager profile, the application (userapplications, system applications, support applications, sample applications) anddeployment environment configuration data (clusters, JMS resources, databaseresources of WPSMgEnv) are transformed and copied to the target profile. The targetprofile is the deployment manager created in <WPS7.0.0.1_home>.

Table 1. Deployment manager migrationSource profile Target profile Location

<WPS6.2.0.2_home>/profiles/Dmgr01

<WPS7.0.0.1_home>/profiles/Dmgr01

Windows1 server

The deployment manager has to be migrated before the migration is attempted onthe managed nodes. You will use the migration wizard to perform the migration on thedeployment manager. In this section, the Dmgr01 profile in Process Server V6.2.0.2is migrated to the Dmgr01 profile in Process V7.0.0.1 (see Table 1).

The steps to perform migration on the deployment manager are:

1. Stop all node agents and servers in the source environment. Stop theWPSMgEnv deployment environment using the admin console. This activity willstop all the clusters. After this activity, stop all the node agents.

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/topic/com.ibm.websphere.wps.doc/doc/iins_choose_install.html

http://www.ibm.com/support/docview.wss?rs=2307&uid=swg24024941




2. On the Windows1 server, navigate to the <WPS6.2.0.2_home>/profiles/Dmgr01/bin/ directory.

3. Stop the deployment manager by issuing the stopManager.bat command.4. Navigate to the <WPS7.0.0.1_home>/bin/ directory and invoke the migration

wizard by issuing BPMMigrate.bat. The tool opens the Migration Wizard asshown in the Figure 9. Click the Next button.

Figure 9. Migration wizard

5. On the next screen, select the Custom migration by clicking the correspondingradio button as shown in the Figure 10.



Figure 10. Selecting the Custom migration option

6. The migration tool lists all the Process Server installations of the previousversions on the Windows1 server. Select V6.2.0.2 in the list as shown in andclick the Next button. This is the installation where the source environment isconfigured.



Figure 11. Previous versions of Process Server

7. Select the profile to be migrated on the next screen. Since you are performingmigration on the deployment manager profile, select Dmgr01 and click the Nextbutton as shown in Figure 12. Also, provide the user name and password forthe deployment manager.



Figure 12. Source profile selection

8. Provide a directory on the file system for the snapshot directory as shown inthe Figure 13. In the first step, the migration wizard takes a snapshot of thedeployment manager profile in this directory. In the subsequent steps, thedata in this directory is used for the actual migration. The migration wizardalso creates various log and trace files in this directory during the course ofmigration. You will provide a different directory for each profile migration sothat you can better monitor the migration of each profile independently. Afterproviding the snapshot directory, click the Next button.



Figure 13. Snapshot directory

9. Provide the name for the target profile and the directory where the target profileis to be created as shown in Figure 14. Click the Next button.



Figure 14. Target profile name

Note on restrictions while creating the target profile: In Process ServerV7.0, we do not allow migrating into the existing target deployment managercreated using PMT. If you want to create the target profile ahead of time, usethe command line utility BPMCreateTargetProfile to create the profile from thesnapshot directory and use the command utility BPMMigrateProfile command tomigrate the profile. For more information, see Migrating a profile using the BPMcommand-line utilities.

10. Select the application migration setting as shown in Figure 15. Click the Nextbutton.

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/tmig_vtv_sidebysidecommandline.html

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/tmig_vtv_sidebysidecommandline.html



Figure 15. Application migration setting

11. Select the script compatibility setting as shown in Figure 16 and click the Nextbutton.



Figure 16. Script compatibility setting

12. Figure 17 displays the summary of migration activity, which is about to begin.By clicking the Next button, the migration of the deployment manager profilebegins.



Figure 17. Summary of migration activity

13. The migration of a source profile consists of three steps in the followingsequence:

a. Take a backup of the source profile to the snapshot directory. Under thecovers, the following command will be executed to take the snapshot ofthe Dmgr01 profile in the source environment:C:\ibm\WPS7.0\bin\BPMSnapshotSourceProfile.bat C:\ibm\WPS6.2 Dmgr01C:\MigrationSnapshots\WPS6.2\Dmgr01

b. Create the target profile on the target environment. Under the covers,the following command will be executed to create the target profile in thetarget environment:



C:\ibm\WPS7.0\bin\BPMCreateTargetProfile.bat -targetProfileName Dmgr01 -targetProfileDirectory C:\ibm\WPS7.0\profiles\Dmgr01 C:\MigrationSnapshots\WPS6.2\Dmgr01 Dmgr01

c. Migrate the source profile to the target profile. Under the covers, thefollowing command will be created to migrate the source profile to thetarget profile:C:\ibm\WPS7.0\bin\BPMMigrateProfile.bat -username admin -password ******** -targetProfileName Dmgr01 C:\MigrationSnapshots\WPS6.2\Dmgr01 Dmgr01

Figure 18 shows all three steps, where the first step has already started.

Figure 18. Migration execution



14. Step 13a creates the following log and trace files in the logs sub directory ofthe snapshot directory (Figure 19). You can examine these logs to monitorthe progress of the snapshot activity. The log.lck file is a lock file to indicatean instance of an activity taking a snapshot of the Dmgr01 profile that isalready running. This mechanism prevents starting multiple snapshot activitiesinadvertently by different users.

Figure 19. Logs created for snapshot activity

15. After completing the Step 13a, the screen indicates that Step 13b has started.In this step, the target profile is created in the target environment, as shown inFigure 20.



Figure 20. Creating the target profile

16. Like in Step 13a, this step also creates log and trace files as shown in Figure21. These are created in the logs sub directory of the snapshot directory.Note that logs or traces will also be created in the target environment for theprofile creation activity. These are created in the <WPS7.0.0.1_home>/logs/manageprofiles directory. Check these files for any errors generated in theprofile creation.

Figure 21. Logs created while creating target profile



17. After completing Step 13b, the screen indicates that the Step 13c has started. Inthis step, the actual migration of the artifacts from the snapshot directory to thenewly created target profile is performed, as shown in Figure 22.

Figure 22. Migration of the Dmgr01 profile

18. Like in the previous steps, the logs and traces for this step are also createdin the logs sub directory of the snapshot directory,. as shown in in Figure 23.Check for any errors in these log files.



Figure 23. Logs files created during the Dmgr01 migration

19. After all the three steps are completed successfully, the screen indicates thatthe migration of the Dmgr01 is completed, as shown in Figure 24. Click theNext button and close the migration wizard.

Figure 24. Successful completion of Dmgr01 profile



20. In addition to the above log files, messages are also logged into a separatelog file for any errors encountered in the Migration wizard itself. This log file iscreated in the <WPS7.0.0.1_home>/logs/bpm_migration directory, as shown inFigure 25. Check for any errors encountered by the Migration wizard and reportthem to the support team.Figure 25. Migration wizard GUI log file

21. Common database migration: As part of deployment manager profilemigration, the next step is to upgrade the Common database schema toProcess Server V7.0 before starting it in the target environment. You mustupgrade manually if the database user that is defined for the data source doesnot have sufficient authorization to modify the database schema.

a. You will manually upgrade the Common database schema usingupgradeSchema.bat. The upgradeSchema.bat is a command line toolthat you can run interactively to upgrade the Common database. Thelocation of the tool is in <WPS7.0.0.1_home>dbscripts/CommonDB/DB2. Notethat if DB2 is installed in a remote machine, you need to copy the contentsof this folder to the remote machine.

b. When this tool is run, it will prompt the user with several questions tocapture the information regarding the source environment. Figure 26shows the command window running the tool to upgrade the database.After capturing the dbUserId information from the user, it will open a newcommand window and prompt for the password. Once the password isentered, it will upgrade the Common database. Note that dbUserid hassufficient permissions to perform the database schema upgrade.Figure 26. CommonDB schema upgrade

22. After upgrading the Common database, start deployment manager in the targetenvironment. Check for any errors in the logs. This completes the Dmgr01profile migration.

Note on taking backup of target Dmgr01 profileNow is the right time to back up the new deployment manager. You canrestore the new deployment manager to rollback from custom node failure.Do not attempt to migrate the node multiple times without restoring thedeployment manager.



Section 5. Performing migration on the managednodes

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

Table 2. Managed nodes migration

Task Source profile Target profile Location

1 <WPS6.2.0.2_home>/profiles/Custom01

<WPS7.0.0.1_home>/profiles/Custom01

Windows1 Server

2 <WPS6.2.0.2_home>/profiles/Custom02

<WPS7.0.0.1_home>/profiles/Custom02

Windows2 Server

In this section, you will perform the following tasks:

• Performing migration on the Custom01 profile in the Windows1 server• Performing migration on the Custom02 profile in the Windows2 server• Performing migration on the cluster• Performing migration on the Business Process Choreographer database

manually

Performing 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 2. This task is similar to migration of the deploymentmanager profile described earlier. However, we will provide the complete steps toperform the migration on the managed node and highlight the differences. This taskwill perform the following actions:

1. Takes the snapshot of the Custom01 profile in a snapshot directory.2. Creates a new Custom01 profile in the target environment in the Windows1

server.3. Copies and transforms the configuration data from the Custom01 profile in the

source environment to the Custom01 profile in the target environment.4. Performs automatic synchronization from Dmgr01 running in the target

environment.

The steps to perform the migration are:

1. Make sure that the deployment manager in the target environment is runningand the node agent is stopped in the source environment.



2. Navigate to the <WPS7.0.0.1_home>/bin/ directory and invoke the migrationtool by issuing BPMMigrate.bat. The tool opens the Migration wizard as shownin Figure 27. Click the Next button.

Figure 27. Migration wizard

3. Select Custom migration as shown in Figure 28 and click the Next button.



Figure 28. Selecting the Custom migration option

4. The migration tool lists all the Process Server installations of the previousversions on the Windows1 server. Select V6.2.0.2 in the list as shown inFigure 29 and click the Next button. This is the installation where the sourceenvironment is configured.



Figure 29. Previous versions of Process Server

5. Select the profile to be migrated on the next screen. Since you are performingmigration on the Custom profile, select Custom01 and click the Next buttonas shown in Figure 30. Also, provide the user name and password for thedeployment manager.




6. Provide a directory on the file system for the snapshot directory as shownin Figure 31. In the first step, the migration wizard takes a snapshot of theCustom01 profile in this directory. In the subsequent steps, the data in thisdirectory is used for the actual migration. The Migration wizard also createsvarious log and trace files in this directory during the course of migration. Wewill provide a different directory for each profile migration to better monitor themigration of each profile independently. After providing the snapshot directory,click the Next button.




7. Provide the name for target profile and the directory where the target profile isto be created as shown in Figure 32. Click the Next button.



Figure 32. Target profile name

8. Figure 33 displays the summary of migration activity, which is about to begin. Byclicking the Next button, the migration of the Custom01 profile begins.



Figure 33. Summary of migration activity

9. The migration of a source profile consists of three steps:a. Take the backup of the source profile to the snapshot directory. Under the

covers, the following command is executed to take the snapshot of thesource profile:C:\ibm\WPS7.0\bin\BPMSnapshotSourceProfile.batC:\ibm\WPS6.2 Custom01C:\MigrationSnapshots\WPS6.2\Custom01

b. Create the target profile on the target environment. Under the covers,the following command will be executed to create the target profile in thetarget environment:C:\ibm\WPS7.0\bin\BPMCreateTargetProfile.bat-targetProfileName Custom01 -targetProfileDirectoryC:\ibm\WPS7.0\profiles\Custom01C:\MigrationSnapshots\WPS6.2\Custom01 Custom01

c. Migrate the source profile to the target profile. Under the covers, thefollowing command is executed to migrate the source profile:C:\ibm\WPS7.0\bin\BPMMigrateProfile.bat -username admin-password ******** -targetProfileName Custom01C:\MigrationSnapshots\WPS6.2\Custom01 Custom01



Figure 34 shows all three steps, where the first step has already started.

Figure 34. Migration execution

10. Step 9a creates the following log and trace files in the logs sub directory ofthe snapshot directory. You can examine these logs to monitor the progressof the snapshot activity. The log.lck file is a lock file indicating the instanceof an activity is taking a snapshot of Custom01 profile that is already running(Figure 35). This is a mechanism to prevent starting multiple snapshot activitiesinadvertently by different users.

Figure 35. Logs created for snapshot activity



11. After completing Step 9a, the screen indicates that Step 9b is started. In thisstep, the target profile is created in the target environment, as shown in Figure36.

Figure 36. Creating the target profile

12. Like in Step 9a, this step also creates log and trace files as shown in Figure37. These are created in the logs sub directory of the snapshot directory.Note that logs and traces will also be created in the target environment for theprofile creation activity. These are created in the <WPS7.0.0.1_home>/logs/manageprofiles directory. Check these files for any errors generated during theprofile creation.



Figure 37. Logs created while creating target profile

13. After completing Step 9b, the screen indicates that Step 9c has started. In thisstep, the actual migration of the data from the snapshot directory to the newcreated target profile is performed. This is shown in Figure 38. During this step,the migration process performs the following:

a. Changes the local properties.b. Connects to the deployment manager and changes the node information

on the master repository.c. Installs new system applications if required.

Figure 38. Migration of the Custom01 profile



14. Like in the previous steps, the logs and traces for this step are created in thelogs sub directory of the snapshot directory. This is shown in Figure 39. Checkfor any errors in these log files.

Figure 39. Logs files created during the Custom01 migration

15. The Migration wizard synchronizes the target Custom01 profile with the runningof deployment manager as the last step. The changes made at the deploymentmanager (master repository) will be synchronized to the local repository. Thesynchronization step also creates a log file in the logs sub directory, as shown inFigure 40.

Figure 40. SyncNode log file

16. After all three steps have completed successfully, the screen indicates that themigration of the Custom01 is completed, as shown in Figure 41. Click the Nextbutton and close the Migration wizard. This completes the Custom01 profilemigration in the Windows1 server.



Figure 41. Successful completion of Custom01 profile migration

17. In addition to the above log files, messages are also logged into a separatelog file for any errors encountered in the Migration wizard itself. This log file iscreated in the <WPS7.0.0.1_home>/logs/bpm_migration directory. Check forany errors encountered by the Migration wizard GUI tool and report them to thesupport team.

18. In case you experience unexpected errors while performing the migration ofCustom01 profile and the errors cannot be resolved, you need to delete theCustom01 profile in the target environment, restore the backed up Dmgr01profile in the target environment, and perform the migration of Custom01 again.Refer to Step 8 in Figure 8.

Note on taking back up of target Dmgr01 profile aftermigration of Custom01The node1 migration is complete, so now you need to back up the targetdeployment manager. You can restore the deployment manager to rollbackfrom the Custom2 node failure. Do not attempt to migrate the node multipletimes without restoring the deployment manager.



Performing migration on the Custom02 profile in theWindows2 server

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

This task will perform the following actions:

1. Takes the snapshot of the Custom02 profile in a snapshot directory.2. Creates a new Custom02 profile in the target environment in the Windows1

server.3. Copies and transforms the configuration data from the Custom02 profile in the

source environment to the Custom02 profile in the target environment.4. Performs automatic synchronization from Dmgr01 running in the target

environment.

The steps to perform the migration are as follows. These steps are similar to the onesfollowed during migration of the Custom01 profile in the Windows1 server. We willonly mention the steps where there are differences.

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

2. Navigate to the <WPS7.0.0.1_home>/bin/ directory and invoke the migrationtool by issuing BPMMigrate.bat. This opens the Migration wizard.

3. Select Custom02 profile as the source profile on the Source profile selectionscreen. Provide the user name and password of the deployment manager(Figure 42).




4. On the screen where the snapshot directory is prompted by the Migrationwizard, provide a directory on the file system as shown in Figure 43. In thefirst step, the Migration wizard takes a snapshot of the Custom02 profile inthis directory. In the subsequent steps, the data in this directory is used forthe actual migration. The Migration wizard also creates various log and tracefiles in this directory during the course of migration. We will provide a differentdirectory for each profile migration to better monitor the migration of each profileindependently.




5. On the screen where the name for the target profile is prompted by theMigration wizard, provide the name for the target profile and the directory wherethe target profile is to be created, as shown in Figure 44.



Figure 44. Target profile details

6. Like in the case of migration of the Custom01 profile in the Windows1 servershown earlier, the migration tool performs migration on the Custom0 profile. Italso creates corresponding logs in each step of the migration. Check for anyerrors in the logs files. This completes the migration of the Custom02 profile.

7. In case you experience unexpected errors while performing the migration ofCustom02 profile and the errors cannot be resolved, you need to delete theCustom02 profile in the target environment, restore the backed up Dmgr01profile in the target environment, and perform the migration of Custom02 again.Refer to Step 13 in Figure 8.

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

• WPSMgEnv.AppTarget• WPSMgEnv.Support• WPSMgEnv.Messaging

All the above clusters have their members distributed in the Custom01 andCustom02 profiles on the Windows1 and Windows2 servers, respectively. As part



of the migration process, BPMMigrateCluster.bat must be run on each of theclusters to perform migration at the cluster scope. This will transform or modify theconfiguration data at the cluster scope.

Note on migrating clusters

• Perform these steps on the machine where the new deploymentmanager profile exists.

• Use the same backup directory used during the deploymentmanager migration.

The following steps describe the task:

1. Navigate to the <WPS7.0.0.1_home>/bin directory on the Windows1 serverand issue the following commands:

a. BPMMigrateCluster.bat

C:\MigrationSnapshots\WPS6.2\Dmgr01 WPSMgEnv.Messaging

Dmgr01

b. BPMMigrateCluster.bat

C:\MigrationSnapshots\WPS6.2\Dmgr01 WPSMgEnv.Support

Dmgr01

c. BPMMigrateCluster.bat

C:\MigrationSnapshots\WPS6.2\Dmgr01 WPSMgEnv.AppTarget

Dmgr01

2. In the above commands, C:\MigrationSnapshots\WPS6.2\Dmgr01 is thesnapshot directory specified while migrating the Dmgr01 profile.

3. When the above commands are run, a log file and a trace file are created foreach of the commands in the logs sub directory of the snapshot directory asshown in Figure 45. Verify that there are no errors in the log files.



Figure 45. Cluster migration logs

4. Run the syncNode.bat command from the <WPS7.0.0.1_home>/profiles/Custom01/bin directory on the Window1 server. Similarly, run the syncNode.batcommand from the <WPS7.0.0.1_home>/profiles/Custom02/bin on theWindows2 Server. This step synchronizes changes to the clusters from theDmgr01, as shown in Figure 46.



Figure 46. syncNode after cluster migration

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

Performing migration on the Business ProcessChoreographer database manually

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

• Upgrading the Business Process Choreographer database schema• Migrating the Business Process Choreographer runtime data

The source environment uses the BPEDB database for storing the BPEL and HumanTask related data. Before any cluster members of the WPSMgEnv.AppTarget clusterare started, you need to migrate the BPEDB database.

Upgrading the Business Process Choreographer database schema

The first task is to upgrade the database schema. The following steps describe theprocedure to upgrade the database schema:

1. Copy the following file to a temporary directory, for example C:\temp:



<WPS7.0.0.1_home>/ profiles\Dmgr01\dbscripts\ ProcessChoreographer\DB2\BPEDB\<schema_name>/ createSchema.properties

2. Open a command prompt and navigate to a temporary directory and run thefollowing command on the copied file:<WPS7.0.0.1_home>\util\dbUtils\DbDesignGenerator.bat -e

createSchema.properties

3. The DbDesignGenerator.bat is the database design tool in the Process Serverthat creates database design files and generates database scripts. This is anew tool introduced in Process Server V7.0 to help you generate scripts forvarious databases used by Process Server.

4. The above command opens in interactive mode and prompts the user for input.Provide the values as given in Table 3. At the end of the activity, the databasedesign tool will generate the customized database design file for the BPEDBdatabase.

Table 3. Command line arguments for DBDesignGenerator

Database type DB2-distributed

Scenario Migration

Database name BPEDB

Territory Us-en

Database schema name WPRBE00

Use tablespaces false

Tablespace directory /container path

<default>

Tablespace for audit log items <default>

Tablespace for audit log itemsTablespace for instance itemsTablespace for scheduleritemsTablespace for staff queryitemsTabplespace for templateitemsTablespace for work itemtables

<default>

Data source properties Skip

Do you want to save changesback to the same file?

Yes

1. Run the database design tool on the customized database design file togenerate the upgraded scripts:<WPS7.0.0.1_home>\util\dbUtils\DbDesignGenerator.bat-g createSchema.properties -d <output_directory>

2. The above command will generate the database scripts to be run onthe BPEDB database to upgrade the schema in <output_directory>.Since you are migrating from Process Server V6.2.0.2, run the generatedupgradeSchema620.sql file on BPEDB to upgrade the schema. This finishes



the BPEDB schema upgrade. For various options available when using thedatabase design tool, see Upgrading the Business Process Choreographerdatabase schema.

Migrating the Business Process Choreographer runtime data

Since you are migrating from Process Server V6.2.0.2, you do not have to migratethe runtime data using the MigrateDB.py script. This step is applicable only if youare migrating from versions earlier than V6.2.x. For more details, see Migrating theBusiness Process Choreographer database data.

The second task is to upgrade the runtime data of the BPEDB. This will migrate thedata related to BPEL and Human Tasks instances running in the source environment.Migrating runtime data will allow these instances to be valid after the migration. Userscan work on these instances in the target environment after the migration. Time tocomplete this step depends on the database content, see Technote: Complementarydata migration documentation.

Note on migrating the Business Space database

If you have configured Business Space in Process Server V6.2.0.2, youneed to upgrade the Business Space database schema and migrate theruntime data as well. The following links explain the procedure:

• Migrating the Business Space database schema procedure• Migrating the Business Space Database data procedure

Migration of runtime data should be run only once from one of the nodes aftermigration before starting the cluster members.

The Business Process Choreographer database and Business Space database areconfigured at the cluster scope, whereas the Common database is configured at thecell scope.

Section 6. Post-migration activities and verifications

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

• Verify that the profiles are properly created.• Verify that the deployment environment is migrated.• Verify that the user and support applications are migrated.

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/tmig_vtv_upg_bpcdb_schema.html

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/tmig_vtv_upg_bpcdb_schema.html

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/tmig_vtv_upg_bpcdb_mig.html

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/tmig_vtv_upg_bpcdb_mig.html



http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/tmig_vtv_upg_bsdb.html

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/tmig_vtv_upg_bspacedb_mig.html

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/rmig_vtv_bpc_data.html



• Verify that the failed events generated in the source environment are migratedto the target environment.

• Verify that the pending BPEL and human tasks instances are migrated to thetarget environment.

If you have specific configuration settings in the source environment, then you needto perform the post-migration tasks. These are explained in Postmigration tasks.

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

1. Restart the deployment manager in the target environment and start all nodeagents and clusters.

2. Open the admin console and observe that the source environment is migratedto the target environment as-is. The cell topology is the same as in the sourceenvironment, as shown in Figure 47.

Figure 47. Cell topology in the target environment

3. Verify that the cluster members are created in all the clusters as shown in theFigure 48.

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/index.jsp?topic=/com.ibm.websphere.wps.doc/doc/scmig_vtv_postmig.html



Figure 48. Cluster members in the target environment

4. Verify that the deployment environment WPSMgEnv has started successfully asshown in Figure 49.

Figure 49. Deployment environment

5. If there are running instances of the old predefined human task applications,they are not uninstalled during migration. This means that after migration,both the new and old versions of the predefined human task applications arein your system. Make sure that all old instances have been deleted. In theadministrative console, click Applications > Application Types > WebSphere



enterprise applications. If there are multiple versions of any of the followingapplications, select the older applications and click Uninstall.HTM_PredefinedTasks_Vnnn_scope.earHTM_PredefinedTaskMsg_Vnnn_scope.ear

nnn is the version number when the application was last updated, for example620. If the newest version of these applications looks older than the currentrelease, it just means that it has not changed. It is important to only delete theoldest if there is more than one version of the two applications.

Figure 50. Verifying the enterprise applications

6. Open the BPC Explorer in a browser window and click the My To-dos link toobserve that the human tasks are migrated. These human tasks were started inthe source environment and left in running state, as shown in Figure 51.



Figure 51. Runtime migration of Human Tasks

7. Complete the above human tasks and click the Process instances link toobserve that all the process instances are in “finished” state. Two instanceswere finished in the source environment and the remaining two instances werefinished in the target environment, as shown in Figure 52.

Figure 52. Process instances in the target environment

8. Open the admin console in a browser window and click the Failed EventManager link under Integration Applications in the navigation tree. This willopen the failed event manager application. Click the Get all failed events linkto list out the failed events. These failed events were generated in the sourceenvironment and the data was migrated to the target environment during theCommon database migration. This is shown in Figure 53.



Figure 53. Migration of the failed events in the target environment

Section 7. Conclusion

This tutorial described in detail the migration process from WebSphere ProcessServer V6.2.0.2 to V7.0.0.1. This involved migration of configuration data, applicationdata, and databases that were performed in a specified sequence. The tutorial alsoprovided details about various subtasks involved and where to locate the migrationlog files to help with troubleshooting. This exercise provided a clear picture of themigration process by highlighting steps where administrators have to be cautious toprevent losing valuable business data.



Downloads

Description Name Size Downloadmethod

EAR files EAR_file_samples.zip 90KB HTTP

Information about download methods

http://www.ibm.com/developerworks/apps/download/index.jsp?contentid=470684&filename=EAR_file_samples.zip&method=http&locale=

http://www.ibm.com/developerworks/library/whichmethod.html



Resources• Migrating to WebSphere Process Server V6.2• WebSphere Process Server V7.0 Information Center• WebSphere Process Server V7.0 Information Center: Migrating from previous

versions• IBM Redbooks on WebSphere Process Server• WebSphere Process Server product support• Technote: Complimentary data migration documentation• Technotes/Techdocs on migration• WebSphere Process Server migration planning sheet• WebSphere Process Server discussion forum

http://www.ibm.com/developerworks/websphere/tutorials/0911_madgula/

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/topic/com.ibm.websphere.wbpm.help.ic.doc/info/welc6doc.html

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/topic/com.ibm.btools.help.modeler.collab.publish.mig.doc/mig/migrate.html

http://publib.boulder.ibm.com/infocenter/dmndhelp/v7r0mx/topic/com.ibm.btools.help.modeler.collab.publish.mig.doc/mig/migrate.html

http://www.redbooks.ibm.com/cgi-bin/searchsite.cgi?query=WebSphere+AND+Process+AND+Server&SearchOrder=4&SearchFuzzy=

http://www-947.ibm.com/support/entry/portal/Overview/Software/WebSphere/WebSphere_Process_Server

http://www.ibm.com/support/docview.wss?rs=2307&context=SSQH9M&context=SSLLVC&q1=Migration&uid=swg21327385&loc=en_US&cs=utf-8&lang=en

http://www.ibm.com/support/search.wss?rs=2307&tc=SSQH9M%2BSSLLVC&q=Migration

http://www.ibm.com/support/docview.wss?rs=2307&context=SSQH9M&context=SSLLVC&q1=Migration+planning&uid=swg27015595&loc=en_US&cs=utf-8&lang=en

http://www.ibm.com/developerworks/forums/forum.jspa?forumID=820



About the authors

Phani Madgula

Phani Madgula is currently working for WebSphere Process ServerSupport at the India Software Labs (ISL). He has 7 years of experienceat IBM. He worked in various product teams, including WebSphereApplication Server Community Edition, WebSphere Business IntegrationAdapters, and DB2. He has experience in developing JEE applications,product support, and database administration. He is an Oracle9i certifiedprofessional.

Rajiv Madassery

Rajiv Madassery works as a Principal Software Engineer for theWebSphere Process Server Level 2 Support Team at the IndiaSoftware Lab (ISL). Rajiv joined IBM in 2003 and has worked with theWebSphere Business Integration Adapters Functional Verification Testand WebSphere Application Server Level 2 Support teams.

© Copyright IBM Corporation 2010(www.ibm.com/legal/copytrade.shtml)Trademarks(www.ibm.com/developerworks/ibm/trademarks/)

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

http://www.ibm.com/developerworks/ibm/trademarks/

Documents

process server migration