Migrating the Business Space database data (V6.x)

IBM BPM, V8.0.1, All platforms > Migrating and upgrading your IBM BPM environment > Migrating from previous versions > Migrating your IBM BPM Advanced V7.5.x or WebSphere Process Server V7.x or V6.2.x runtime > Runtime migration subprocedures > Migrating databases
Migrating the Business Space database data (V6.x)

After manually upgrading the product databases (which upgrades the Business Space database schema), you must migrate the Business Space database data.

Before you upgrade the database data, make sure you have completed the steps in Manually upgrading the product databases.
Important: When migrating Business Space data, the personalized information that is migrated for every Business Space user is limited to 10 of the most recently viewed pages and 60 of the most recently adjusted widgets. When migrating Business Space data to V8.0.1, use the same LDAP that you used for the previous version.

Procedure
If you have enabled specific BPM product widgets for remote endpoints, and the product for the widgets is not installed on the target system (the system you are migrating to), install the product widgets manually after profile migration. A remote endpoint is a service endpoint that resides on a system that is "remote" to the Business Space server (that is, the service endpoint is not collocated with the Business Space server).

For example, in a configuration where you have two profiles, one for IBM BPM and the other for IBM Business Monitor and install Business Space on the server in the IBM Business Monitor profile, and have enabled the IBM BPM widgets for remote endpoint, install the IBM BPM widgets in the server after profile migration. To do this, use the following procedure:

Copy the widget package files for specific BPM product to a temporary folder in local machine.
Widgets packages can be found in the INSTALL_ROOT\BusinessSpace\registryData\ product_name\widgets directory on the machine where the BPM product is installed.
Using the installBusinessSpaceWidgets command, install the product widgets (with the widget package files) on Business Space in the target installation. See installBusinessSpaceWidgets command.

Copy the widget definition files.
The V8.0.1 widget definition files and any custom widget definition files from a previous version must be copied manually to the following directory on the V8.0.1 target server: profile_root/BusinessSpace/datamigration/widgets.
Depending on your environment, use one of the following procedures:

For a stand-alone or non-clustered managed-node environment, copy the widget files to the target profile.
For a clustered Business Space environment, copy the widget files on all the profiles participating in the cluster.

To copy the widget definition files, use the following procedure.

Copy all of the non-custom Business Space V8.0.1 widget definition files into the profile_root/BusinessSpace/datamigration/widgets directory.
These files can be found by searching for file names containing either iwidget.xml or iWidget.xml in the V8.0.1 profile_root/installedApps directory.
In a ND environment, search for iwidget.xml in the custom profile, rather than in the Deployment Manager (Dmgr) profile.
If you have custom widgets from V7.0 or V6.2, you must copy all of the custom widget definition files to the V8.0.1 installation of Business Space before migrating the Business Space data. To do this, copy all of the custom widget definition files from the earlier versions of Business Space into the profile_root/BusinessSpace/datamigration/widgets directory.

Start the server in the target environment. Depending on your environment, use one of the following procedures:

For a stand-alone environment, start the target server.
Start the migration target server using the startServer command from the profile_root/bin directory of the migration target server or from the target profile's First steps console.
Use the following syntax:

startServer.sh server_name
startServer.bat server_name

For more information about the startServer command, see startServer command in the WebSphere Application Server information center.
For a ND environment, use the following procedure.

Important: Perform the procedure using one of the following methods, depending on how the ND environment is configured:

If the Business Space database being updated belongs to a non-clustered managed node where Business Space is configured, start the node agent and the server on the node.
If the Business Space database being updated belongs to a clustered environment, select a node that is participating in the cluster and start the node agent and server on it.
For a Business Space clustered environment, only one node participating in the cluster needs to be started.

Start the migration target node agent.
Start the migration target node agent using the startNode command from the profile_root/bin directory of the migration target server.
Use the following syntax:

startNode.sh
startNode.bat

For more information about the startNode command, see startNode command in the WebSphere Application Server information center.
Start the migration target servers.
Start the migration target server using the startServer command from the profile_root/bin directory of the migration target server or from the profile's First steps console.
Use the following syntax:

startServer.sh server_name
startServer.bat server_name

For more information about the startServer command, see startServer command in the WebSphere Application Server information center.

Migrate the Business Space data.

To prevent timeout errors, modify the com.ibm.SOAP.requestTimeout property by editing the soap.client.props file that is located in the properties subdirectory of the profile_root directory, where profile_root is the node that the migration target server belongs to. Change com.ibm.SOAP.requestTimeout value from 180 to a larger value, such as 1800, which is 30 minutes.

On the node for which the target server was started in the previous step, run the migrateBSpaceData script to migrate Business Space V6.2 data to Business Space V8.0.1.
Choose the script for your operating system:

migrateBSpaceData.bat

migrateBSpaceData.sh

The script is located in the following directory: target_INSTALL_ROOT/BusinessSpace/scripts/. For more information about the migrateBSpaceData script, see migrateBSpaceData command-line utility.
After running the migrateBSpaceData command on the custom node profile, to generate the directory for endpoints or catalogs, you must manually copy the directory that you generated from custom node machine to the dmgr machine.
Attention: If you fail to perform step 4.c , you are presented with the following error: wsadmin>$AdminTask updateBusinessSpaceWidgets {-clusterName MyTop1.Support -endpoints /opt/BPM75/profiles/Custom01/BusinessSpace/datamigration/endpoints} CWMO1132E: No endpoint files found. The path to the endpoints file does not exist: [/opt/BPM75/profiles/Custom01/BusinessSpace/datamigration/endpoints]
Optional: Migrate the widget catalog for custom widgets.
If you have custom widgets and you are migrating a ND environment, run the updateBusinessSpaceWidgets command on the dmgr profile to populate the migrated widget catalog of the custom widgets that were generated in XML format under the following folder: profile_root/BusinessSpace/datamigration/catalog. Launch the updateBusinessSpaceWidgets command from the profile_root\bin directory of the dmgr profile.
Jython example:
AdminTask.updateBusinessSpaceWidgets('[-clusterName  cluster_name -catalogs  profile_root/BusinessSpace/datamigration/catalog]')
Jacl example:
$AdminTask updateBusinessSpaceWidgets {-clusterName  cluster_name -catalogs  profile_root/BusinessSpace/datamigration/catalog }
Catalog files are generated only if you have custom widgets.
For more information about the updateBusinessSpaceWidgets command, see updateBusinessSpaceWidgets command.
For ND environments, migrate the widget endpoints for both product and custom widgets.
If you are migrating a ND environment, run the updateBusinessSpaceWidgets command on the dmgr profile to populate the migrated widget endpoints for both product and custom widgets that were generated in XML format under the following folder: profile_root/BusinessSpace/datamigration/endpoints. Launch the wsadmin environment for the updateBusinessSpaceWidgets command from the profile_root\bin directory of the dmgr profile.
This step is not necessary for stand-alone environments.
For more information about the updateBusinessSpaceWidgets command, see updateBusinessSpaceWidgets command.
Jython example:
 AdminTask.updateBusinessSpaceWidgets('[-clusterName  cluster_name -endpoints  profile_root/BusinessSpace/datamigration/endpoints]')
Jacl example:
$AdminTask updateBusinessSpaceWidgets {-clusterName  cluster_name -endpoints  profile_root/BusinessSpace/datamigration/endpoints }
Stop the target server. Depending on your environment, use one of the following procedures:

For a stand-alone environment, stop the target server.
Stop the migration target server using the stopServer command from the profile_root/bin directory on the migration target system.
Use the following syntax:

stopServer.sh server_name -username user_name -password password
stopServer.bat server_name -username user_name -password password

If the profile has security enabled the user name provided must be a member of the operator or administrator role.
If security is enabled, the -username and -password parameters do not have to be specified if the server is running as a Windows service. In this case, the parameters are automatically passed into the script that the Windows service uses to shut down the server.
If the profile does not have security enabled the -username and -password parameters are not necessary.
For more information about the stopServer command, see stopServer command in the WebSphere Application Server information center.
For a ND environment, stop the servers in the target cluster that were started in Step 3.
Repeat this step for each server in the cluster.
Stop the migration target server using the stopServer command from the profile_root/bin directory on the migration source target.
Use the following syntax:

stopServer.sh server_name -username user_name -password password
stopServer.bat server_name -username user_name -password password

If the profile has security enabled the user name provided must be a member of the operator or administrator role.
If security is enabled the -username and -password parameters do not have to be specified if the server is running as a Windows service. In this case, the parameters are automatically passed into the script that the Windows service uses to shut down the server.
If the profile does not have security enabled the -username and -password parameters are unnecessary.
For more information about the stopServer command, see stopServer command in the WebSphere Application Server information center.

Verify the previous profile migration and data migration steps are all successful.

Check all the migration traces and logs.
Log in to Business Space to check that all the user-created spaces have been migrated.

Remove obsolete database tables by running either the postMigrateBusinessSpace612.sql or the postMigrateBusinessSpace620.sql script.

Log on to the database server as a user with read and write access on the database.
Connect to the database.
Locate the postMigrateBusinessSpace612.sql script or the postMigrateBusinessSpace620.sql script for your database in the profile that you most recently configured, and save it to a location on the same system with the database.
By default, the scripts are located in the following directory for a stand-alone server: profile_root/dbscripts/BusinessSpace/ node_name_ server_name/ database_product_name/ database_name and the following directory for a cluster: deployment_manager_profile_root/dbscripts/BusinessSpace/ cluster_name/ database_product_name/ database_name. The script is located in the profile for the server or cluster that you most recently configured.
Important: This script might need to be modified if the default values do not match your environment.
Change to the directory where you copied the script, and run the postMigrateBusinessSpace612.sql script or the postMigrateBusinessSpace620.sql script, as described in the header of the file.
Results

The Business Space database data is migrated to the Business Space V8.0.1.
Tip: Previous superuser settings that defined Business Space administrators might be lost after the migration from V6.x to V8.0.1. Set the superusers for V8.0.1 using the steps in Assigning the Business Space superuser role.

Migrating databases