1 客户环境    4

2 升级步骤    4

3 准备工作    5

3.1 WPS5机器    5

3.1.1 验证数据库连接是否正确    5

3.1.2 准备迁移工具的 Fix  5

3.2 WPS6机器    6

3.2.1 安装 Portal6.0.1.3+WCM   6

3.2.2 迁移数据库 +启用安全性    6

3.2.3 获取相关管理员账号    7

3.2.4 修改 HTTP Server 的超时时间    7

3.2.5 收集 WPS5必要的文件，便于从 WPS6访问 WPS5  7

3.2.6 确认所有已经发布的 Portlet在 WPS5 的 PortalServer/installableApps当中有 WAR包    8

3.2.7 重新创建虚拟门户    9

3.2.8 调整迁移的性能    9

4 迁移客户化资源    10

5 迁移门户配置    11

5.1 在 WPS6使用命令行方式迁移    11

5.2 从 WPS5导出门户数据    11

5.3 从 WPS5导出虚拟门户数据    12

5.4 导入门户数据到 WPS6  12

5.5 导入虚拟门户数据    13

5.6 迁移 FileServlet Portlet(可选 ) 13

5.7 重起 WPS6  13

6 迁移权限相关数据    14

7 迁移 WCM数据    16

7.1 安装迁移工具 (Web content migration tool) 16

7.2 清理 WPS5的 WCM的错误数据    17

7.2.1 Reference checker 17

7.2.2 Site checker 17

7.2.3 Resource checker 17

7.2.4 Member fixer 17

7.2.5 确定没有加密的 Excel,WORD， PPT等文件    18

7.3 WCM内容迁移    18

7.4 迁移 user profiles 22

7.5 迁移 local rendering portlet 23

7.6 迁移 remote rendering portlet 24

7.7 WCM迁移成功后修改工作    25

7.7.1 Web content configuration files 25

7.7.2 Anchor tags and URLs 26

7.7.3 Links to Web Content Management content from external sites 26

7.7.4 Siblings with the same name 27

7.7.5 Draft items 27

7.7.6 Navigator elements 27

7.7.7 Menu elements 28

7.7.8 Name and title fields 28

7.7.9 Connect tags 28

7.7.10 Web Content Management search  28

7.7.11 Moving objects to new libraries 28

7.7.12 API code 29

7.7.13 JSP files 29

7.7.14 Authoring portlet access changes 29

7.7.15 Referential integrity  29

7.7.16 Authoring portlet pages 29

7.7.17 Presentation templates 30

7.7.18 Removing the migration tool 30

8 迁移后验证任务    30

8.1 Verify Notes and Domino Web Access (iNotes) portlets migration  30

8.2 Verify migration of portal clients 31

8.3 Verify migration of user customizations 31

8.4 Verify migration of credential vault segments and slots 31

8.5 Verify migration of themes and skins 32

8.6 Verify migration of portlet applications 32

8.7 Verify migration of portlet configuration data 32

8.8 Verify migration of virtual resources 33

8.9 Verify migration of pages 33

 

1      客户环境

源环境： WPS5

平台： windows

门户： WebSphere Portal Server enable 5.1.0.2+WCM (WCM 发布的服务器，最好是从发布服务器迁移 )

数据库： Oracle 9i

 

 

 

 

 

 

目标环境： WPS6

平台： windows

门户： WebSphere Portal Server Enable 6.0.1.3 +WCM+WAS6.0.2.23

数据库： Oracle 9i

 

 

WPS1  10.195.88.221   10.195.88.201

WPS2  10.195.88.220

LDAP  10.195.88.221

 

 

 

补丁：

6.0.1-WP-FP003

6.0.1.3-WP-Multi-IFPK59655

6.0.1.3-WP-Multi-IFPK61633

 

6.0.2-WS-WAS-WinX32-FP00000023

6.0.2-WS-WASJavaSDK-WinX32-FP00000023

 

2      升级步骤

任务	列表	天数
环境准备	WPS5 准备（客户提供）	1
	WPS6 准备（现场安装） + 启用安全性 + 数据库迁移 +Fixpack
	迁移前门户系统配置修改
	WCM 数据清理
迁移门户数据	迁移客户化资源 ( 主题、皮肤等 )	1
	迁移门户配置
	迁移权限数据
迁移 WCM	WCM 内容迁移	1.5
	User Profile 迁移
	Local Rendering Portlet 迁移
	Remote Rendering Portlet 迁移
验证迁移	验证迁移的数据	0.5

 

 

3      准备工作

 

3.1    WPS5 机器

3.1.1  验证数据库连接是否正确

查看 wpconfig.properties 配置是否正确，测试是否正常连接数据库。

PortalServer/Config 目录下执行命令 :

WPSConfig.bat validate-database-connection-wps

 

 

3.1.2  准备迁移工具的 Fix

 

a.     Create an update directory in your previous WebSphere Portal directory; for example, C:\Program Files\WebSphere\PortalServer\update .

b.     Download the WebSphere Portal Update Installer from http://www.ibm.com/software/genservers/portal/support/ and then unpack the Installer to the update directory you created in the previous step.

c.     Unzip the interim fixes from the appropriate directory of the current WebSphere Portal directory to the update directory created in the previous step:

§       portal_server_root /migration/fixes/5102

Note: All interim fixes are already built in for version 5.1.0.4; therefore, there are no interim fixes to apply.

 

For version 5.1.0.2:

§       PK14100

§       PK14103

§       PK15013

§       PK19790

§       PK20467

§       PK16371

§       PK16597

§       PK18538

§       PK21688

§       PK17690

§       PK21136

§       PK22244

§       PK23901

§       PK11536

§       PK40171 – Apply this fix using the WebSphere Portal database check and update tool wpdbupdate

 

d.     Enter the following command on the command line to set the WAS_HOME environment variable for the previous version directory where you will run the WebSphere Portal Update Installer:

Windows: set WAS_HOME=was_old_root

For example: set WAS_HOME=C:\Program Files\WebSphere\AppServer\setupCmdLine.bat

e.     Enter the following command on the command line to install one or more interim fixes:

Windows: .\updatePortal.bat -install -installDir wp_old_root -fix -fixDir wp_old_root/update -fixes list of fixes

For example : updatePortal.bat -install -installDir "C:\Program Files\WebSphere\PortalServer" -fix -fixDir "C:\Program Files\WebSphere\PortalServer\update" -fixes PK07258 PK07872

 

 

 

3.2    WPS6 机器

3.2.1  安装 Portal6.0.1.3+WCM

要备份。包括目录备份 + 数据库备份。

 

3.2.2  迁移数据库 + 启用安全性

LDAP 目录最好是同一个或者数据是一样， LDAP 版本也一致，或者数据应该一致，否则 WCM 数据当中做用户检测部分可能存在问题。

 

 

3.2.3  获取相关管理员账号

WPS5 的管理员账号和密码： WAS 和 PORTAL

WPS6 的管理员账号和密码： WAS 和 PORTAL

 

3.2.4  修改 HTTP Server 的超时时间

Because migration can be a lengthy process, we suggest that you change the timeout length of your HTTP server to unlimited timeout while performing the migration task. Refer to your HTTP server documentation for information on how to change the timeout value.

 

 

3.2.5  收集 WPS5 必要的文件，便于从 WPS6 访问 WPS5

Run the migrate property collector task to collect required files from the previous version to allow the migration scripts to access the previous version:

Important: You will need to stop the previous version of your Portal server if any of the following statements are true for your environment:

o      If you are using a Cloudscape database

o      If there is a port conflict or resource conflict when you start the current portal server

o      If you modified the number of groups

d.     Copy the propcollector.xml and propcollector.jar files from the portal_server_root /migration directory of the current version to the wp_old_root/config/includes directory of the previous version and run the following command from the wp_old_root/config directory of the previous version:

Note: If using i5/OS, the directory path is portal_server_root_user for the current version of WebSphere Portal and wp_user_old_root for the previous version of WebSphere Portal.

§       Windows and UNIX: WPSconfig.{sh|bat} prop-collector -DDbPassword=wpsdb_password

§       i5/OS: Choose one of the following commands based on the version of WebSphere Application Server that you are using:

§       WebSphere Application Server 5.x: WPSconfig.sh -instance instance_name prop-collector -DDbPassword=wpsdb_password

where instance_name is the name of the WebSphere Application Server profile where WebSphere Portal is installed.

§       WebSphere Application Server 6.x: WPSconfig.sh -profileName profile_root prop-collector -DDbPassword=wpsdb_password

where profile_root is the name of the WebSphere Application Server profile where WebSphere Portal is installed; for example, wp_profile.

§       Important: The following information applies to running the above command:

§       -DDbPassword=wpsdb_password is not required if the value is already defined in the wpconfig.properties file.

§       Ensure that the values for DbUrl and DbName are defined in the wpconfig.properties file.

§       Ensure that the value for WpsHostName in the wpconfig.properties file is the fully-qualified host name of the Web server that WebSphere Application Server is configured to use and is NOT "localhost".

e.     Copy the wp_old_root/config/includes/propcollectorOutput.zip file from the previous version to the portal_server_root /migration directory on the current version.

f.      Run the following command from the portal_server_root /migration directory of the current version to extract the propcollectorOutput.zip file:

WPmigrate.{sh|bat} collector-extract

 

 

3.2.6  确认所有已经发布的 Portlet 在 WPS5
的 PortalServer/installableApps 当中有 WAR 包

 

Make portlet applications available to migration tasks for deployment

The portal_server_root /installedApps directory contains a list of all portlet applications that are deployed on your previous WebSphere Portal system. Depending on the features that are used by these portlets, they might have to first be upgraded to work with the current version of WebSphere Portal. Refer to the instructions that are provided in the Migrating your customized resources section to determine if you need to upgrade your portlets.

Some of the WAR files in the portal_server_root /installedApps directory might have been shipped with the current version of WebSphere Portal. In that case, there is no need to manually upgrade corresponding portlets. You can safely use the corresponding WAR file from the portal_server_root /installableApps directory as an upgraded version of the portlet.

Before running migration tasks, all the upgraded portlets must be made available in the portal_server_root /installableApps directory of your current WebSphere Portal system. This directory has the sample portlets that ship with the current version of WebSphere Portal; do not overwrite these with the sample versions that shipped with earlier versions of WebSphere Portal.

3.2.7  重新创建虚拟门户

Create the virtual portal from your previous version in the current version: In order to migrate the data from your previous virtual portal into the current version, you must recreate the virtual portal in the current version. Use the Virtual Portal Manager to create the virtual portal in the current version.

 

 

3.2.8  调整迁移的性能

Required performance tuning for exporting and importing large groups and resources

a.     Check your LDAP server to determine the number of groups and perform the appropriate steps if the number is greater than 200:

§       Perform the following steps on the previous version of WebSphere Portal if migrating from version 5.1.x:

                                                             i.         Change to the wp_old_root/wmm directory of the 5.1.x directory.

                                                            ii.         Open the wmm.xml file and the maximumSearchResults attribute. You must change the numerical value of maximumSearchResults to a number greater than the actual number of groups on the LDAP server; for example if the LDAP server has 300 groups, then enter 301.

                                                           iii.         Save your changes.

                                                          iv.         If this is a clustered environment, change to the was_old_root/config/wmm directory of the 5.1.x system.

                                                           v.         Open the wmm.xml file and the maximumSearchResults attribute. You must change the numerical value of maximumSearchResults to a number greater than the actual number of groups on the LDAP server; for example if the LDAP server has 300 groups, then enter 301.

                                                          vi.         Save your changes.

                                                         vii.         If this is a clustered environment, change to the dmgr_old_root/config/wmm directory on the deployment manager machine of the 5.1.x system.

                                                        viii.         Open the wmm.xml file and the maximumSearchResults attribute. You must change the numerical value of maximumSearchResults to a number greater than the actual number of groups on the LDAP server; for example if the LDAP server has 300 groups, then enter 301.

                                                          ix.         Save your changes.

§       Perform the following steps on the current version of WebSphere Portal after completing any security-related tasks, such as, but not limited to, running the enable-security-ldap task:

                                                             i.         Change to the portal_server_root /wmm directory of the current version.

                                                            ii.         Open the wmm.xml file and the maximumSearchResults attribute. You must change the numerical value of maximumSearchResults to a number greater than the actual number of groups on the LDAP server; for example if the LDAP server has 300 groups, then enter 301.

                                                           iii.         Save your changes.

b.     Change the LDAP server search parameters based on your server's documentation to an unlimited value or a value large enough to handle the exporting and importing of large groups and resources; for example:

§       Search size limit: Unlimited

§       Search time limit: Unlimited

§       Idle time out for paged searches: 172800

Note: This value should be 48 hours or more; no unlimited option is documented (value is in seconds).

 

 

 

4      迁移客户化资源

主题和皮肤：

WPS5的皮肤和主题和WPS6有些不一样，在WPS6的基础上新建一个主题，把相关的资源替换（css or Images）。

其他：

如果客户部署了协作的Portlet、Structs Framework的portlet、业务流程的Portlet或者Portal搜索数据，请参考Inforcenter的章节:

l   Migrating cooperative portlets that use IBM Portlet API

l   Migrating portlets built with Struts Portlet Framework

l   Migrating business process applications

l   Migrating Portal Search between portal versions

 

5      迁移门户配置

5.1    在 WPS6 使用命令行方式迁移

命令在 portal_server_root /migration 目录

• Windows: WPmigrate.bat

5.2    从 WPS5 导出门户数据

The export-portal-content task exports the WebSphere Portal content from the previous version.

Important: Before running the export-portal-content task, perform the following steps:

1.     Stop the current WebSphere Portal server. ( 停止 WPS6)

2.     Start the server for your previous version of WebSphere Portal and ensure it is accessible to the network. ( 启动 WPS5)

The syntax for invoking a migration task is as follows:

• Windows: WPmigrate.bat export-portal-content -DPrevPortalAdminId=portaladminid -DPrevPortalAdminPwd=password

• PrevPortalAdminId indicates a portaladminid from the previous version of WebSphere Portal
• PrevPortalAdminPwd indicates the password for the above portaladminid

  

5.3    从 WPS5 导出虚拟门户数据

如果没有虚拟门户，跳过这一步。

The export-portal-content task exports the WebSphere Portal content from the previous version. 但是在 WPS6 的 portal_server_root /migration 目录运行。

Important: Before running the export-portal-content task, perform the following steps:

1.     Stop the current WebSphere Portal server ( 停止 WPS6).

2.     Ensure the server for your previous version of WebSphere Portal is running and accessible to the network. （启动 WPS5 ）

The syntax for invoking a migration task is as follows:

• Windows: WPmigrate.bat export-portal-content -DPrevPortalAdminId=portaladminid -DPrevPortalAdminPwd=password -DVirtualPortal=URL context

where:

• PrevPortalAdminId indicates a portaladminid from the previous version of WebSphere Portal
• PrevPortalAdminPwd indicates the password for the above portaladminid
• URL context is the context extension for the virtual portal URL; see the URL Context description row in the Virtual Portal Manager portlet

 

5.4    导入门户数据到 WPS6

The import-portal-content task imports the content from the previous version of WebSphere Portal into the current version of WebSphere Portal.

在 WPS6 的 portal_server_root /migration 目录运行。

Important: Before running the import-portal-content task, perform the following steps:

1.     Stop the previous WebSphere Portal server. ( 停止 WPS5)

2.     Start the server for your current version of WebSphere Portal and ensure it is accessible to the network. ( 启动 WPS6)

3.     Specify the WasUserid and WasPassword in the wpconfig.properties file; see Configuration properties reference for information about editing the properties file.

The syntax for invoking the migration task is as follows:

• Windows: WPmigrate.bat import-portal-content -DPortalAdminId= portaladminid -DPortalAdminPwd= password

where:

• PortalAdminId indicates a portaladminid from the current version of WebSphere Portal
• PortalAdminPwd indicates the password from the above portaladminid

Note : If running the import-portal-content task multiple times, you must Restart the servers before rerunning the task.

 

5.5    导入虚拟门户数据

如果没有虚拟门户，跳过这一步。

The import-portal-content task imports the content from the previous version of WebSphere Portal into the current version of WebSphere Portal.

Important: Before running the import-portal-content task, perform the following steps:

1.     Stop the previous WebSphere Portal server. ( 停止 WPS5)

2.     Ensure the server for your current version of WebSphere Portal is running and accessible to the network. ( 启动 WPS6)

Tip: Before importing each Virtual Portal, backup your database.

The syntax for invoking the migration task is as follows:

• Windows: WPmigrate.bat import-portal-content -DPortalAdminId= portaladminid -DPortalAdminPwd= password -DVirtualPortal= URL context

where:

• PortalAdminId indicates a portaladminid from the current version of WebSphere Portal
• PortalAdminPwd indicates the password from the above portaladminid
• URL context is the context extension for the virtual portal URL; see the URL Context description row in the Virtual Portal Manager portlet

Note: If running the import-portal-content task multiple times, you must Restart the servers before rerunning the task.

5.6    迁移 FileServlet Portlet( 可选 )

If you cloned the FileServer portlet in previous versions and supplied HTML files in the wp_old_root/installedApps/FileServer.war/FileServerPortlet/html directory, you must copy those files to the portal_server_root /installedApps/FileServer.war/FileServerPortlet/html directory, after running the import task and before restarting the server, to make the files accessible in the current version.

 

5.7    重起 WPS6

After completing the import-portal-content task, restart the following server on the current version only:

1.     Open a command prompt and change to the following directory:

o      Windows: was_profile_root \bin

2.     Enter the following command:

o      Windows : stopServer.bat WebSphere_Portal -user admin_userid -password admin_password

3.     Enter the following command:

o      Windows: startServer.bat WebSphere_Portal

6      迁移权限相关数据

虽然前面成功的迁移了门户配置数据，但是有些权限配置相关数据，是没有迁移的，例如：凭证保险库相关数据，资源许可权的数据等等。

 

 

1.     Migrating permissions on All Authenticated Portal Users and All Portal User Groups group

Permissions on User Groups allows principals to perform the following tasks:

o      Edit group information

o      Change group membership

o      Change the access rights of the group members

Follow this step to migrate permissions on user groups:

On the current WebSphere Portal system, use the User and Group Permissions portlet, the Resource Permissions portlet, or the XML configuration interface to assign the principals to roles on the appropriate user groups. For more information, refer to the portlet helps or The XML configuration interface . Follow these steps to assign the principals to roles on the appropriate user groups using the Resource Permissions portlet:

                                           i.         Log in to portal using an administrator account.

                                          ii.         Open the Resource permissions portlet.

                                         iii.         Select the Resource type User Groups.

                                        iv.         Select the All Authenticated Portal Users option and analyze the existing role assignments on that user group.

                                         v.         Use the Resource permissions portlet to create the same role assignments on the new portal.

                                        vi.         Repeat these steps for All Portal User Groups .

2.     Migrating permissions on WebSphere Portal 5.1.x administrative resources

Log onto your previous version of WebSphere Portal and go to the Manage pages portlet. View and make note of the access control settings for your previous version. Then log into your current version of WebSphere Portal and go to the Manage pages portlet. Recreate the access control from your previous version in your current version.

5.1.x Administrative Page	5.1.x Administration Portlet title
Portal User Interface o                        Manage Pages o                        Themes and Skins	Manage Pages Themes and Skins
Portlet Management o                        Web Modules o                        Applications o                        Portlets o                        Web Services o                        Web Clipping	Manage Web Modules Manage Applications Manage Portlets Web Service Configuration Web Clipping Editor
Access o                        Users and Groups o                        Resource Permissions o                        User and Group Permissions o                        Credential Vault	Manage Users and Groups Resource Permissions User and Group Permissions Credential Vault
Portal Settings o                        Global Settings o                        URL Mapping o                        Custom Unique Names o                        Supported Markups o                        Supported Clients o                        Search Administration o                        Import XML	Global Settings URL Mapping portlet Manage Custom Unique Names Manage Markups Manage Clients Manage Search Collection Import XML
Portal Analysis o                        Frequent Users o                        Enable Tracing	Frequent Users Enable Tracing
Portal Content o                        Manage Document Libraries	Manage Document Libraries
Virtual Portals o                        Manage Virtual Portals	Virtual Portal Manager
Page Customizer o                        Content Layout o                        Appearance o                        Locks o                        Wires	Edit Layout Appearance portlet Page Locks Portlet Wiring Tool
Page properties	Page properties
Organize Favorites	Organize Favorites
Login	Login portlet
Edit My Profile	Edit My Profile

 

 

 

3.     Migrating credential vault data

When you migrated the WebSphere Portal configuration using either the command line script or the wizard, the Credential Vault slots and segments were also migrated. This section assumes that the WebSphere Portal migration was successfully completed.

Existing credential secrets must be handled differently depending on your environment:

o      WebSphere Portal Default Vault: complete the following procedure if you want to migrate existing credential secrets to the current WebSphere Portal system.

o      Third-party vault implementation (Tivoli Access Manager): No additional steps are required. Existing credential secrets can be used in the current WebSphere Portal system.

Note: If you decide not to migrate existing credential secrets, users must provide their credential information the first time a Version 6.0 portlet attempts to use the data.

       （参考 Inforcenter ）

 

7      迁移 WCM 数据

 

7.1    安装迁移工具 (Web content migration tool)

Run the WPSconfig. {sh | bat} configure-wcm-migration task from the portal_server_root /config directory of your new system.

• Windows: WPSconfig.bat configure-wcm-migration -DWasUserId=username -DWasPassword=password

The user specified in the command must be a WebSphere Application Server administrator.

 

7.2    清理 WPS5 的 WCM 的错误数据

7.2.1  Reference checker

To view a report:

http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPEReferenceChecker

To correct reference errors, use the following URL:

http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPEReferenceChecker&fix=true

 

7.2.2  Site checker

To view a report, use the following URL:

http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPESiteChecker

To correct site errors, use the following URL:

http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPESiteChecker&fix=true

 

7.2.3  Resource checker

To view a report, use the following URL:

http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPEResourceChecker

To correct resource errors, use the following URL:

http://[HOST]:[PORT]/wps/wcm/connect?MOD=AJPEResourceChecker&fix=true

 

7.2.4  Member fixer

To view a report, use the following URL:

http://[HOST]:[PORT]/wps/wcm/connect?MOD=MemberFixer

To update changes to Member Manager users and groups in Web Content Management items, use the following URL:

http://[HOST]:[PORT]/wps/wcm/connect?MOD=MemberFixer&fix=true

 

 

 

7.2.5  确定没有加密的 Excel,WORD ， PPT 等文件

有加密的 excel\word\ppt 在 WCM 作为附件，会迁移失败，应该在迁移之前去掉保护。

 

 

7.3    WCM 内容迁移

1.     Copy the portal_server_root /wcm/config/ folder from your old system(WPS5) to a temporary migration folder on the new system(WPS6). Do not overwrite the portal_server_root /wcm/config/ on the new system.

2.     Depending on which data repository your old system uses, you will need to copy the following files from your old system to the portal_server_root /wcm/migration/exporter/lib folder of your new system. These will typically be:

o      Oracle Enterprise Edition : ojdbc14.jar

3.     Update the portal_server_root /wcm/migration/exporter/classpath.properties by adding the names of the files you copied in step 2 to the value of the exporter.classpath property.

4.     If migrating from a DB2 repository, you will need to edit the following files located in the /wcm/config/ folder you created in step 1:

o      aptrixjpe.properties : Ensure jdbc.url=jdbc:db2://<db2 host name>:<port number>/wcmdb is configured to point to the database of the old system and ensure that there are no spaces before or after the URL.

o      connect.cfg : Ensure <jdbc:db2://<db2 host name>:<port number>/wcmdb driver="com.ibm.db2.jcc.DB2Driver" />

Note: The port number for DB2 on your new system can be found under %systemroot%/system32/drivers/etc/services on Windows systems or /etc/services on UNIX systems.

5.     If migrating from an embedded Cloudscape repository, stop the portal server on the old system and then copy this database to your new system before migrating Web Content Management. You will need to edit the following files located in the /wcm/config/ folder you created in step 1:

o      aptrixjpe.properties : Ensure jdbc.url=jdbc:db2j:<path_to_database> is configured to point to the location of the Cloudscape database on the new system and ensure that there are no spaces before or after the URL.

o      connect.cfg : Ensure <jdbc:db2j:<path_to_database> driver="com.ibm.db2j.jdbc.DB2jDriver" />

6.     Update the portal_server_root /wcm/migration/config/migration.properties file on your new system. Confirm that the following parameters are set as specified and modify them if necessary:

o      export.path : The path on the local file system where exported data will be saved.

o      import.path : The directory on the local file system where transformed data is saved.

o      summary.path : The path on the local file system where summary configuration files will be created. These files will be used when migrating a secondary system.

o      legacy.config.path : The path on the local file system where the old Web Content Management configuration is located. See step 1.

o      import.servlet.url : The URL of the import servlet, running on the new system. Replace localhost with the appropriate host name for the new system.

o      import.library.name : The name of the library created during import.

o      import.library.locale : zh

7.     Increase the total transaction lifetime timeout of your new WebSphere Portal server to 1200 seconds through the WebSphere Application Server administrative console. Go to Application Servers > server > Container Services > Transaction Service . See the WebSphere Application Server information center for more information. Make a note of the current total transaction lifetime timeout so that it can be restored in step 10.

8.     Restart the portal application server.

9.     Run the wcmmigrate all-data task from the portal_server_root /wcm/migration directory of your new system.

Important: Before you run the wcmmigrate task, make sure that the portal server on the new system is running.

o      Windows: wcmmigrate.bat -user username -password password all-data

The user specified in the command must be a WebSphere Portal administrator.

Notes:

All errors, information and warnings are logged to the console as migration is performed. The message "command successful" is displayed after a successful migration. If the message "command failed" is displayed upon completion you will need to do the following: Review any error messages displayed during the migration. Review the migration log files located under the portal_server_root /wcm/migration/log folder. Make sure you have copied the correct files and directories as described in the primary and secondary migration tasks. Review the settings in the portal_server_root /wcm/migration/config/migration.properties file. Running individual wcmmigrate all-data commands   When you run the wcmmigrate all-data task, a set of commands are executed. To troubleshoot the wcmmigrate all-data task, you can run each of the commands separately. They should be run in the order shown below. validate This validates the migration.properties file, network connectivity and user permissions. This requires a user-name and password. estimate-data This provides an estimate of the time taken and space required for data migration. export-data This exports items from the old system. transform-data This transforms exported items so that they are ready to be imported into the new system. import-data This imports the transformed items. This requires a user-name and password. For example, to run the validate command, run the following command from the portal_server_root /wcm/migration directory. Windows: wcmmigrate.bat -user username -password password validate   The user specified in the command must be a WebSphere Portal administrator. Resuming or restarting wcmmigrate commands Once you have identified and fixed the issue that was causing a migration to fail, you have a choice of either restarting a wcmmigrate command, or resuming a wcmmigrate command from the point where a migration error occurred. For example, to restart the wcmmigrate all-data command, enter the following from the portal_server_root /wcm/migration directory. Windows: wcmmigrate.bat -user username -password password all-data -restart UNIX: ./wcmmigrate.sh -user username -password password all-data -restart i5/OS: wcmmigrate.sh -user username -password password all-data -restart The user specified in the command must be a WebSphere Portal administrator. To resume the wcmmigrate all-data command from the point where migration failed, enter the following from the portal_server_root /wcm/migration directory. Windows: wcmmigrate.bat -user username -password password all-data -resume UNIX: ./wcmmigrate.sh -user username -password password all-data -resume i5/OS: wcmmigrate.sh -user username -password password all-data -resume The user specified in the command must be a WebSphere Portal administrator. Log tracing levels By default, the migration log trace level is set to "fine". This is set in the portal_server_root /wcm/migration/config/migration.properties file. If you change this setting to "finer" or "finest", data migration may slow or fail. If migration is still slow with a trace level of "fine", you should change the trace-level to "info".

 

10.   Verify the migration by reviewing the migration console. The message "command successful" is displayed after a successful migration. If the message "command failed" is displayed upon completion you will need to review the previous steps. See Troubleshooting Web Content Management migration for further information.

Note: The total number of items exported, transformed and imported may not be equal, as some items will be merged and other items added during the migration process.

11.   Restore the total transaction lifetime timeout setting to the original setting that was changed in step 7.

12.   Restart the portal application server.

13.   Review the configuration of the library created when the data was migrated and make changes as required. For example, you will need to enable user access to this library by adding users and groups to each library role. See Working with libraries for further information on configuring a Web content library.

14.   Syndicate the migrated data to all the other servers in your new Web content system. See Syndication for further information.

 

 

7.4    迁移 user profiles

After migrating your primary data you must update the portal users to use the migrated data.

Note: If you are using dynamic keywords then you must migrate Member Manager before migrating user profiles. See Migrating the remaining access control configuration for further information. If you are not using dynamic keywords, or if you have already migrated Member Manager as part of your core IBM^® WebSphere^® Portal migration, you do not need to do migrate Member Manager.

1.     If you are migrating users on a primary system, go to step 3. If you are migrating users on a secondary system, copy the summary configuration files created when migrating your primary system to a folder on the secondary system. See summary.path in the data migration topic.

2.     Update the portal_server_root /wcm/migration/config/migration.properties file. Confirm that the following parameters are set as specified and modify them if necessary:

o      summary.path : The path on the local file system where the old IBM Workplace Web Content Management™ summary configuration files were copied in step 1.

3.     If your LDAP server contains more than 200 users, you must perform the following steps. Otherwise, proceed to step 4.

a.           Stop your WebSphere Portal server.

b.     Make a backup of portal_server_root /wmm/wmm.xml named wmm.xml.bak .

Note: If using i5/OS, wmm.xml is located under portal_server_root .

c.              Edit portal_server_root /wmm/wmm.xml and change the following settings:

§       Change maximumSearchResults , maximumSearchResultsForSortingAndPaging and maximumTotalSearchResultsForSortingAndPaging to a number higher than the total number of users. For example, if you have 300 users, you must change these settings to at least 301.

§       Change searchTimeOut to 2,000,000.

4.     Increase the total transaction lifetime timeout of your new WebSphere Portal server to 3600 seconds through the WebSphere Application Server administrative console. Go to Application Servers > server > Container Services > Transaction Service . See the WebSphere Application Server information center for more information. Make a note of the current total transaction lifetime timeout so that it can be restored in step 7.

5.     Restart the portal application server.

6.     Run the wcmmigrate users task from the portal_server_root /wcm/migration directory, where portal_server_root is the install directory path of the current version of WebSphere Portal.

o      Windows: wcmmigrate.bat -user username -password password users

The user specified in the command must be a WebSphere Portal administrator.

7.     Verify the user migration by reviewing the migration console. The message "command successful" is displayed after a successful migration. If the message "command failed" is displayed upon completion you will need to review the previous steps. See Troubleshooting Web Content Management migration for further information.

8.     Restore the total transaction lifetime timeout setting to the original setting that was changed in step 4.

9.     If you performed step 3, you must do the following:

  .      Stop your WebSphere Portal server.

a.     Restore the wmm.xml.bak file you created in step 3.b to portal_server_root /wmm/wmm.xml .

10.   Restart the portal application server.

 

7.5    迁移 local rendering portlet

After migrating your primary data you must re-configure all local rendering portlets to use the migrated data.

Note: You must migrate Web content data before migrating a local rendering portlet. See Migrating Web content data for further information.

Note: If you have a small number of local rendering portlets, it may be simpler to install and configure new local rendering portlets to use the migrated data instead of migrating any existing portlets. See Configuring the local rendering portlet for further information.

1.     If you are migrating one or more local rendering portlets on a primary system, go to step 3. If you are migrating one or more local rendering portlets on a secondary system, copy the summary configuration files created when migrating your primary system to a folder on the secondary system. See summary.path in the data migration topic.

2.     Update the portal_server_root /wcm/migration/config/migration.properties file. Confirm that the following parameters are set as specified and modify them if necessary:

o      summary.path : The path on the local file system where the old IBM Workplace Web Content Management™ summary configuration files were copied in step 1.

o      virtual.portal : If migrating a local rendering portlet located on a virtual portal, you must enter the name of the virtual portal.

3.     Run the wcmmigrate configure-local task from the portal_server_root /wcm/migration directory, where portal_server_root is the install directory path of the current version of WebSphere Portal.

o      Windows: wcmmigrate.bat -user username -password password configure-local

The user specified in the command must be a WebSphere Portal administrator.

4.     Verify the migration by reviewing the migration console. The message "command successful" is displayed after a successful migration. If the message "command failed" is displayed upon completion you will need to review the previous steps. See Troubleshooting Web Content Management migration for further information.

5.     Verify the configuration of the migrated local rendering portlet. See Configuring the local rendering portlet for further information on configuring a local rendering portlet.

Note: Restart the portal server after completing the above steps to verify that the portlets have been configured correctly.

 

 

7.6    迁移 remote rendering portlet

After migrating your primary data you must re-configure all remote rendering portlets to use the migrated data.

Note: You must migrate Web content data on the system that the remote rendering portlet is configured to use before migrating a remote rendering portlet. See Migrating Web content data for further information.

Note: If you have a small number of remote rendering portlets, it may be simpler to install and configure new remote rendering portlets to use the migrated data instead of migrating any existing portlets. See Configuring the remote rendering portlet for further information.

1.     If you are migrating one or more remote rendering portlets on a primary system, go to step 3. If you are migrating one or more remote rendering portlets on a secondary system, copy the summary configuration files created when migrating your primary system to a folder on the secondary system. See summary.path in the data migration topic.

2.     Update the portal_server_root /wcm/migration/config/migration.properties file. Confirm that the following parameters are set as specified and modify them if necessary:

o      summary.path : The path on the local file system where the old IBM Workplace Web Content Management summary configuration files were copied in step 1.

o      virtual.portal : If migrating a remote rendering portlet located on a virtual portal, you must enter the name of the virtual portal.

3.     Update the portal_server_root /wcm/migration/config/remote_rendering.properties file. Confirm that the following parameters are set as specified and modify them if necessary:

o      remote.host.base.path.list : Enter the remote host base path of old remote rendering portlet. This is the "Web Content Management Server Host" specified in the old remote rendering portlet configuration. For example,

o      



remote.host.base.path.list=http://oldhostname:9081

Note: If all your old remote rendering portlets use data from a single system you can specify remote.host.base.path.list=all .

o      WCM_REMOTE_HOST_BASE_PATH : Enter the remote host base path of the server the remote rendering portlet is being migrated to. For example,

o      



WCM_REMOTE_HOST_BASE_PATH=http://newhostname:9081

4.     Run the wcmmigrate configure-remote task from the portal_server_root /wcm/migration directory, where portal_server_root is the install directory path of the current version of IBM WebSphere Portal.

o      Windows: wcmmigrate.bat -user username -password password configure-remote

The user specified in the command must be a WebSphere Portal administrator.

5.     Verify the migration by reviewing the migration console. The message "command successful" is displayed after a successful migration. If the message "command failed" is displayed upon completion you will need to review the previous steps. See Troubleshooting Web Content Management migration for further information.

6.     Verify the configuration of the migrated remote rendering portlet. See Configuring the remote rendering portlet for further information on configuring a remote rendering portlet.

Note: Restart the portal server after completing the above steps to verify that the portlets have been configured correctly.

 

 

 

7.7    WCM 迁移成功后修改工作

 

The IBM^® Workplace Web Content Management™ migration process does not automatically update your Web content to use all the new features of the current release. The following steps are recommended to update your old Web content to take advantage of the new Web Content Management features.

7.7.1  Web content configuration files

The Web content configuration files connect.cfg and aptrixjpe.properties have been deprecated and replaced by the WCMConfigService.properties file. No configuration settings from your old system are migrated to this file. You will need to edit this file and update settings to match your old configuration if required.

The WCMConfigService.properties file is located under:

• Windows: portal_server_root /wcm/shared/app/config/wcmservices

Note: The JDBC URL property

Database driver URLs now need to contain escape characters. You will need to edit any JDBC URLs copied from an old connect.cfg file. For example:

• Old URL:

connect.connector.sqlconnector.databases.jdbc:microsoft:sqlserver://host:port;DatabaseName=dbname

• New URL:

connect.connector.sqlconnector.databases.jdbc\:microsoft\:sqlserver\://host\:port;DatabaseName\=dbname

7.7.2  Anchor tags and URLs

You should replace any anchor tags or URLs in presentation templates or element designs by using either a link element, or using the "add link" feature in HTML and rich text fields and elements. See the Link element and Inserting a link in an element topics for further information.

To assist in this process, the following files are created under the summary path folder specified during data migration:

• transformed_contents.links
• transformed_library_components.links
• transformed_content_components.links
• transformed_presentation_templates.links

These files can be used as reference material as they list the old and new names and paths of content items, components (library components), elements (content components) and presentation templates.

7.7.3  Links to Web Content Management content from external sites

During migration, some items will be merged, added or renamed. You may need to update links to Web Content Management content from external sites.

To assist in this process, the following files are created under the summary path folder specified during data migration:

• transformed_contents.links
• transformed_library_components.links
• transformed_content_components.links
• transformed_presentation_templates.links

These files list the old and new names and paths of content items, components (library components), elements (content components) and presentation templates.

7.7.4  Siblings with the same name

Unlike previous versions of Web Content Management, you are not able create two sibling Web Content items using the same name in IBM WebSphere^® Portal version 6.0.

For example, your old system may have the following site framework:

• MySite
  • MySiteArea
  • MySiteArea

During migration, the second site area will be renamed as "MySiteArea_1". The site framework will now look like this:

• MySite
  • MySiteArea
  • MySiteArea_1

Any references to the path "MySite/MySiteArea" will be left unchanged, but will now only point to the site area named "MySiteArea". You will need to edit any paths that should now point to "MySite/MySiteArea_1" instead.

This example also applies to other siblings such as categories and content items.

7.7.5  Draft items

Any draft sites, site areas and taxonomies that have child items will be published during migration, as will their children. Any items that have had there status changed from draft to published are listed in published_draft_items.txt located under the summary path folder specified during data migration. You should review this file and check that any changes to these published items are valid.

If no items have had there status changed from draft to published, this file will not be created.

7.7.6  Navigator elements

Paging is now supported in the design of navigator elements. After migration, the maximum number of items to be displayed per page is set at one hundred by default. If any or your navigators display more than one hundred items, you will need to edit this figure. You can also add a paging element to your navigator design. See Defining navigator element design options for further information.

7.7.7  Menu elements

A "no result" design has been added to menu elements. You must edit all your menus and enter appropriate text in the "no result" design. Otherwise, nothing will be displayed when a menu finds no results. See Defining menu element formatting options for further information.

7.7.8  Name and title fields

A title field has been added to the identification section of all items. The title is the text displayed to end-users when viewing a list of items in the authoring portlet. Unlike the name, titles can use double-byte and non-ASCII characters. When migrated, the current name is also copied to the title field. You will need to edit any items where you would like to use a different title than one created during migration.

Any Web content tags that use the field="name" attribute, such as the placeholder tag, can be changed to use field="title" as well.

7.7.9  Connect tags

The use of "connect" tags has been deprecated, with the exception of component caching. Content that uses "connect" tags will still work, but it is recommended that "connect" tags be replaced with other standard Web content features. See Displaying data from external sources for further information.

7.7.10                Web Content Management search

The Web Content Management search module is no longer supported. The WebSphere Portal search features are now used to search for Web Content.

Any search forms that use the Web Content Management search module must be replaced or updated with search forms using the WebSphere Portal search features. See Searching Sites for details on using the WebSphere Portal search features with Web content.

7.7.11                Moving objects to new libraries

The Web Content Management migration process will only create a single library. To implement multiple libraries, you will need to create new libraries and move items from the migrated library into the new libraries. See Copying and moving items for further information.

7.7.12                API code

After migration, any Web Content Management API code should still function as normal. The API will, by default, use the library specified in the WCMConfigService.properties file.

Once you create new libraries and add items to those libraries, you will need to update your API code to be library-specific by using the setCurrentDocumentLibrary method. See the Javadoc HTML files located under the was_profile_root \AppServer\profiles\wp_profile\installedApps\nodename\wcm.ear\ilwwcm.war\webinterface\ folder for further information on using this method.

7.7.13                JSP files

Any JSP files used on your old system will need to be manually copied to your new system. See JSP elements for details on where to store JSP files.

7.7.14                Authoring portlet access changes

You no longer assign access to the different views in the authoring portlet by configuring the authoring portlet. Access to the different views in the authoring portlet is now determined by the role assigned to users and groups. See Using item type roles within a library for further information.

7.7.15                Referential integrity

Referential integrity features have been added in this release. See Collaborative authoring and Deleting items for further information.

These features are not applied to a migrated items that contain element or component tags until the item is opened and saved in the authoring portlet.

7.7.16                Authoring portlet pages

Although authoring portlets are not migrated, any portal pages that previously displayed an authoring portlet on your old system are migrated as blank pages. You can either delete these pages, or add a new authoring portlet to the blank page.

7.7.17                Presentation templates

Migrated presentation templates may contain additional HTML header information not present in the original presentation template. The additional header information will not affect any content rendered in the presentation template and can be deleted.

7.7.18                Removing the migration tool

To remove the migration tool, run the remove-wcm-migration task from the portal_server_root /config directory of your new system.

• Windows: WPSconfig.bat remove-wcm-migration

 

 

 

 

8      迁移后验证任务

This section provides information that you can use to verify the success of the migration tasks.

Perform the appropriate tasks to verify that your migration was successful:

1.     Verify Notes and Domino Web Access (iNotes™) portlets migration

2.     Verify migration of portal clients

3.     Verify migration of user customizations

4.     Verify migration of credential vault data

5.     Verify migration of themes and skins

6.     Verify migration of portlet applications

7.     Verify migration of portlet configuration data

8.     Verify migration of virtual resources

9.     Verify migration of pages

8.1    Verify Notes and Domino Web Access (iNotes) portlets migration

a.     Log in to the current WebSphere Portal Administrative Interface.

b.     Click Portlet Management > Portlets .

c.     There should be a portlet in the portlet list for each portlet that existed in the previously installed version.

Note: In some previous versions of WebSphere Portal, these portlets were individual portlets, while in the current version, they are copies of one portlet.

d.     Select each migrated portlet, click Configure Portlet , and verify that the portlet settings were migrated correctly. If you are migrating pages that had Notes portlets in them, the portlets should be on the page after migration and should work as they did on the previous version.

8.2    Verify migration of portal clients

e.     Log in to the current WebSphere Portal Administrative Interface.

f.      Click Administration > Portal Settings > Supported Clients .

g.     Verify that the portal clients that you migrated show up in the list of supported clients.

h.     Select the clients that were migrated and click Edit Selected Client to verify that all settings for the client were migrated.

i.       Verify that your migrated clients are able to access WebSphere Portal.

8.3    Verify migration of user customizations

User customizations are artifacts that are attributed to a portal user that has EDIT but not MANAGE permissions on a page. These are created when such a user changes the layout of a page or edits portlet settings.

j.       Log in to the current WebSphere Portal with credentials of users having the customizations.

k.     Verify that all user customizations from the previous version are present in the current version. You can also pick users at random and ensure that the users see the correct customizations in the current version by comparing them visually to customizations in the previous version.

8.4        Verify migration of credential vault segments and slots

These procedures help verify that the credential slots and segments were migrated successfully. Existing credential vault data must be migrated with a separate manual procedure that is described in the Migrating the remaining access control configuration section.

l.       Log in to the current WebSphere Portal Administrative Interface.

m.    Click Access and then click Credential Vault on the left navigation.

n.     Using the Manage vault segments and Manage system vault slots options, verify that credential segments and slots from the previous version are now also present in the current version.

8.5    Verify migration of themes and skins

o.     Log in to the current WebSphere Portal Administrative Interface.

p.     Click Portal user interface > Themes and Skins in the left navigation.

q.     Verify that the themes and skins that are listed are the ones that you migrated from the previous version to the current version.

r.      Verify that you are able to associate migrated themes and skins to existing pages and portlets, and verify that they produce the required view.

8.6    Verify migration of portlet applications

s.     Log in to the current WebSphere Portal Administrative Interface.

t.      Click Portlet Management > Applications on the left navigation.

u.     Verify that the portlet applications that are listed are the ones that you migrated from the previous version.

v.     For each Web Module, verify that all your portlet applications also display in the Portlet Applications list.

w.     For each portlet application that is migrated and for which you have set up parameters on the previous version, click Edit portlet application next to the portlet applications list and verify that the parameters were migrated correctly.

You should also verify the access control for migrated portlet application and portlets using the Administrative Interface.

x.     Click Access > Resource Permissions and select Portlet Applications from Resource Types .

y.     Click Assign Access to verify the access control information.

z.     Click Access > Resource Permissions and select Portlets from Resource Types .

aa.   Click Assign Access to verify the access control information.

You can also perform a full export of the current WebSphere Portal after migration is complete and verify the roles in the exported XML file. Refer to The XML configuration interface for more information.

8.7    Verify migration of portlet configuration data

bb.   Log in to the current WebSphere Portal Administrative Interface.

cc.   Click Portlet Management > Portlets on the left navigation.

dd.   Verify that all portlet configuration data migrated from the previous version are present in the current version by selecting the portlet from the list and clicking Configure portlet .

8.8    Verify migration of virtual resources

ee.   Log in to the current WebSphere Portal Administrative Interface.

ff.     Click Access > Resource Permissions on the left navigation.

gg.   Select Virtual Resources from Resource Types .

hh.   Verify that all virtual resources migrated from the previous version are present in the current version.

8.9    Verify migration of pages

If only the Welcome and Getting Started pages display, see Problem: After migration, only the Welcome and Getting Started pages are available for information; otherwise, migration of pages was successful.

 

 

附件：

 

Technical contents of ISO 639:1988 (E/F)

"Code for the representation of names of languages".

 

Typed by Keld.Simonsen@dkuug.dk 1990-11-30  <ftp://dkuug.dk/i18n/ISO_639>

Minor corrections, 1992-09-08 by Keld Simonsen

Sundanese corrected, 1992-11-11 by Keld Simonsen

Telugu corrected, 1995-08-24 by Keld Simonsen

Hebrew, Indonesian, Yiddish corrected 1995-10-10 by Michael Everson

Inuktitut, Uighur, Zhuang added 1995-10-10 by Michael Everson

Sinhalese corrected, 1995-10-10 by Michael Everson

Faeroese corrected to Faroese, 1995-11-18 by Keld Simonsen

Sangro corrected to Sangho, 1996-07-28 by Keld Simonsen

 

Two-letter lower-case symbols are used.

The Registration Authority for ISO 639 is Infoterm, Osterreichisches

Normungsinstitut (ON), Postfach 130, A-1021 Vienna, Austria.

 

aa Afar

ab Abkhazian

af Afrikaans

am Amharic

ar Arabic

as Assamese

ay Aymara

az Azerbaijani

 

ba Bashkir

be Byelorussian

bg Bulgarian

bh Bihari

bi Bislama

bn Bengali; Bangla

bo Tibetan

br Breton

 

ca Catalan

co Corsican

cs Czech

cy Welsh

 

da Danish

de German

dz Bhutani

 

el Greek

en English

eo Esperanto

es Spanish

et Estonian

eu Basque

 

fa Persian

fi Finnish

fj Fiji

fo Faroese

fr French

fy Frisian

 

ga Irish

gd Scots Gaelic

gl Galician

gn Guarani

gu Gujarati

 

ha Hausa

he Hebrew (formerly iw)

hi Hindi

hr Croatian

hu Hungarian

hy Armenian

 

ia Interlingua

id Indonesian (formerly in)

ie Interlingue

ik Inupiak

is Icelandic

it Italian

iu Inuktitut

 

ja Japanese

jw Javanese

 

ka Georgian

kk Kazakh

kl Greenlandic

km Cambodian

kn Kannada

ko Korean

ks Kashmiri

ku Kurdish

ky Kirghiz

 

la Latin

ln Lingala

lo Laothian

lt Lithuanian

lv Latvian, Lettish

 

mg Malagasy

mi Maori

mk Macedonian

ml Malayalam

mn Mongolian

mo Moldavian

mr Marathi

ms Malay

mt Maltese

my Burmese

 

na Nauru

ne Nepali

nl Dutch

no Norwegian

 

oc Occitan

om (Afan) Oromo

or Oriya

 

pa Punjabi

pl Polish

ps Pashto, Pushto

pt Portuguese

 

qu Quechua

 

rm Rhaeto-Romance

rn Kirundi

ro Romanian

ru Russian

rw Kinyarwanda

 

sa Sanskrit

sd Sindhi

sg Sangho

sh Serbo-Croatian

si Sinhalese

sk Slovak

sl Slovenian

sm Samoan

sn Shona

so Somali

sq Albanian

sr Serbian

ss Siswati

st Sesotho

su Sundanese

sv Swedish

sw Swahili

 

ta Tamil

te Telugu

tg Tajik

th Thai

ti Tigrinya

tk Turkmen

tl Tagalog

tn Setswana

to Tonga

tr Turkish

ts Tsonga

tt Tatar

tw Twi

 

ug Uighur

uk Ukrainian

ur Urdu

uz Uzbek

 

vi Vietnamese

vo Volapuk

 

wo Wolof

 

xh Xhosa

 

yi Yiddish (formerly ji)

yo Yoruba

 

za Zhuang

zh Chinese

zu Zulu