WebSphere Partner Gateway v6.2 - Cross Platform MigrationWPG

8/12/2019 WebSphere Partner Gateway v6.2 - Cross Platform MigrationWPG

1/23

WebSphere Partner Gateway v6.2 Cross platform migration

IBM WebSphere Partner Gateway v6.2

Cross Platform Migration

WPG v6.0 to WPG v6.2

Copyright IBM Corporation 2009. All rights reserved.

Copyright International Business Machines Corporation 2009 Page 1 of 23


2/23


Table of Contents Page

Introduction 3

Notations used in this document 5

Step A: Replicate environment on the target system 6

Step B: Execute scripts to rename duplicate certificates and users 7

Step C: Migration of WPG database from v6.0.0.x to v6.2.0.0 level 9 Step D: Install WPG v6.2.0.0 level 12

Step E: Removal of data for expired certificates and deleted partners. 13

Step F: Apply fixes on WPG v6.2 to resolve Partner Migration issues. 14

Step G: Installation of WPG V6.2 on target platform. 15

Step H: Export/import data using Partner Migration on target machine 16

Known Issues 21 References 23



3/23


Introduction

This document explains the considerations and steps to be followed for performing the migration activity of WebSphere Partner Gateway product

from an existing setup using WPG v6.0.0.x level hosted on Windows environment to a new WPG v6.2 GA level hosted on AIX machine. This

migration would be achieved by performing a mix of the manual migration steps as well as using the smart migration feature available in WPG

v6.2.

The overall steps followed to achieve the migration setup are as below:

Step A: The points to be considered to create the WPG setup on target machine (to act as an backup to existing system) are provided with respect

to the database. The WPG hub will not be recreated. The WPG Common File System will not be replicated here.

Step B: In WPG v6.0 there was no feature to check for unique users and certificates at the entire hub level. In WPG v6.2 all certificate and user

names need to be unique. Because of this discrepancy between WPG v6.0 and WPG v6.2 there are additional scripts provided that would rename

the duplicate certificates and users in WPG v6.0. Instructions on how to access and execute these scripts would be provided in this step.

Step C: The WPG v 6.0 FP3 to WPG v6.2 database migration is carried out on a staging system. This migration is performed by executing the

migration database scripts as explained in details of this step. Note: There are some scripts that are sent along with this document, that need to be

used, along with the already existing other WPG database migration scripts.

Step D: The WPG 6.0 hub is migrated to WPG version 6.2. The hub is migrated using smart migration feature. This migration is also carried out on

the staging environment.

Step E: After completing the migration of WPG to the level of v6.2, a few additional house-keeping scripts would need to be applied. These scripts

will remove all expired certificates from the database. Also there might be some partner configurations that have been deleted in 6.0, but the



4/23


5/23


Notations used in this document

Text in this font is used for the commands to be executed.

Text in this font is used to represent the instructions that need to be followed without fail.

Special Considerations:

Carefully replace the values in .sql files wherever mentioned in the instructions below.Ensure that the files get saved in using unix notations, to avoid any ^M characters to be seen during execution.

.



6/23


Step A: Replicate environment on the target system

One: Database replication:

1. Create WPG users(bcgcon, bcgrecv and bcgdoc) and bcggroup same as the ones existing in the WPG 6.0 production machine

2. Export the WPG v6.0.0.x database backup from the existing WPG V6.0.0 setup.3. Install WPG v6.0 fresh database and hub on a Windows system. DB2 level 8.1 Fixpack 14

a. Execute and install WPG 6.0 GA DBloader . b. Execute and install WPG 6.0.x to match the fixpack level of the database to be restored. NOTE:Give the schema_owner and database user name same as that of exported database in step 1 above .

4. Restore the exported database in step 1.

5. After importing the database dump, the common file system path provided can be checked by examining the LG_MEDIA table. This tablehas two entries- one for msg_store path and other one for non_rep path.

a. If you wish to change the path, you can do that using the following sql commands :i. update LG_MEDIA set URL = where mediaid=1ii. update LG_MEDIA set URL = where mediaid=2



7/23


Step B: Execute scripts to rename duplicate certificates and users

The below steps explain how to execute the scripts to rename duplicate certificates and users. These scripts can be obtained from the technicalnote of WPG Application database housekeeping scripts .

After executing step 3 that has been given below, an update DML will be created. This script can be then be executed to rename all duplicate

certificates.

1. Log on to the WPG application database

db2 connect to user using

2. Run the attached scripts using the commands given below:

a) db2 -td! -vf \FINDDUPUSER.sqlb) db2 -td! -vf \FINDDUPCERT.sql

3. To generate scripts to update duplicate certificates and users, run the commands given below

a) Command to generate the update script to rename duplicate certificates.

db2 -x "SELECT '/* '||certname||' */', '/* '||partner_name||' */', updatestmt from tmp_dup_cert order by partnerid" > \certupdate.sql

b) Command to generate the update script to rename

db2 -x "SELECT '/* '||username||' */', '/* '||partner_name||' */', updatestmt from tmp_dup_user order by partnerid" >

\userupdate.sql

http://www.ibm.com/support/docview.wss?rs=2311&uid=swg27017471http://www.ibm.com/support/docview.wss?rs=2311&uid=swg27017471


8/23


c) The duplicate cert names and user names have been appended with a system generated id.

For eg: If there are 2 certificates with the name "Test Encryption Certificate", one is renamed to Test Encryption Certificate_1 and

the other to Test Encryption Certificate_2

4. Execute the above 2 generated SQL,i.e., certupdate.sql and userupdate.sql to update the database.

Run the following commnds

a) db2 -td! -vf \certupdate.sql

b) db2 -td! -vf \userupdate.sql

c) db2 commit

5. To drop the created temp tables.

a) db2 drop table tmp_dup_user

b) db2 drop table tmp_dup_cert



9/23


Step C: Migration of WPG database from v6.0.0.x to v6.2.0.0 level

The below steps explain the path followed for migrating the WPG database from 6.0.0.x level to 6.2 level.

It is recommended that the backup for database taken, before starting the database migration activity.The Database Schema name and Database User name has to be provided as required in the existing setup for the migration steps. This

document assumes the Schema name as bcgapps and Database User name as bcgdb

1. Stop all WPG servers.

2. Upgrade DB2 level from 8.1 FP14 to 8.1 FP16.

3. Install bcgappsdb using 62 DBLoader providing the db name as bcgapps.Ensure that the option for "Run SQL Files automatically" is unchecked (not selected). Using this option ensures that the required WPG

v62 DBLoader files are copied into the location /scripts/DB2. These files are later used during the manual

migration steps.

4. Run the scripts in sequence as mentioned below. All of these scripts are present in /scripts/DB2 folder.

Note: All the database migration scripts are not cumulative, hence it is required that all of these migration scripts should be executed in the

sequence.Syntax to be used:

db2 td! vf /scripts/DB2/{BCGUpgradeScript} z {BCGUpgradeScript}.log



10/23


11/23


12/23


13/23


Step E: Removal of data for expired certificates and deleted partners.

The below steps explain how to execute the scripts to remove expired certificates and deleted partners from the database.

These scripts can be obtained from the technical note of WPG Application database housekeeping scripts .

It is recommended to take a database backup before the next activity is performed. Once these scripts are executed, the related data on expired

certificates and deleted partners would be removed from WPG application database.

These scripts need to be run on the WPG v6.2 database available on the Windows machine. When deleting the expired certificates the associated

certificate sets may not be deleted because of other complex dependencies.

1. Connect to the WPG application database.

db2 connect to user using

2. Execute the given scripts. Please refer to the instructions.txt file provided along with the script for detailed instructions on execution of eachscript.



14/23


Step F: Apply fixes on WPG v6.2 to resolve Partner Migration issues.

1. Apply WebSphere Partner Gateway v6.2 iFix and APAR JR34216. . This APAR would be available with WPG v6.2 FP2. In cases wherein this

APAR is required for other WPG v6.2 levels, a specific rebuild has to be obtained from IBM support. These activities are performed by using theUPDI for WebSphere Partner Gateway v6.2.

Note:a. You need to setup the UPDI for WebSphere Partner Gateway v6.2. Refer to the technical document for WPG 6.2 Update Installer to

download and extract the UPDI for WebSphere Partner Gateway v6.2.

2. Follow the instructions provided in the WPG 6.2 mandatory iFix download link

(http://www.ibm.com/eserver/support/fixes/fixcentral/swg/quickorder?fixes=6.2.0.0-wbi-wpg-advanced-enterprise-iFix-

JR31639&productid=WebSphere Partner Gateway Advanced Edition&brandid=5 ), and install the WebSphere Partner Gateway v6.2 mandatory

iFix 6.2.0.0-WS-WPG-IFJR31639.pak using UPDI for WebSphere Partner Gateway v6.2

3. Apply APAR JR34216. It has to be applied on Hub installed location of both WPG systems (where the data is being exported and where the

data is being imported.). The fix will update the BCGMigrationUtil.zip , so you need to unzip the new updated utility and use to export/import the

data.

4. Perform a system sanity check by starting the WPG server, logging to the console, then create 2 partners and send a test transaction.

http://www.ibm.com/support/docview.wss?uid=swg27015150http://www.ibm.com/support/docview.wss?uid=swg27015150


15/23


Step G: Installation of WPG V6.2 on target platform.

1. Install WPG V6.2 fresh database and hub on the AIX box.

Pre-requisite DB2 9.5 FP4

_ WASND FP19

2. Apply WebSphere Partner Gateway v6.2 iFix and APAR JR34216. These activities are performed by using the UPDI for WebSphere Partner

Gateway v6.2.

Note:

a. You need to setup the UPDI for WebSphere Partner Gateway v6.2. Refer to the technical document for WPG 6.2 Update Installer to

download and extract the UPDI for WebSphere Partner Gateway v6.2.3. Follow the instructions provided in the WPG 6.2 mandatory iFix download link

(http://www.ibm.com/eserver/support/fixes/fixcentral/swg/quickorder?fixes=6.2.0.0-wbi-wpg-advanced-enterprise-iFix-

JR31639&productid=WebSphere Partner Gateway Advanced Edition&brandid=5 ), and install the WebSphere Partner Gateway v6.2 mandatory

iFix 6.2.0.0-WS-WPG-IFJR31639.pak using UPDI for WebSphere Partner Gateway v6.2

4. Apply APAR JR34216. It has to be applied on Hub installed location of both WPG systems (where the data is being exported and where the

data is being imported.). The fix will update the BCGMigrationUtil.zip file, so you need to unzip the new updated utility and use to export/import the

data.

5. The next step would be to import data using the Partner migration utility. It is recommended to backup the database before the next activity is

performed.

http://www.ibm.com/support/docview.wss?uid=swg27015150http://www.ibm.com/support/docview.wss?uid=swg27015150


16/23


Step H: Export/import data using Partner Migration on target machine

The below steps explain in detail how the Partner Migration Utility is to be used to export data from staging machine and then import the data to

the target machine. .

1. When doing a Partner migration import we saw that partner migration fails in case there are any non-ASCII characters in the Migration xml .XML parsing fails when reading this xml document, it is not able to handle these non-ASCII characters.

The certificates that might have these non-ASCII characters would need to be deleted before we do a Partner migration export from the WPG V6.2

staging system.

2. Ensure that the WPG server is up and running before attempting Partner Migration. Unzip the Partner Migration utility which is available at

location /console/support/ BCGMigrationUtil.zip

3. Unzip the export.zip available at location /\console\support\BCGMigrationUtil\bcgmigrate\samples\export.

4. Edit the export.xml which will be available in the location where export.zip was unzipped. Here set the AllSystemAdminProps property will be

available and set to true. Set it to false now. After setting this to false we will not be exporting the System Administration Property data from the

Windows WPG V6.2, that would include the CFS locations available under System Administration. So the AIX CFS locations will not get

overwritten with Windows values.

false

DocMgr_EventEngine_ExternalEvents



17/23


5. Use Partner Migration utility now to export all the data from the Windows WPG V6.2 hub.

/bcgmigrate/bin/bcgmigrate.bat -h : -a export f

\export.xml -u hubadmin p -d 5

Eg: C:\BCGMigrationUtil\bcgmigrate\bin\bcgmigrate -h 9.122.165.215:58809 -a export -f

C:\BCGMigrationUtil\bcgmigrate\samples\export\export.xml -u hubadmin -p admin123 -d 5

The export should happen successfully without any errors.

6. Next step is to extract the import.xml from the BCGMigrate_localhost.zip file, and edit it to replace Receiver and Destination values.

Ex. Replace E:\\//netapp03/bcg/common/subdir with /bcg/common/subdir.

Then the updated BCGMigrate_localhost.xml file should be updated back to the BCGMigrate_localhost.zip, from where it was extracted.Download the sample utility Script to change the Receiver and Destination URLs in partner migration exported content . This downloaded script filewould require to be modified so as to customize the URL references as per those used in the current WPG setup.

Do as follows:

a) Use FileZilla to FTP (or perform FTP through telnet session) the BCGMigration_localhost.zip file to the AIX server.

b) Then use either a telnet or putty session to copy the file from the copied location directory to the /console/support/bcgmigrate/bin - make sure you FTP as bcguser id.

c) Copy the downloaded and customized import filter script to the AIX box. Edit this Import filter script. This script has parameter called

importFile. Please make sure the importFile has the same value as the Partner Migration exported zip. For eg. If the name of your exported file is

BCGMigration_localhost.zip, please make sure the value of this property is set to BCGMIgration_localhost.zip in the xml.



18/23


d) Make sure that both the filter_import.sh and the BCGMigration_localhost.zip have read/write/execute permissions and also user and owner for

these files are bcguser:bcggroup.Following are the commands to change the permissions chown bcguser:bcggroup filter_import.sh chmod 755 filter_import.sh chown bcguser:bcggroup BCGMigration_localhost.zip chmod 777 BCGMigration_localhost.zip

e) Next, run import filter script (from current directory) to edit the XML and replaces the necessary environment-specific values as follows(ensure that the user login is still as bcguser)

$ ./filter_import.sh (./ preceding command indicates executable is in current directory)

The filter_import file converts specific 6.0 values to 6.2 values.

The script will display messages that BCGMigration_localhost.xml has been updated and written back to BCGMigration_localhost.zip file. It leavesthe updated BCGMigration_localhost.xml file and the original BCGMigrate_localhost.xml.tmp file in the same bin directory (outside of the zip file)

for reference.

7. When doing a Partner Migration import certificate upload may fail with the following error: [9/30/09 7:33:11:093 UTC] 0000002e SystemErr

R com.ibm.websphere.ce.cm.StaleConnectionException: [ibm][db2][jcc][t4][2050][11326] Execution failed due to a distribution protocol error that

caused deallocation of the conversation.

The identified cursor is not open.

[9/30/09 7:33:11:094 UTC] 0000002e SystemErr R at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

This error is seen because the latest DB2 JDBC driver is not present in WPG. To fix the above stated issue we would need to replace the

db2jcc.jar in all location where WPG uses it.



19/23


a) Stop the servers, node agent and dmgr in that order.

b) Copy the db2jcc.jar from /opt/IBM/db2/V9.5/java to the following locations:i) /lib

ii) /lib

iii) /MAS/lib

iv) /ftpserver/common/lib

v) /wasND/Profiles/bcgprofile/installedApps/wpgCell/BCGReceiver.ear/libvi) /wasND/Profiles/bcgprofile/installedApps/wpgCell/BCGConsole.ear/lib/support

vii) /wasND/Profiles/bcgprofile/installedApps/wpgCell/BCGConsole.ear/lib

ix) /wasND/Profiles/bcgprofile/installedApps/wpgCell/BCGBPE.ear/lib

x) /wasND/Profiles/bcgprofile/installedApps/wpgCell/BCGDocMgr.ear/lib

c) Make sure that the db2jcc.jar that has been placed in all these locations has bcguser:bcggroup permission

i) To change the permissions for any other user to bcguser-bcggroup. Login a sroot and execute the following command:chown bcguser:bcggroup db2jcc.jar

ii) To give it read-write and execute permission, run the following command:

chmod 755 db2jcc.jar

d) Start the dmgr, node agent and the servers in that order.

8) It is recommended that the backup for database taken before the next activity is performed. If this backup was taken at the end of Step G, that

backup is sufficient. Import the data which was exported from the WPG V6.2 Windows hub using the Partner Migration utility. The command to

unzip the utility is: unzip BCgMigrationutility.zip

The Partner migration utility is located at /console/support.

Please remember to use the Exported zip that was updated as part of step 6. This zip will have the Windows notation replaced to Unix.

Before running the Partner migration import utility please do the following:



20/23


21/23


Known Issues

1. The following error may be seen in the bcgmigration.log after Partner Migration import has been completed.

[Fri Oct 23 14:03:29 EDT 2009] BCGImportUtil:updateGroupPermission::ERROR:::Permission with the name XYZ receiver-module does not exist

in the system. There could be many instances on these kinds of errors.This error simply means that if the permissions for that screen are disabled on the WPG 6.2 console, for each partner available this error would be

thrown. This is as per design, since the permission has been disabled in the 6.2 Console we are not over-writing and enabling it. Any permission

change would need to be set manually.

2. The following error may be seen in the bcgmigration.log after Partner Migration import has been completed.

[Fri Oct 23 14:18:44 EDT 2009] BCGImportUtil:processUserList::ERROR:::User configuration not updated.Error Messge:null

The FTP user information was not updated since the FTP management server was down.

3. The following error may be seen in the bcgmigration.log after Partner Migration import has been completed.[Fri Oct 23 16:00:37 EDT 2009] BCGImportUtil:processEventAlertList::ERROR:::Contact not found on the target system :

These errors are thrown because the Contact info is not available. This is an issue because of the migration from WPG 6.0 to 6.2 In WPG 6.0 we

could have the same user as a contact, however in WPG 6.2 we a user cannot be also added as a contact.

Now we explicitly need to add the Contact as a Subscribed contact.

The alerts for which the contacts have not been updated are:

a) Document Too Large to Process



22/23


b) Encryption Failure

c) Unpackaging Errord) Cardinal Delivery Retry Failed

e) Cardinal First Delivery Attempt Failed

f) Cardinal MDN with Disposition Error

g) Cardinal Document Delivery Failed

h) Cardinal MDN Not Received

i) System Error in the Inbound Processork) Could Not Unpackage AS2 Header



23/23



References

WPG v6.2 Update Installer WPG Application database housekeeping scripts Utility Script to change URLs in partner migration exported content.

Corrected Database script for BCGUpgrade_600FP4_600FP5
http://www.ibm.com/support/docview.wss?uid=swg27015150http://www.ibm.com/support/docview.wss?uid=swg27015150http://www.ibm.com/support/docview.wss?rs=2311&uid=swg27017471http://www.ibm.com/support/docview.wss?rs=2311&uid=swg27017471http://www.ibm.com/support/docview.wss?rs=2311&uid=swg27017446http://www.ibm.com/support/docview.wss?rs=2311&uid=swg27017446http://www.ibm.com/support/docview.wss?rs=2311&uid=swg21411429http://www.ibm.com/support/docview.wss?rs=2311&uid=swg21411429http://www.ibm.com/support/docview.wss?rs=2311&uid=swg27017446http://www.ibm.com/support/docview.wss?rs=2311&uid=swg27017471http://www.ibm.com/support/docview.wss?uid=swg27015150http://www.ibm.com/support/docview.wss?uid=swg27015150

Documents

WebSphere Partner Gateway v6.2 - Cross Platform MigrationWPG