WebSphere Partner Gateway v6.2 - Cross Platform MigrationWPG

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

WebSphere Partner Gateway v6.2 Cross platform migration

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


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


entries are still available in the database. These partners and the artifacts around these partners will be deleted from the database using these
scripts.

Step F: After executing the housekeeping DB scripts on the WPG 6.2 staging machine, apply the mandatory WPG v6.2 ifix APAR of JR31639
using UPDI. Also, the partner migration tool does not export / import alert configurations. So as to rectify this error, apply JR34216 APAR fix using
UPDI.

Step G: Install a fresh WPG on the target machine. After installation is complete apply the mandatory WPG v6.2 ifix APAR of JR31639 using
UPDI. Then apply the JR34216 APAR fix using UPDI.

Step H: Using Partner Migration Utility, export data from the WPG 6.2 (staging environment on Windows). On the exported data in the partner
migration xml file, it is required to filter out the URL path references so as to match the AIX specific file notations. So as to achieve the changes in
platform specific path separators, the xml configuration file needs to be run through the filter_import script. This step provides the details on
accessing the filter_import script. Once the configuration data is changed in the xml file, the same is ready to be imported using Partner Migration
Utility on WPG v6.2(AIX)


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.

.



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 table
has 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 =<fully qualified path for non_rep> where mediaid=1
ii. update LG_MEDIA set URL =<fully qualified path for msg_store> where mediaid=2



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 technical
note 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 <WPG application database> user <db2admin user> using <db2admin password>

2. Run the attached scripts using the commands given below:
a) db2 -td! -vf <PATH>\FINDDUPUSER.sql
b) db2 -td! -vf <PATH>\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" > <PATH>\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" >
<PATH>\userupdate.sql


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 <PATH>\certupdate.sql
b) db2 -td! -vf <PATH>\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



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 <bcgappsdb_home>/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 <62bcgappsdb_home>/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 <bcgappsdb_home>/scripts/DB2/{BCGUpgradeScript} z {BCGUpgradeScript}.log



Where {BCGUpgradeScript} corresponds to the name of the migration scripts as provided below and the output is redirected to the
{BCGUpgradeScript}.log file. It is required to start executing the scripts from the current fixpack level. For e.g. assuming the current
fixpack level is FP3 the following scripts need to be executed.

Run BCGUpgrade_600FP3_600FP4.sql to migrate the database to 6.0.0.4.
Download the corrected BCGUpgrade_600FP4_600FP5.sql script. Edit the downloaded script file before
using it, so as to replace the variable $group_name$ with the WPG used group name. Typically the
group name would be bcggroup.
Run BCGUpgrade_600FP5_610.sql to migrate the database to 6.1.
Run BCGUpgrade_610_610FP1.sql to migrate the database to 6.1.0.1.
Run BCGUpgrade_610FP2_611.sql to migrate the database to 6.1.1.
Run BCG_Upgrade611_611FP1.sql to migrate the database to 6.1.1.1.
Run Archiver_UDF.sql to install the Archiver UDF functionality.
Run BCG_Upgrade611FP1_62.sql to migrate the database to 6.2.

5. Check the logs for errors. The following errors are known errors
a) SQLSTATE=23505

All errors with this SQLState can be ignored. This simply means that the data that is being inserted is already available. It could be
available because of some fix already provided to FoodLion.
b) DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor command.
During SQL processing it returned:SQL0085N The statement name "V_STMT" is already defined. LINE NUMBER=133



This error can be ignored too. This error is seen because all versions prior to WPG v6.2 are not supported on DB2 9.5. This above
given error will be available in all log files till the 611FP1_62 log file. Since Db2 9.5 is supported on WPG 6.2 , this error will not be
seen on this version.
c) update BP_STATE_HDR set corbusid = (select corbusid from lg_as_busid where businessid = initbusinessid) DB21034E The
command was processed as an SQL statement because it was not a valid Command Line Processor command. During SQL
processing it returned:SQL0407N Assignment of a NULL value to a NOT NULL column "TBSPACEID=3, TABLEID=15,
COLNO=39" is not allowed. SQLSTATE=23502
d) CREATE UNIQUE INDEX UK_PROTOCOLDEF_3 ON cf_protocoldef(srcdocver, srcdoctype, protocoldeffamilyid) allow
REVERSE scans DB21034E The command was processed as an SQL statement because it was not a valid Command Line
Processor command. During SQL processing it returned:SQL0603N A unique index cannot be created because the table
contains rows which are duplicates with respect to the values of the identified columns.
e) CREATE UNIQUE INDEX UK_STATE_HDR_1 ON BP_STATE_HDR(CORBUSID,PROCESSINSTANCEID) ALLOW REVERSE
SCANS DB21034E The command was processed as an SQL statement because it was not a valid Command Line Processor
command. During SQL processing it returned:SQL0603N A unique index cannot be created because the table contains rows
which are duplicates with respect to the values of the identified columns. SQLSTATE=23515

These errors are seen due to database migration steps and the above artifacts may be already created in the database. However
in case of a fresh installation on the target system, these errors will not be seen.



Step D: Install WPG v6.2.0.0 level

1. Install the WebSphere Application Server Network Deployment (WASND) v6.1 GA and apply the WASND fix pack 19.
2. New users namely bcgdb and bcguser may need to be created. This should be a part of the bcggroup.
3. Install WPG 6.2 hub and point it to the upgraded BCGAPPS database



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 <WPG application database> user <db2admin user> using <db2admin password>

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



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



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.


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 <Hub installed location>/console/support/ BCGMigrationUtil.zip

3. Unzip the export.zip available at location <Hub installed 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.
<SystemAdminList>
<AllSystemAdminProps>false</AllSystemAdminProps>
<SystemAdminGroup>
<GroupName>DocMgr_EventEngine_ExternalEvents</GroupName>


</SystemAdminGroup>
</SystemAdminList>

5. Use Partner Migration utility now to export all the data from the Windows WPG V6.2 hub.
<Location where BCGMigration was unzipped as part of Step 2>/bcgmigrate/bin/bcgmigrate.bat -h <IP>:<Bootstrap port> -a export f
<Location where export.zip was unzipped in step 3> \export.xml -u hubadmin p <password> -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 file
would 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 <BCGHUB
location>/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.



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 leaves
the 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.


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) <Dmgr installed location>/lib

ii) <Hub installed location>/lib
iii) <Hub installed location>/MAS/lib
iv) <Hub installed location>/ftpserver/common/lib
v) <Hub installed location>/wasND/Profiles/bcgprofile/installedApps/wpgCell/BCGReceiver.ear/lib
vi) <Hub installed location>/wasND/Profiles/bcgprofile/installedApps/wpgCell/BCGConsole.ear/lib/support
vii) <Hub installed location>/wasND/Profiles/bcgprofile/installedApps/wpgCell/BCGConsole.ear/lib
ix) <Hub installed location>/wasND/Profiles/bcgprofile/installedApps/wpgCell/BCGBPE.ear/lib
x) <Hub installed location>/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 <Hub installed location>/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:


1) In the command window where you run the import command run the following command
export JAVA_HOME=/usr/WebSphere/AppServer/java
2) In the command window where you run the import command: java -version (make sure the JDK is for java 1.5). This needs to be done because
Partner migration will not run unless the Java version is 1.5
3) The variable MIGRATION_PATH needs to be set to the location where the Migration Utility has been unzipped. Say it has been unzipped under
/was/console/support then to set MIGRATION_PATH the following command would need to be run:
MIGRATION_PATH =/was/console/support/bcgmigrate
4) Instance of OOM Exceptions may occur when running the Partner Migration import utility, to fix this error the heap size needs to be set in the
partner migration utility. Edit the bcgmigrate.sh file available under /was/console/support/bcgmigrate/bin.
At the end of the file the following command is present:
$JAVA_HOME/bin/java com.ibm.bcg.sdk.migration.BCGMigrationUtil $1 $2 $3 $4 $5 $6 $7 $8 $9 ${10} ${11} ${12} ${13} ${14} ${15}
This needs to be edited and now set to
$JAVA_HOME/bin/java -Xms256m -Xmx1024m com.ibm.bcg.sdk.migration.BCGMigrationUtil $1 $2 $3 $4 $5 $6 $7 $8 $9 ${10} ${11} ${12} ${13}
${14} ${15}
In the above command we have set the initialheapSize to 256 MB and the maximumHeapSize to 1GB
5) Switch user to "bcguser", then change directory to /was/console/support/bcgmigrate/bin to run the ./bcgmigrate.sh import
Use the following command to import data using the partner migration utility:
<BCGMigration utility location>/bcgmigrate/bin -h <IP>:<BootStrap port> -a import -f <Location of exported file>/BCGMigration_localhost.zip -u
hubadmin -p <passwd> -o -d 5

Eg: bcgmigrate.sh -h 9.184.236.137:58809 -a import -f <Location of exported file>BCGMigration_localhost.zip -u hubadmin -p hub8admin -o -d 5



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.

[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.

[Fri Oct 23 16:00:37 EDT 2009] BCGImportUtil:processEventAlertList::ERROR:::Contact not found on the target system : <ContactInfo>
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


b) Encryption Failure
c) Unpackaging Error
d) 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 Processor
k) Could Not Unpackage AS2 Header



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

WebSphere Partner Gateway v6.2 - Cross Platform MigrationWPG

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

WebSphere Partner Gateway v6.2 - Cross Platform MigrationWPG

Încărcat de

Drepturi de autor:

Formate disponibile

WebSphere Partner Gateway v6.

2 Cross platform migration

S-ar putea să vă placă și