迁移到 WebSphere Process Server Version 7

从 WebSphere Process Server V6.2.0.x 迁移到 V7.0.0.x

本教程提供了有关从 WebSphere® Process Server V6.2.0.2 迁移到 V7.0.0.1 的指导说明。重点介绍了一些需要管理员加倍小心以避免丢失宝贵业务数据的步骤。

Phani Madgula, 软件开发人员, IBM

作者照片Phani Madgula 在 India Software Labs (ISL) 从事 WebSphere Process Server 支持工作。他在 IBM 工作了 6 年,曾经在多个产品团队工作过,包括 WebSphere Application Server Community Edition、WebSphere Business Integration Adapters 和 DB2。他有开发 JEE 应用程序、产品支持和数据库管理方面的工作经历。他是经过认证的 Oracle9i 专业人员。


developerWorks 投稿作者

Rajiv Madassery, 软件开发人员, IBM

Rajiv Madassery 的照片Rajiv Madassery 是 India Software labs (ISL) 的 WebSphere Process Server Level 2 Support 团队的首席软件工程师。Rajiv 于 2003 年加入 IBM,曾经在 WebSphere Business Integration Adapters Functional Verification Test 团队和 WebSphere Application Server Level 2 Support 团队工作。



2010 年 6 月 10 日

简介

本教程将以与 迁移到 WebSphere Process Server V6.2 类似的方式呈现。然而,WebSphere Process Server V7.0(此后简称为 Process Server)附带了一组可以帮助完成迁移的改进的工具和命令。它还提供了一组新的术语,可以帮助清楚地理解整个迁移过程,从而在执行迁移过程中进一步减少出错的机率。根据用户的运行中的部署环境的需求和限制,将推荐使用不同的迁移方法。迁移类型有两种,一种是独立配置文件的迁移,另一种是集群环境的迁移。总之,根据需求、约束以及源环境的类型,迁移过程会采取特定的步骤。根据多年的经验,Process Server 开发团队在 V7.0 迁移过程中累积了大量的改进。

随着 Process Server 最新版本的发布和对老版本的支持停止,客户不得不从当前环境迁移到最新的受支持版本。该产品的最新版本提供了新功能、已知缺陷的补丁。它们通常要比旧版本更可靠。然而,当前运行的环境和应用程序已经针对企业的特定需求进行了配置、调优和健壮的测试。如果无法将配置和应用程序数据自动从当前版本迁移到最新版本,那么用户将面临挑战。在最新版本中手动创建相同的环境是一项枯燥、容易出错的任务。为了帮助用户自动迁移到最新版本,最新版本中提供了一组过程以及一些可用的工具和命令。当用户决定从 Process Server 的当前版本迁移到最新版本时,这一过程被称为 “版本到版本迁移”。在这种情况下,Process Server 的最新版本与当前版本安装在一起。然后,执行一系列迁移任务,把配置数据、相关的应用程序数据和数据库模式从当前版本复制并转换到最新版本。

这种方式与 Process Server 升级任务不一样,升级任务用最新信息替换现有系统中过时的文件或数据。应用更新包、补丁包和临时包都属于升级。

迁移过程是一个复杂的任务,需要仔细地计划,才能成功地从以前版本的 Process Server 环境迁移到最新版本。Process Server 环境中运行的应用程序使用各种组件,比如 Service Integration Bus (SIB)、Business Process Choreographer (BPC)、Business Space 等等。每个组件都使用数据库存储运行时数据。因此,在迁移之前,需要充分了解迁移过程涉及的风险,制定适当的备份和恢复计划,从而避免在迁移失败时丢失宝贵的业务数据。除了上面提到的方面之外,如果当前的 Process Server 环境拥有多个使用不同的功能、附加级别(augmentation level)和集群创建的配置文件,管理员还必须遵循相关的建议和过程。如果用户要求停机时间尽可能短,需要按特定的过程执行迁移。更多信息请参见 WebSphere Process Information Center 主题 迁移概述

在本教程中

本教程详细讨论从 Process Server V6.2.0.2 迁移到 V7.0.0.1 的过程。采用以下方式讲解迁移过程:

  • 选择 Process Server V6.2.0.2 中的一个示例部署环境(配置为 gold 拓扑)作为源环境。源环境要迁移到 Process Server V7.0.0.1。迁移后 Process Server V7.0.0.1 中的部署环境称为目标环境
  • 在源环境中部署一个示例 BPEL 应用程序,其中包含一个人工任务。在开始迁移之前,启动一些 BPEL 实例并保持运行状态。在执行迁移之后,将在目标环境中运行这些 BPEL 实例。这演示了 BPC 数据库模式或运行时数据迁移。
  • 同样,在源环境中部署另一个示例应用程序,它会生成失败的事件。在迁移之前,生成一组失败的事件。在执行迁移之后,将在目标环境中获取这些失败的事件。这说明了新版本的应用程序兼容性。
  • 使用迁移向导工具执行迁移。使用这个工具迁移应用程序数据和配置数据。
  • 使用数据库脚本迁移数据库模式和运行时数据。

关于 WebSphere Process Server 补丁包的说明

在本教程中,使用 Process Server V6.2.0.2 作为源环境,使用 Process Server V7.0.0.1 作为目标环境。从 Process V6.2.0.x(从任何补丁包)到 Process Server V7.0.0.x(到任何补丁包)的迁移过程是相同的。在开始迁移过程之前,建议在目标环境中应用最新的补丁包。

本教程分为以下几节:

前提条件

  • 您需要了解 J2EE 概念和数据库概念。
  • 您应该具有配置 Process Server 部署环境(gold、silver 和 bronze 拓扑)和在部署环境中执行管理活动的技能。
  • 您应该有创建和管理 DB2® 数据库的实践经验。应该知道如何在 DB2 数据库上运行管理脚本。

系统需求

对于本教程中讲解的迁移活动,需要以下环境:

  • 两个 Microsoft® Windows 2003 服务器或有至少 2 GB RAM 的 Windows XP Service Pack 2 桌面机
  • IBM® DB2 Fix Pack 9.5.0.1
  • IBM WebSphere Process Server V6.2.0 Fix Pack 2
  • IBM WebSphere Process V7.0.0.0 Fix Pack 1

学习时间

  • 配置源(WebSphere Process Server V6.2.0.2)环境:8 小时
  • 执行迁移:6 小时

配置源环境

本教程使用两个 Windows 服务器 Windows1Windows2。在这两个 Windows 服务器上,将安装 Process Server V6.2.0 Fix Pack 2 和 Process Server V7.0.0 Fix Pack 1。在 Windows1 服务器上,还安装 DB2 作为公用数据库和 Business Process Choreographer 数据库。

在本节中,执行以下任务:

安装 WebSphere Process Server V6.2.0 Fix Pack 2

在两个 Windows 服务器上安装 Process Server V6.2.0 Fix Pack 2。关于如何安装 Process Server V6.2.0.2 的说明,请参见 安装和配置 WebSphere Process Server。在安装期间 创建任何配置文件。在完成安装任务之后,将单独创建所需的配置文件。安装基本的 Process Server V6.2.0.0 后,按照 Technote: WebSphere Process Server V6.2.0 Fix Pack 2 (V6.2.0.2) 中的说明应用 Fix Pack 2。因为在 Information Center 中有详细的说明,本教程不详细讨论安装过程。

安装 Process Server V6.2.0 Fix Pack 2 之后,运行以下命令并查看输出中的版本:

<WPS6.2.0.2_home>\bin>versionInfo.bat
Installed Product
---------------------------------------------------------------------

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

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

Name                     IBM WebSphere Process Server
Version                  6.2.0.2
ID                       WBI
Build Level              of0936.02
Build Date               9/11/09

<WPS6.2.0.2_home> 是指两个 Windows 服务器上安装 Process Server V6.2.0.2 的目录。

安装 DB2 Fix Pack 9.5.0.1

在 Windows1 服务器上安装 DB2 Fix Pack 9.5.0.1。安装的前提条件见 产品文档。文档还说明安装过程以及如何应用补丁包。完成这个任务之后,就在 Windows1 服务器上安装了 DB2 Fix Pack 9.5.0.1。

按 gold 拓扑配置部署环境

在本节中,我们要配置源环境。创建一个包含应用程序集群、支持集群和消息传递集群的部署环境。每个集群都有一个集群成员,在两个 Windows 服务器上的 <WPS6.2.0.2_home> 中创建的配置文件中进行了配置。已经有许多关于这个主题的 developerWorks 文章和 IBM Redbook,所以这里不详细讨论。下面的参考资料有助于准备部署环境:Building clustered topologies in WebSphere Process Server V6.2

创建 WPRCSDB 和 BPEDB 数据库,它们分别存储公用数据库存储库和 Business Process Choreographer 数据。这些数据库是在 DB2 上创建的。部署环境的名称是 WPSMgEnv。创建和配置部署环境的步骤如下:

  1. 在 DB2 上创建 WPRCSDB 和 BPEDB 数据库,如图 1 所示。
    图 1. DB2 中创建的数据库
    DB2 中创建的数据库
  2. 在 Windows1 服务器上,在 <WPS6.2.0.2_home> 中创建部署管理器配置文件 Dmgr01。指定 WPRCSDB 作为公用数据库,同时创建配置文件。
  3. 在 Windows1 服务器上,在 <WPS6.2.0.2_home> 中创建一个托管配置文件 Custom01
  4. 在 Windows2 服务器上,在 <WPS6.2.0.2_home> 中创建一个托管配置文件 Custom02
  5. 将两个定制配置文件与 Dmgr01 联合起来。
  6. 创建一个采用 gold 拓扑的部署环境并命名为 WPSMgEnv。执行 Building clustered topologies in WebSphere Process Server V6.2 中提供的步骤。
  7. 在 Windows1 和 Windows2 服务器上创建的托管配置文件中,分布 WPSMgEnv.AppTarget、WPSMgEnv.Support 和 WPSMgEnv.Messaging 集群的集群成员。
  8. 指定 WPRCSDB 作为公用存储库的数据库名称,BPEDB 作为 Business Process Choreographer 数据库的名称。WPRCSDB 数据库用于消息传递引擎和 Common Event Infrastructure (CEI)。
  9. Configuring Business Space as part of the Deployment Environment Configuration wizard 解释了如何在 Process Server V6.2 中配置 Business Space。必须为 Business Space 手动创建数据库对象。如果数据库对象未被创建,支持集群成员将在启动时抛出 SQL 异常。这些错误不会阻塞 Process Server 上的任何其他活动,除非 Business Space 组件在应用程序中被使用。在本教程中,我们不会讨论 Business Space 组件的迁移活动。然而,该过程仍然类似于其他组件。
  10. 生成部署环境后,cell 拓扑将如图 2 所示。
    图 2. Cell 拓扑
    Cell 拓扑

注意源环境中的拓扑:在图 2 中,phani2CellManager01 节点对应于 Dmgr01 配置文件,而 phani2Node05 对应于 Custom01 配置文件。这些节点是在 Windows1 服务器上创建 Dmgr01 和 Custom01 配置文件时创建的。rmadasse3Node06Custom02 配置文件对应,并在 Windows2 机器上创建该配置文件时一同创建。在生成部署环境之后,也会替您创建相似的拓扑(节点名称可能不一样)。但是,如果使用 WPSTestEnv 作为部署环境名称,那么三个集群的名称是相同的。

部署示例模块

在源环境中部署 EAR_file_samples.zip 文件提供的两个示例应用程序。这两个应用程序用于生成一些失败的事件和创建业务过程实例。在迁移之后,将在目标环境中检查失败的事件和过程实例是否保持不变。

  1. 在 Window1 和 Windows2 服务器上,启动 Custom01 和 Custom02 配置文件的节点代理。
  2. 启动 WPSMgEnv 部署环境。启动部署环境之后,状态如图 3 所示。
    图 3. 启动部署环境
    启动部署环境
  3. 检查所有集群成员的日志,看看是否出现错误。如果出现任何重要的异常,在继续迁移之前修复这些错误。
  4. 下载 HelloWorldWithBOApp.earToDoTaskApp.ear 文件。
  5. 将它们安装到 WPSMgEnv.AppTarget 集群,并启动应用程序,如图 4 所示。
    图 4. 启动样例应用程序
    启动样例应用程序
  6. 执行完整的节点重新同步,把应用程序状态传播到 Dmgr01。
  7. ToDoTaskApp.ear 应用程序创建一个名为 RequestProcess 的 BPEL 过程模板。使用 BPCExplorerRequestProcess 模板启动几个过程实例。BPC Explorer 应用程序安装在 WPSMgEnv.Support 集群上。查明 WPSMgEnv.Support 集群的集群成员的 HTTP 端口,使用 http://<hostname>:<port>/bpc 打开 BPC Explorer。如果链接没有打开 BPC Explorer 应用程序,应该检查映射的虚拟主机中是否添加了主机名和端口。
  8. 重启几个过程实例后,单击 My To-dos 链接并处理一些需要完成的任务,然后将剩余的任务保持在运行状态。每个过程实例有一个期望用户处理的 to-do 任务。过程实例提出一个问题,期望用户通过处理 to-do 任务提供答案。对于已完成的任务,对应的过程实例会将其状态标识为已完成。
  9. 已创建的或已完成的过程实例将显示在 BPC Explorer 中,如图 5 所示。
    图 5. 源环境中的过程实例
    源环境中的过程实例
  10. 一直在运行的任务实例将显示在 BPC Explorer 中,如图 6 所示。
    图 6. 源环境中运行的人工任务
    源环境中运行的人工任务
  11. 现在不处理这些任务。让这些任务继续运行并启动迁移过程。执行迁移之后,将回到 BPC Explorer 中处理这些任务。这说明可以在运行过程实例和人工任务的同时执行迁移。
  12. 打开浏览器窗口并通过链接 http://localhost:9080/HelloWorldWithBOWeb/TestAll.jsp 调用 HelloWorldWithBOApp.ear 应用程序中的 TestAll.jsp。这个 JSP 文件生成一些失败的事件,可以在管理控制台中查看它们,见图 7。
    图 7. 源环境中的失败事件
    源环境中的失败事件
  13. 执行迁移之后,将检查是否保留了这些失败的事件并可以在管理控制台中查看。

迁移前活动

版本到版本迁移过程指的是一系列将配置数据、应用程序和数据库数据从旧版本迁移到 Process Server V7.0 的活动。迁移工具或命令可以帮助迁移完整的生产配置、应用程序和数据库。默认情况下,Process Server 可以向后兼容早期版本中开发的应用程序。也就是说,为以前版本开发的应用程序不需要修改即可在新版本上运行。然而,用户应用程序将不能够使用最新版本中的新特性,直到使用开发工具对应用程序升级。系统应用程序将在迁移期间升级。

如本教程前面所述,Process Server V7.0 带来了一些新的术语、工具或命令来帮助执行迁移。

在本节中,您将了解以下内容:

迁移概念

Process Server V7.0 中的版本到版本迁移的基础概念是 迁移方法。如何选择迁移方法取决于您的源开发环境的需求或约束。有三种类型的迁移方法可供选择:

  • 运行时(Runtime)
  • 手动(Manual)
  • 工件(Artifact)

运行时迁移(生产环境)

对于这种方法,将使用迁移过程或工具来将配置数据、应用程序和数据库数据从源环境迁移到目标环境。数据库模式和运行时数据都将直接(inline)升级。源环境在目标环境中被复制。完成迁移过程后,源环境将变为不可用。这种方法同时支持集群式环境和单独的服务器的迁移。它将用户应用程序按原样从源环境迁移到目标环境。因此,用户应用程序不会进行升级来利用 Process Server V7.0 的新特性。在完成迁移过程后,长期运行的过程和失败事件(在执行迁移的过程中始终在源环境中运行)将在目标环境中得到处理。用户倾向于这种迁移方法是因为它在目标环境中原样复制了完整的源环境。

另一方面,需要停止应用程序才能够完成迁移。在尝试投入到生产环境中之前,需要对试运行环境执行端到端测试和检验。执行这项任务的管理员必须注意回滚过程并制定执行计划,以应对可能出现的迁移失败。

手动迁移(并行生产环境)

这种方法更像是一种手动过程。有关更多信息,请参见 迁移方法

工件迁移(包含开发工具迁移的并行生产环境)

该方法与手动迁移(并行生产环境)相同。此外,用户应用程序也将通过 WebSphere Integration Developer V7.0 升级,从而能够与 Process Server V7.0 兼容。

在本教程中,您将在源环境中执行运行时迁移。

迁移工具

对于运行时迁移,用户将需要使用迁移工具或命令来执行迁移。这些工具可分为以下两类:

  • 配置文件迁移工具
  • 数据库升级和迁移工具

配置文件迁移工具

这些工具或命令可以帮助将每一个源配置文件从源环境迁移到目标环境。迁移配置文件是一个分三步骤的过程:

  1. 从源配置文件中获得配置文件的快照。
  2. 在目标环境中创建目标配置文件。
  3. 将 snapshot 目录中的配置迁移到目标配置文件中。

以下命令行工具可以帮助执行上面的任务:

  • BPMSnapshotSourceProfile 命令行实用工具
  • BPMCreateTargetProfile 命令行实用工具
  • BPMMigrateProfile 命令行实用工具

Process Server V7.0 还提供了一个配置文件迁移向导 GUI,可以按照顺序执行以上所有任务。然而,配置文件迁移向导并不能用于所有平台,或者是不能用于某些情况下的迁移。有关更多信息,请参见 运行时迁移工具

在本教程中,您将使用配置文件迁移向导执行所有配置文件的迁移。

数据库升级和迁移工具

WebSphere Process Server 在运行中使用以下数据库:

  • Business Process Choreographer 数据库
  • Business Space 数据库
  • 通用数据库
  • Common Event Infrastructure 数据库
  • Messaging Engine 数据库

在本教程中,您将使用附带的工具和手动过程迁移公用数据库和 Business Process Choreographer 数据库。迁移其他数据库的过程在本质上与此类似。有关更多信息,请参见 运行时迁移工具

迁移类型

Process Server V7.0 引入 迁移类型 一词来区分独立环境的迁移和部署环境的迁移:

  • 独立迁移:这些过程将对独立的配置文件执行迁移。
  • 网络部署迁移:这种迁移涉及一个部署环境,其中包含了需要迁移的集群。部署环境可能包含多个托管节点,这些可能也构成了集群的一部分。对于包含集群的部署环境,需要执行额外的步骤来迁移集群级别上的配置数据。由于我们的源环境涉及多个节点,因此我们将使用这个类别中提到的过程执行迁移。

运行时迁移过程

迁移活动在图 8 所示的流程图中得到了最好的阐释。该流程图提供了在源环境中执行迁移的过程。流程图中的每个任务都表示要执行的一组特定操作。对于每个任务,本教程都将介绍与之对应的参考。

流程图中的一些任务将在各个不同阶段对配置文件进行备份。在整个迁移过程中完成某个重要的任务后将执行备份。当迁移过程在某个点失败,那么当前活动正在执行的对应的配置文件可能会被破坏。备份可以帮助您从之前的一致状态中恢复这些配置文件,并从之前状态一致的点重新开始迁移过程。在迁移期间,源环境完全被停止。迁移过程是由用于执行部署环境的运行时迁移的步骤组成的,部署环境针对 gold 拓扑进行了配置,并且被完全停止。

图 8. 描述迁移活动的流程图
描述迁移活动的流程图

运行时预迁移检查列表

运行时预迁移检查列表 主题列出了在开始迁移之前需要考虑的事项。对于本教程中创建的样例源环境,我们必须考虑到目标配置文件目录和源配置文件快照目录的存储需求。数据库用户具有足够的特权来执行数据库迁移脚本。

更为重要的是,您需要在源环境中备份配置文件和数据库。数据库将直接升级。因此,在开始迁移之前对数据库进行备份非常重要,如果迁移由于意外事件而无法继续时,备份可以帮助您恢复源环境。在本节中,您将执行下面的任务:

备份源环境中的配置文件

  1. 在 Windows1 服务器中,导航到 <WPS6.2.0.2_home>/bin 目录并提交下面的命令来备份 Dmgr01 配置文件:
    <WPS6.2.0.2_home>\bin\manageprofiles.bat –backupProfile -profileName 
    Dmgr01 -backupFile <target_backup_dir>\Dmgr01.zip
  2. 类似地,在 Windows1 服务器上,导航到 <WPS6.2.0.2_home>/bin 目录并提交下面的命令备份 Custom01 配置文件:
    <WPS6.2.0.2_home>\bin\manageprofiles.bat –backupProfile 
    -profileName Custom01-backupFile <target_backup_dir>\Custom01.zip
  3. 同样,在 Windows2 服务器上,导航到 <WPS6.2.0.2_home>/bin 目录并提交下面的命令备份 Custom02 配置文件:
    <WPS6.2.0.2_home>\bin\manageprofiles.bat –backupProfile 
    -profileName Custom02 -backupFile <target_backup_dir>\Custom02.zip

备份的配置文件可以使用 –restoreProfile 选项存储。有关更多信息,请参考 manageprofiles 命令

有关 SOAP Connector 属性的注意事项

根据源环境中部署的应用程序的大小,我们建议您在源配置文件中为 SOAP 请求超时属性设置合适的值。这可以避免 SOAP connector 发生超时。有关更多信息,请参见 Java 管理扩展连接器属性

备份源环境中的数据库

您需要使用特定于数据库的过程来备份 Process Server 数据库。在我们的源环境中,我们在 DB2 中创建了 WPRCSDB 和 BPEDB。备份概述 解释了 DB2 中的备份和恢复过程。

为迁移准备目标环境

在本节中,将在 Windows1 和 Windows2 服务器上安装 Process Server V7.0.0 Fix Pack 1。在版本到版本迁移中,目标版本与以前的版本安装在一起。在迁移期间,从源配置文件复制配置数据和应用程序,然后转换并写到相同物理机器上安装的目标版本中创建的配置文件中。当前的 Process Server 版本 支持迁移到远程位置。只能把单独的配置文件迁移到远程位置。下面几小节提供更多信息。

安装 WebSphere Process Server V7.0.0 Fix Pack 1

在这个迁移实验中,源环境中的 Dmgr01 配置文件迁移到目标环境中的 Dmgr01 配置文件。这在 Windows1 服务器上执行。源环境中的 Custom01 配置文件迁移到 Windows1 服务器上目标环境中的 Custom01 配置文件。同样,源环境中的 Custom02 配置文件迁移到 Windows2 服务器上目标环境中的 Custom02 配置文件。后面的小节提供详细信息。

按照 Installing and configuring WebSphere Process Server 提供的说明在 Windows1 和 Windows2 服务器上安装 Process Server V7.0.0.0。按照 Technote: WebSphere Process Server V7.0.0 Fix Pack 1 (V7.0.0.1) 提供的说明应用 Fix Pack 1。该补丁包应当使用 Installation Manager 安装。在安装期间不要创建任何配置文件。我们将在迁移过程中创建目标配置文件。这样目标环境就准备好了。


在部署管理器上执行迁移

在迁移部署管理器配置文件期间,应用程序(用户应用程序、系统应用程序、支持应用程序、样例应用程序)和部署环境配置数据(集群、JMS 资源、WPSMgEnv 的数据库资源))都被转换并复制到目标配置文件。目标配置文件是在 <WPS7.0.0.1_home> 中创建的部署管理器。

表 1. 部署管理器迁移
源配置文件目标配置文件位置
<WPS6.2.0.2_home>
/profiles/Dmgr01
<WPS7.0.0.1_home>
/profiles/Dmgr01
Windows1 服务器

必须在迁移托管节点之前迁移部署管理器。使用迁移向导对部署管理器执行迁移。在本小节中,Process Server V6.2.0.2 中的 Dmgr01 配置文件迁移到 Process V7.0.0.1 中的 Dmgr01 配置文件(参见表 1)。

对部署管理器执行迁移的步骤如下:

  1. 通知源环境上的所有节点代理和服务器。使用管理控制台停止 WPSMgEnv 部署环境。这一行为将停止所有集群。此后,停止所有节点代理。
  2. 在 Windows1 服务器上,导航到 <WPS6.2.0.2_home>/profiles/Dmgr01/bin/ 目录。
  3. 通过发出 stopManager.bat 命令停止部署管理器。
  4. 导航到 <WPS7.0.0.1_home>/bin/ 目录并通过发出 BPMMigrate.bat 调用迁移向导。该工具将打开 Migration Wizard,如图 9 所示。单击 Next 按钮。
    图 9. 迁移向导
    迁移向导d
  5. 在下一个屏幕中,通过单击相应的单选按钮来选择 Custom migration,如图 10 所示。
    图 10. 选择 Custom migration 选项
    选择 Custom migration 选项
  6. 迁移工具列出 Windows1 服务器上安装的所有以前版本的 Process Server。在列表中选择 V6.2.0.2 并单击 Next 按钮(如图 11 所示)。这就是在其中配置了源环境的安装。
    图 11. 以前版本的 Process Server
    以前版本的 Process Server
  7. 在下一个屏幕中选择要迁移的配置文件。因为要对部署管理器配置文件执行迁移,选择 Dmgr01 并单击 Next 按钮,如图 12 所示。同样,为部署管理器提供用户名和密码。
    图 12. 源配置文件选择
    源配置文件选择
  8. 如图 13 所示,在文件系统上为 snapshot 目录提供一个目录。迁移向导首先在这个目录中获取部署管理器配置文件的快照。随后,该目录中的数据将被用于实际的迁移。迁移向导在迁移过程中还将在此目录中创建各种日志和跟踪文件。您将为每个配置文件的迁移提供不同的目录,这样就可以更好地独立监视每个配置文件的迁移。提供了 snapshot 目录后,单击 Next 按钮。
    图 13. Snapshot 目录
    Snapshot 目录
  9. 为目标配置文件和将在其中创建目标配置文件的目录提供名字,如图 14 所示。单击 Next 按钮。
    图 14. 目标配置文件的名称
    目标配置文件的名称注意有关创建目标配置文件的限制:在 Process Server V7.0 中,我们不允许迁移到使用 PMT 创建的现有目标部署管理器中。如果希望提前创建目标配置文件,那么使用命令行实用工具 BPMCreateTargetProfile 来从 snapshot 目录创建配置文件,并使用命令行实用工具 BPMMigrateProfile 来迁移配置文件。有关更多信息,请参见 使用 BPM 命令行实用工具迁移配置文件
  10. 选择应用程序迁移设置,如图 15 所示。单击 Next 按钮。
    图 15. 应用程序迁移设置
    应用程序迁移设置
  11. 选择脚本兼容性设置,如图 16 所示,然后单击 Next 按钮。
    图 16. 脚本兼容性设置
    脚本兼容性设置
  12. 图 17 显示了迁移活动的摘要,迁移活动将要开始。通过单击 Next 按钮,部署管理器配置文件的迁移就要开始。
    图 17. 迁移活动的摘要
    迁移活动的摘要
  13. 源配置文件的迁移包含三个按以下顺序执行的步骤:
    1. 将源配置文件的备份放到 snapshot 目录。在内部,将执行以下命令来获取源环境中的 Dmgr01 配置文件的快照:
      C:\ibm\WPS7.0\bin\BPMSnapshotSourceProfile.bat C:\ibm\WPS6.2 Dmgr01 
      C:\MigrationSnapshots\WPS6.2\Dmgr01
    2. 在目标环境中创建目标配置文件。在内部,将执行以下命令来在目标环境中创建目标配置文件:
      C:\ibm\WPS7.0\bin\BPMCreateTargetProfile.bat 
       -targetProfileName Dmgr01  
       -targetProfileDirectory  
       C:\ibm\WPS7.0\profiles\Dmgr01  
       C:\MigrationSnapshots\WPS6.2\Dmgr01     
       Dmgr01
    3. 将源配置文件迁移到目标配置文件。在内部,执行下面的命令来将源配置文件迁移到目标配置文件:
      C:\ibm\WPS7.0\bin\BPMMigrateProfile.bat 
       -username admin -password ******** 
       -targetProfileName Dmgr01                   
       C:\MigrationSnapshots\WPS6.2\Dmgr01 
       Dmgr01
    图 18 展示了所有这三个步骤,其中第一个步骤已经开始执行。
    图 18. 迁移执行
    迁移执行
  14. 步骤 13a 在 snapshot 目录的 logs 子目录创建以下日志和跟踪文件(图 19)。可以查看这些日志来监视获取快照行为的过程。log.lck 文件是一个 lock 文件,用于表示一个行为的实例,该行为获取正在运行的 Dmgr01 配置文件的快照。这种机制可以防止不同的用户意外启动多个快照行为。
    图 19. 为快照行为创建的日志
    为快照行为创建的日志
  15. 完成步骤 13a 后,屏幕表示步骤 13b 已启动。在这个步骤中,目标配置文件将在目标环境中创建,如图 20 所示。
    图 20. 创建目标配置文件
    创建目标配置文件
  16. 和步骤 13a 相同,这个步骤也创建了日志和跟踪文件,如图 21 所示。这些文件在 snapshot 目录的 logs 子目录中创建。注意,在创建配置文件时,还将在目录环境中创建日志或跟踪文件。这些文件在 <WPS7.0.0.1_home>/logs/manageprofiles 目录中创建。查看这些文件,看看创建配置文件的过程中是否生成任何错误。
    图 21. 在创建目标配置文件时生成的日志
    在创建目标配置文件时生成的日志
  17. 完成步骤 13b 后,屏幕显示步骤 13c 已经开始执行。在这个步骤中,将执行工件从 snapshot 目录到新建的目标配置文件的实际迁移,如图 22 所示。
    图 22. 迁移 Dmgr01 配置文件
    迁移 Dmgr01 配置文件
  18. 和前面的步骤一样,这个步骤中创建的日志和跟踪文件也在 snapshot 目录的 logs 子目录中创建,如图 23 所示。查看这些日志文件,看看是否出现错误。
    图 23. Dmgr01 迁移过程中创建的日志文件
    Dmgr01 迁移过程中创建的日志文件
  19. 当成功完成所有三个步骤后,屏幕将显示对 Dmgr01 的迁移已经完成,如图 24 所示。单击 Next 按钮并关闭迁移向导。
    图 24. 成功完成 Dmgr01 配置文件的迁移
    成功完成 Dmgr01 配置文件的迁移
  20. 除了以上的日志文件外,有关迁移向导内发生的任何错误的消息都被记录到一个单独的日志文件中。该日志文件在 <WPS7.0.0.1_home>/logs/bpm_migration 目录中创建,如图 25 所示。查看迁移向导中出现的错误,并将它们报告给支持团队。
    图 25. 迁移向导 GUI 日志文件
    迁移向导 GUI 日志文件
  21. 公用数据库迁移:作为部署管理器配置文件迁移的一部分,下一步是将公用数据库模式升级到 Process Server V7.0,然后再在目标环境中启动它。如果针对数据源定义的数据库用户没有足够的授权来修改数据库模式,那么您必须进行手动升级。
    1. 您将使用 upgradeSchema.bat 手动升级公用数据库模式。upgradeSchema.bat 是一个命令行工具,可以以交互方式运行来升级公用数据库。该工具的位置是 <WPS7.0.0.1_home>dbscripts/CommonDB/DB2。注意,如果 DB2 被安装在一个远程机器中,那么您需要将该文件夹的内容复制到远程机器上。
    2. 当这个工具在运行时,它将向用户提出一些问题,以捕捉有关源环境的信息。图 26 展示了运行此工具来升级数据库的命令窗口。从用户那里捕捉到 dbUserId 信息后,将打开一个新的命令窗口并提示输入密码。输入密码后,将升级公用数据库。注意 dbUserid 具有足够的权限来执行数据库模式升级。
      图 26. CommonDB 模式升级
      CommonDB 模式升级
  22. 对公用数据库执行升级后,在目标环境中启动部署管理器。检查日志中的错误。这将完成 Dmgr01 配置文件的迁移。

有关对目标 Dmgr01 配置文件执行备份的注意事项

现在应该备份新的部署管理器。如果出现定制节点失败,可以恢复新的部署管理器。在不恢复部署管理器的情况下,不要 尝试多次迁移节点。


在托管节点上执行迁移

在迁移托管节点配置文件期间,把源配置文件中与服务器相关的配置转换和复制到目标环境中的配置文件(表 2)。

表 2. 托管节点迁移
任务源配置文件目标配置文件位置
1<WPS6.2.0.2_home>/ profiles/Custom01<WPS7.0.0.1_home>/ profiles/Custom01Windows1 服务器
2<WPS6.2.0.2_home>/ profiles/Custom02<WPS7.0.0.1_home>/ profiles/Custom02Windows2 服务器

在本节中,您将执行下面这些任务:

对 Windows1 服务器中的 Custom01 配置文件执行迁移

下面的步骤将对 Windows1 服务器中的 Custom01 配置文件执行迁移。参考 表 2 的步骤 1。该任务类似于前面描述的部署管理器配置文件的迁移。然而,我们将提供完整的步骤来执行托管节点的迁移,并重点展示两者之间的差别。该任务将执行以下操作:

  1. 在 snapshot 目录中获得 Custom01 配置文件的快照。
  2. 在 Windows1 服务器上,在目标环境中创建一个新的 Custom01 配置文件。
  3. 从源环境的 Custom01 配置文件中,将配置数据复制并转换到目标环境的 Custom01 配置文件中。
  4. 从运行在目标环境中的 Dmgr01 执行自动同步。

执行迁移的步骤为:

  1. 确保目标环境中的部署管理器正在运行,源环境中的节点代理停止。
  2. 导航到 <WPS7.0.0.1_home>/bin/ 目录,通过发出 BPMMigrate.bat 调用迁移工具。该工具将打开迁移向导,如图 27 所示。单击 Next 按钮。
    图 27. 迁移向导
    迁移向导
  3. 如图 28 所示,选择 Custom migration 并单击 Next 按钮。
    图 28. 选择 Custom 迁移选项
    选择 Custom 迁移选项
  4. 迁移工具列出 Windows1 服务器上 Process Server 的早期版本的所有安装。在列表中选择 V6.2.0.2,如图 29 所示,然后单击 Next 按钮。这是在其中配置了源环境的安装。
    图 29. Process Server 的早期版本
    Process Server 的早期版本
  5. 在下一个屏幕中选择要进行迁移的配置文件。由于您是在 Custom 配置文件之上执行迁移,因此选择 Custom01 并单击 Next 按钮,如图 30 所示。同样,为部署管理器提供用户名和密码。
    图 30. 选择源配置文件
    选择源配置文件
  6. 如图 31 所示,在文件系统上为 snapshot 目录提供一个目录。首先,迁移向导在这个目录中获取 Custom01 配置文件的快照。随后,该目录中的数据将被用于实际的迁移。迁移向导在迁移过程中还将在此目录中创建各种日志和跟踪文件。您将为每个配置文件的迁移提供不同的目录,这样就可以更好地独立监视每个配置文件的迁移。提供了 snapshot 目录后,单击 Next 按钮。
    图 31. Snapshot 目录
    Snapshot 目录
  7. 为目标配置文件和将在其中创建目标配置文件的目录提供名称,如图 32 所示。单击 Next 按钮。
    图 32. 目标配置文件的名称
    目标配置文件的名称
  8. 图 33 显示了迁移活动的摘要,迁移活动将要开始。通过单击 Next 按钮,Custom01 配置文件的迁移将要开始。
    图 33. 迁移活动的摘要
    迁移活动的摘要
  9. 源配置文件的迁移包含以下三个步骤:
    1. 将源配置文件的备份放到 snapshot 目录。在内部,将执行以下命令来获取源配置文件的快照:
      C:\ibm\WPS7.0\bin\BPMSnapshotSourceProfile.bat 
      C:\ibm\WPS6.2 Custom01 
      C:\MigrationSnapshots\WPS6.2\Custom01
    2. 在目标环境中创建目标配置文件。在内部,将执行以下命令来在目标环境中创建目标配置文件:
      C:\ibm\WPS7.0\bin\BPMCreateTargetProfile.bat 
      -targetProfileName Custom01 -targetProfileDirectory 
      C:\ibm\WPS7.0\profiles\Custom01 
      C:\MigrationSnapshots\WPS6.2\Custom01 Custom01
    3. 将源配置文件迁移到目标配置文件。在内部,执行下面的命令来迁移源配置文件:
      C:\ibm\WPS7.0\bin\BPMMigrateProfile.bat -username admin 
      -password ******** -targetProfileName Custom01 
      C:\MigrationSnapshots\WPS6.2\Custom01 Custom01
    图 34 展示了所有这三个步骤,其中第一个步骤已经开始执行。
    图 34. 迁移执行
    迁移执行
  10. 步骤 9a 在 snapshot 目录的 logs 子目录创建以下日志和跟踪文件。可以查看这些日志来监视获取快照行为的过程。log.lck 文件是一个 lock 文件,用于表示一个行为的实例,该行为获取正在运行的 Dmgr01 配置文件的快照(图 35)。这种机制可以防止不同的用户意外启动多个快照行为。
    图 35. 为快照行为创建的日志
    为快照行为创建的日志
  11. 完成步骤 9a 后,屏幕表示步骤 9b 已启动。在这个步骤中,目标配置文件将在目标环境中创建,如图 36 所示。
    图 36. 创建目标配置文件
    创建目标配置文件
  12. 与步骤 9a 相同,这个步骤也创建了日志和跟踪文件,如图 37 所示。这些文件在 snapshot 目录的 logs 子目录中创建。注意,在创建配置文件时,还将在目录环境中创建日志或跟踪文件。这些文件在 <WPS7.0.0.1_home>/logs/manageprofiles 目录中创建。查看这些文件,看看创建配置文件的过程中是否生成任何错误。
    图 37. 在创建目标配置文件时生成的日志
    在创建目标配置文件时生成的日志
  13. 完成步骤 9b 后,屏幕显示步骤 9c 已经开始执行。在这个步骤中,将执行工件从 snapshot 目录到新建的目标配置文件的实际迁移,如图 38 所示。在执行此步骤期间,迁移过程将执行下面的任务:
    1. 修改位置属性。
    2. 连接到部署管理器并修改主存储库上的节点信息。
    3. 安装新的系统应用程序,如果需要的话。
    图 38. 迁移 Custom01 配置文件
    迁移 Custom01 配置文件
  14. 和前面的步骤一样,这个步骤中创建的日志和跟踪文件也在 snapshot 目录的 logs 子目录中创建。如图 39 所示。查看这些日志文件,看看是否出现错误。
    图 39. 在 Custom01 迁移过程中创建的日志文件
    在 Custom01 迁移过程中创建的日志文件
  15. 最后一步,迁移向导将同步目标 Custom01 配置文件和运行中的部署管理器。在部署管理器(主存储库)中所做的修改将被同步到本地存储库。同步步骤也将在 logs 子目录中创建一个日志文件,如图 40 所示。
    图 40. SyncNode 日志文件
    SyncNode 日志文件
  16. 当成功完成所有三个步骤后,屏幕将显示对 Dmgr01 的迁移已经完成,如图 41 所示。单击 Next 按钮并关闭迁移向导。这将完成 Windows1 服务器上的 Custom01 配置文件的迁移。
    图 41. 成功完成 Dmgr01 配置文件的迁移
    成功完成 Dmgr01 配置文件的迁移
  17. 除了以上的日志文件外,有关迁移向导内发生的任何错误的消息都被记录到一个单独的日志文件中。该日志文件在 <WPS7.0.0.1_home>/logs/bpm_migration 目录中创建。查看迁移向导 GUI 工具中出现的错误,并将它们报告给支持团队。
  18. 如果在执行 Custom01 配置文件迁移的过程中遇到意外错误,并且错误无法修复,那么您需要删除目标环境中的 Custom01 配置文件,在目标环境中恢复已备份的 Dmgr01 配置文件,并再次执行 Custom01 的迁移。请参考 图 8 中的步骤 8。

有关在迁移 Custom01 之后备份目标 Dmgr01 配置文件的注意事项

node1 的迁移是完整的,因此您现在需要备份目标部署管理器。您可以恢复部署管理器,以从发生故障的 Custom2 节点执行回滚。在不恢复部署管理器的情况下,不要 尝试多次迁移节点。

对 Windows2 服务器中的 Custom02 配置文件执行迁移

按以下步骤迁移 Windows2 服务器中的 Custom02 配置文件。参考 表 2 中的任务 2。

这个任务执行以下操作:

  1. 在 snapshot 目录获取 Custom02 配置文件的快照。
  2. 在 Windows1 服务器上,在目标环境中创建一个新的 Custom02 配置文件。
  3. 把源环境中的 Custom02 配置文件中的配置数据复制并转换到目标环境中的 Custom02 配置文件。
  4. 从目标环境中运行的 Dmgr01 中执行自动同步。

执行迁移的步骤如下。这些步骤与 Windows1 服务器上 Custom01 配置文件的迁移步骤相似。这里只提及有差异的步骤。

  1. 确保目标环境中的部署管理器正在运行,节点代理停止。
  2. 导航到 <WPS7.0.0.1_home>/bin/ 目录并通过发出 BPMMigrate.bat 调用迁移工具。这将打开迁移向导。
  3. 在 Source profile selection 屏幕中,选择 Custom02 配置文件作为源配置文件。为部署管理器提供用户名和密码(图 42)。
    图 42. Source profile selection
    Source profile selection
  4. 在迁移向导要求给出 snapshot 目录的屏幕中,提供一个位于文件系统中的目录,如图 43 所示。迁移向导首先在这个目录中获取 Custom02 配置文件的快照。随后,该目录中的数据将被用于实际的迁移。迁移向导在迁移过程中还将在此目录中创建各种日志和跟踪文件。我们将为每个配置文件的迁移提供不同的目录,这样就可以更好地独立监视每个配置文件的迁移。
    图 43. Snapshot 目录
    Snapshot 目录
  5. 在迁移向导要求输入目标配置文件的名称的屏幕中,为目标配置文件和将在其中创建目标配置文件的目录提供名称,如图 44 所示。
    图 44. Target profile details
    Target profile details
  6. 与前面所示的 Windows1 服务器上的 Custom01 配置文件的迁移相同,迁移工具将执行对 Custom0 配置文件的迁移。它还将在迁移的每个步骤中创建相应的日志文件。查看这些日志文件中的错误。这将完成 Custom0 配置文件的迁移。
  7. 如果在执行 Custom02 配置文件迁移的过程中遇到意外错误,并且错误无法修复,那么您需要删除目标环境中的 Custom02 配置文件,在目标环境中恢复已备份的 Dmgr01 配置文件,并再次执行 Custom02 的迁移。请参考 图 8 的步骤 13。

对集群执行迁移

当环境中包含集群时,需要执行额外的迁移步骤。我们在源环境中创建了以下集群:

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

以上所有这些集群分别将它们的成员分布在 Windows1 和 Windows2 服务器上的 Custom01 和 Custom02 配置文件中。作为迁移过程的一部分,BPMMigrateCluster.bat 必须在每一个集群中运行,以执行集群级别的迁移。这将在集群范围内转换或修改配置数据。

有关集群迁移的注意事项

  • 在新的部署管理器配置文件所在的机器上执行这些步骤。
  • 使用部署管理器迁移期间使用的备份目录。

这个任务包含以下步骤:

  1. 导航到 Windows1 服务器上的 <WPS7.0.0.1_home>/bin 目录,并发出以下命令:
    1. BPMMigrateCluster.bat
      C:\MigrationSnapshots\WPS6.2\Dmgr01 WPSMgEnv.Messaging
      Dmgr01
    2. BPMMigrateCluster.bat
      C:\MigrationSnapshots\WPS6.2\Dmgr01 WPSMgEnv.Support
      Dmgr01
    3. BPMMigrateCluster.bat
      C:\MigrationSnapshots\WPS6.2\Dmgr01 WPSMgEnv.AppTarget
      Dmgr01
  2. 在以上命令中,C:\MigrationSnapshots\WPS6.2\Dmgr01 是在迁移 Dmgr01 配置文件时指定的 snapshot 目录。
  3. 在运行以上命令时,在 snapshot 目录的 logs 子目录中为每个命令创建一个日志文件和一个跟踪文件,如图 45 所示。检查日志文件,确保没有错误发生。
    图 45. 集群迁移日志
    集群迁移日志
  4. 从 Window1 服务器的 <WPS7.0.0.1_home>/profiles/Custom01/bin 目录中运行 syncNode.bat 命令。类似地,从 Windows2 服务器的 <WPS7.0.0.1_home>/profiles/Custom02/bin 目录运行 syncNode.bat 命令。这一步骤将 Dmgr01 中的更改同步到集群中,如图 46 所示。
    图 46. 集群迁移后的 syncNode
    集群迁移后的 syncNode
  5. 在完成下一步之前不要 启动集群成员。

对 Business Process Choreographer 数据库手动执行迁移

在本节中,您将升级 Business Process Choreographer 数据库。这个过程涉及两个任务:

源环境使用 BPEDB 数据库存储与 BPEL 和人工任务相关的数据。在启动 WPSTestEnv.AppTarget 集群的任何集群成员之前,需要迁移 BPEDB 数据库。

升级 Business Process Choreographer 数据库模式

第一个任务是升级数据库模式。以下步骤将描述升级数据库模式的过程:

  1. 将以下文件复制到一个临时目录,例如 C:\temp
    <WPS7.0.0.1_home>/ profiles\Dmgr01\dbscripts\
     ProcessChoreographer\DB2\BPEDB\<schema_name>/ 
     createSchema.properties
  2. 打开一个命令提示并导航到一个临时目录,然后在复制的文件中运行以下命令:
    <WPS7.0.0.1_home>\util\dbUtils\DbDesignGenerator.bat -e createSchema.properties
  3. DbDesignGenerator.bat 是 Process Server 中的数据库设计工具,它创建数据库设计文件并生成数据库脚本。这是 Process Server V7.0 中引入的 工具,可以帮助您为 Process Server 所使用的各种数据库生成脚本。
  4. 以上命令在交互模式下打开,并提示用户提供输入。提供如表 3 所示的值。在完成该行为后,数据库设计工具将为 BPEDB 数据库生成定制的数据库设计文件。
表 3. DBDesignGenerator 的命令行参数
数据库类型 DB2-distributed
场景 Migration
数据库名 BPEDB
地区 Us-en
数据库模式名 WPRBE00
使用表空间 false
表空间目录 / 容器路径 <default>
审计日志项的表空间
<default>
审计日志项的表空间
实例项的表空间
scheduler 项的表空间
员工查询项的表空间
模板项的表空间
工作项表的表空间
<default>
数据源属性 Skip
是否希望将修改保存到相同的文件?Yes
  1. 对定制的数据库设计文件运行数据库设计工具,生成升级后的脚本:
    <WPS7.0.0.1_home>\util\dbUtils\DbDesignGenerator.bat 
    -g createSchema.properties -d <output_directory>
  2. 以上命令将生成将在 BPEDB 数据库上运行的数据库脚本,这些脚本可以升级 <output_directory> 中的模式。由于您从 Process Server V6.2.0.2 迁移,因此在 BPEDB 上运行生成的 upgradeSchema620.sql 文件来升级模式。这将完成 BPEDB 模式的升级。对于在使用数据库设计工具时的各种选项,请参考 升级 Business Process Choreographer 数据库模式

迁移 Business Process Choreographer 运行时数据

由于您是从 Process Server V6.2.0.2 迁移的,因此不必使用 MigrateDB.py 脚本来迁移运行时数据。这一步骤只适用于从早于 V6.2.x 的版本开始迁移的情况。有关更多细节,请参考 迁移 Business Process Choreographer 数据库数据

第二个任务是升级 BPEDB 的运行时数据。这会迁移与源环境中运行的 BPEL 和人工任务实例相关的数据。迁移运行时数据让这些实例在迁移之后仍然是有效的。在迁移之后,用户可以在目标环境中处理这些实例。完成这个步骤所需的时间取决于数据库内容。参见 技术说明:补充的数据迁移文档

有关 Business Space 数据库迁移的注意事项

如果您在 Process Server V6.2.0.2 中配置了 Business Space,那么您需要升级 Business Space 数据库模式并迁移运行时数据。下面的链接将解释这个过程:

在完成迁移之后且在启动集群成员之前,应当从其中一个节点只运行一次 运行时数据的迁移

Business Process Choreographer 数据库和 Business Space 数据库都在集群范围内配置,而公用数据库则在 cell 范围内配置。


迁移后活动和检查

在本节中,要检查目标环境,检查迁移过程是否成功地在目标环境中创建了对应的对象。在目标环境中检查以下方面:

  • 是否正确地创建了配置文件。
  • 是否迁移了部署环境。
  • 是否迁移了用户应用程序和支持应用程序。
  • 是否把源环境中生成的失败事件迁移到了目标环境中。
  • 是否把未完成的 BPEL 和人工任务实例迁移到了目标环境中。

如果在源环境中使用了特殊的配置设置,那么需要执行迁移后任务。这些任务在 迁移后任务 中做了解释。

按照下面的步骤执行以上任务:

  1. 在目标环境中重新启动部署管理器,并启动所有节点代理和集群。
  2. 打开管理控制台,观察源环境是否被按原样迁移到目标环境。cell 拓扑与源环境的拓扑完全相同,如图 47 所示。
    图 47. 目标环境中的 Cell 拓扑
    目标环境中的 Cell 拓扑
  3. 检查集群成员是否在所有集群中创建,如图 48 所示。
    图 48. 目标环境中的集群成员
    目标环境中的集群成员
  4. 检查部署环境 WPSMgEnv 是否成功启动,如图 49 所示。
    图 49. 部署环境
    部署环境
  5. 如果存在旧的预定义人工任务应用程序的运行实例,那么在迁移期间它们不会被卸载。这意味着在完成迁移后,预定义人工任务应用程序的新旧版本都会并存于您的系统中。确保所有旧实例已经被删除。在管理控制台中,单击 Applications > Application Types > WebSphere enterprise applications。如果出现以下任意应用程序的多个版本,选择较旧的版本并单击 Uninstall
    HTM_PredefinedTasks_Vnnn_scope.ear 
    HTM_PredefinedTaskMsg_Vnnn_scope.ear
    nnn 是应用程序在最近一次更新后的版本号,例如 620。如果这些应用程序的最新版本要比当前版本还旧,那么意味着它没有被修改过。如果两个应用程序有多个版本,那么必须只删除最旧的那个版本。
    图 50. 检查企业应用程序
    检查企业应用程序
  6. 在浏览器窗口中打开 BPC Explorer 并单击 My To-dos 链接来查看已迁移的人工任务。这些人工任务在源环境中启动,并且保持在运行状态,如图 51 所示。
    图 51. 人工任务的运行时迁移
    人工任务的运行时迁移
  7. 完成以上人工任务并单击 Process instances 链接来观察位于 “finished” 状态的所有过程实例。源环境中已经完成了两个实例,其余两个实例在目标环境中完成,如图 52 所示。
    图 52. 目标环境中的过程实例
    目标环境中的过程实例
  8. 在浏览器窗口中打开管理器控制台并单击导航树下的 Integration Applications 中的 Failed Event Manager 链接。这将打开失败的事件管理器应用程序。单击 Get all failed events 链接,列出失败的事件。这些失败的事件在源环境中生成,并且数据在公用数据库迁移期间被迁移到目标环境。如图 53 所示。
    图 53. 目标环境中失败事件的迁移
    目标环境中失败事件的迁移

结束语

本教程详细描述了从 WebSphere Process Server V6.2.0.2 到 V7.0.0.1 的迁移过程。其中涉及配置数据、应用程序数据和数据库数据的迁移,这些迁移按照指定的顺序执行。本教程还提供了各种子任务的细节,以及在哪里可以找到有助于故障排除的迁移日志文件。通过强调管理员需要特别注意的步骤,帮助他们避免丢失宝贵的业务数据,这次迁移实践提供了对迁移过程的清晰了解。


下载

描述名字大小
EAR 文件EAR_file_samples.zip90KB

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=495169
ArticleTitle=迁移到 WebSphere Process Server Version 7
publish-date=06102010