内容


WebSphere Portal 8.0 的新特性 —— 全新的配置向导助手

Comments

WebSphere Portal 配置向导的背景介绍

WebSphere Portal 里的配置向导一向是用户所喜爱的工具,它可以帮助用户简化配置过程,原本需要用户自己手工修改配置文件中的大量配置参数,现在只需要跟随配置向导一步一步填写简单的信息就行了。简单来说配置向导主要是从几个方面来简化配置流程的:

  1. 针对用户所要完成的任务,配置向导将此任务所有相关的配置参数都挑选了出来,并按照它们之间的关系分组放在不同的步骤中。这样避免了让用户自己从纷杂的上百个配置参数判断哪些参数是需要修改,哪些参数是无关的不应该修改。使用了配置向导之后,用户从此不用再担心漏填了必备参数。
  2. 配置向导会根据用户在上一步填写的信息来过滤下一步里所需要填写的配置参数。例如,如果用户在数据库迁移的任务中选择了目标数据库类型是 DB2,那么接下来的步骤中就会将其他数据库类型的配置参数都过滤掉,无需用户填写。并且,配置向导还会针对每个配置参数提供默认值以及帮助信息,方便用户来填写。

配置向导的运行环境介绍

在 WebSphere Portal 8.0 之前的版本里,配置向导是一个运行在 WebSphere Portal 所在的服务器上的 Java 客户端程序,是基于 InstallShield 安装配置向导来实现的,主要提供了对数据库迁移以及配置安全性任务的支持。在 WebSphere Portal 8.0 里,配置向导有了全新的升级,不仅仅运行方式上从 Java 客户端程序转向了基于 Dojo 的 Web 应用,而且扩展性也大大增强,所覆盖的配置任务也因此可以极大丰富了。我们知道,Web 应用自然是运行在 Web 服务器上的;同样,我们的配置向导也是运行在 WebSphere 这个应用服务器上。有人可能看到这里会有疑问了,在常用的配置任务中,经常需要重启 WebSphere 应用服务器来使修改的配置生效(例如,在给 WebSphere Portal 配置安全性时,就需要重启 WebSphere 才能使新的安全性生效),那么在这种时候,我们的配置向导不就被中断了么?我们通过配置向导所执行的配置任务从而也就被中断了,从而无法完成了,不是么?还有的人可能会有其他的担心,在集群环境中每个 WebSphere 节点都是由部署管理器(Deployment Manager)来管理的,每个 WebSphere 自身的管理控制台是无法访问的,那这时候自然配置向导也就无法访问了,这种情况该怎么处理呢?

针对上面的问题,我们来了解一下配置向导的体系框架。首先,它是作为集成解决方案控制台(Integrated System Console,缩写为“ISC”)的一个扩展模块部署在 WebSphere 应用服务器上面的。其次,我们在 WebSphere 里为配置向导创建了其专属的概要(Profile),这个概要的名字就叫 "cw_profile"。这个概要的运行及它的安全性是完全独立的,因此更改 WebSphere Portal 的安全性等配置任务完全不会影响到这个概要的运行,我们的配置向导因此也就始终保持运行,能够完整的完成各种配置任务了。最后,虽然配置向导缺省部署在 WebSphere Portal 所在的机器上,但是我们依然能够将它部署到其他机器的 WebSphere 或者部署管理器上。这样,我们保证了配置向导的完全独立运行,不受任何其他因素的影响。关于如何将配置向导部署到其他机器的相关步骤可以在 WebSphere Portal 8.0 的信息中心中找到,这里就不赘述了。

图 1. 集成解决方案控制台中的配置向导
图 1. 集成解决方案控制台中的配置向导
图 1. 集成解决方案控制台中的配置向导

配置向导的三大全新功能

在全新的配置向导中,所包含的功能也比之前版本有了极大的改善。简单来说可以分为三大新功能:从 Web 界面运行 ConfigEngine 任务,查看系统日志,工作流程。前两个功能可以看作是对现有 ConfigEngine 的功能补充,最后的工作流程功能才是配置向导的重点所在。下面我们来逐个看看每块功能中包含的内容。

从 Web 界面运行 ConfigEngine 任务

我们知道,WebSphere Portal 中的所有配置任务最终都是通过 ConfigEngine 这个命令行工具来执行的,而所有的配置任务也都是基于 ConfigEngine 来实现的 ANT 任务。通常来说我们都是通过登录安装有 WebSphere Portal 的远程机器,在上面通过命令行方式运行 ConfigEngine 任务的。现在,配置向导移到了 Web 端之后,运行一些简单的 ConfigEngine 任务完全可以通过配置向导的这项功能从 Web 端来提交,免去了登录远程机器的过程。

图 2. 从 Web 界面运行 ConfigEngine 任务
图 2. 从 Web 界面运行 ConfigEngine 任务
图 2. 从 Web 界面运行 ConfigEngine 任务

从上图可以看出,在 Web 端运行 ConfigEngine 任务是十分简单的,主要需要用户提供希望运行的任务名以及相关的特性值即可。这项功能其实更主要的是提供了一种替代命令行的运行方式,而不是继承以前版本中配置向导的功能。真正强大的向导功能将会在后面的工作流程小节中详细介绍。

在上图中同样可以看出,我们在允许用户点击“立即运行任务”之前会在后台检查 ConfigEngine 的状态,这是因为 ConfigEngine 不支持并发执行多任务,所以我们需要避免用户提交了任务之后才发现 ConfigEngine 已处于运行中状态。如果当前 ConfigEngine 处于可用状态,那么用户就可以立即运行任务,在任务提交后,页面将会实时显示后台的运行进度及日志中的输出结果直至任务运行完毕。在这里同时提供了其他两个选项:“首选项设置”和“创建脚本”。“首选项设置”主要是可以让用户修改缺省的 WebSphere Portal 安装路径,放置临时文件的路径等信息。而“创建脚本”则提供了打包功能,将用户输入的任务及特性值生成可执行的脚本文件和属性文件并提供下载。用户可以保存这些打包的文件,在需要运行的时候只需要简单的运行一下里面的可执行脚本文件即可,而无需重新输入这些任务名及特性值。当 ConfigEngine 被锁定的状态下导致无法立即运行,或者将来希望重复利用这些脚本的时候都可以使用这个功能来延时完成配置任务。

需要注意的是,从 Web 端运行 ConfigEngine 任务仅限于配置向导与所管理的 WebSphere Portal 安装在同一台机器上。如果配置向导被部署在了其他机器的 WebSphere 或者部署管理器上,是不能使用这项功能的。

系统日志管理功能

有过 ConfigEngine 和 WebSphere Portal 使用经验的用户可能知道,一般来说有两个日志文件在我们的配置管理过程当中十分重要:SystemOut.log 和 ConfigTrace.log。SystemOut.log 文件包含了 WebSphere Portal 自身输出的各种日志信息;而 ConfigTrace.log 则包含了 ConfigEngine 运行中输出的所有日志信息。在新版本的配置向导中,我们提供了一个强大的故障诊断工具,此工具使故障诊断工作 不再令人生畏。 日志查看器在易于追踪的界面中选择想要查看的日志文件, 在此界面中,您只需进行一次单击即可找到日志文件中的错误。需要注意的是,这里的日志文件里不止包含了通过命令行方式执行的 ConfigEngine 所输出的日志,也包含了通过 Web 端执行 ConfigEngine 任务和后面将要介绍的用工作流程执行时所输出的日志信息。

图 3. 使用系统日志管理来查看 ConfigTrace.log
图 3. 使用系统日志管理来查看 ConfigTrace.log
图 3. 使用系统日志管理来查看 ConfigTrace.log

从上图中可以看出,以前查看 ConfigTrace.log 时需要在庞大的文件中手工定位要查找的任务,逐行找出报错的地方。现在所有执行过的任务以列表的形式显示,而且执行成功与否一目了然,很方便就能找到出错的日志信息。

强大的工作流管理功能

如果说以上两个功能都是对现有 ConfigEngine 功能的有效补充,那么工作流程则是配置向导的拳头功能了。什么是工作流程呢?简单来说就是如果有一个或多个配置任务,组合起来能达到最终的配置效果,我们就可以把它组织成单一流程。这样可以节省您的宝贵时间,并可以使用现成的工作流程为配置方案生成定制脚本。一个典型的例子就是为 WebSphere Portal 搭建集群环境,这个工作流程中包含了很多步骤,需要执行多个 ConfigEngine 任务才能够完成集群的搭建。在 WebSphere Portal 8.0 的配置向导中,缺省包含了如下这些工作流程。

图 4. 配置向导中自带的工作流程列表
图 4. 配置向导中自带的工作流程列表
图 4. 配置向导中自带的工作流程列表

工作流模板是如何简化用户配置流程的

让我们暂时跳过工作流程是如何创建的,先来看看工作流程是怎么通过配置向导一步一步从而简原有配置过程的。首先,所有的工作流程都可以看作是一个模板,仅仅包含了框架和缺省值,用户需要定制工作流程,填入符合自己环境的各种数据来生成最终的工作流程实例,最后创建出此工作流程实例的脚本,指示信息以及所有经过更新的属性文件。用户只需要下载这个打包好的文件,按照里面提示信息的指导,逐个运行里面的脚本就能自动完成配置过程,无需再手工执行 ConfigEngine 命令或者编辑配置文件。

我们可以看一个创建静态集群环境的工作流程例子,最终的生成结果如图五所示。用户只需要打开 CreateStaticCluster.html,根据里面的指示,在相应的节点上逐个执行 Scripts 文件夹中包含的脚本文件即可。

图 5. 工作流程实例生成的脚本,指示信息以及所有经过更新的属性文件
图 5. 工作流程实例生成的脚本,指示信息以及所有经过更新的属性文件
图 5. 工作流程实例生成的脚本,指示信息以及所有经过更新的属性文件

从一个工作流程模板到最终工作流程实例生成的脚本文件,一共需要四个步骤 , 如图六所示:

图 6. 定制工作流程的四个步骤
图 6. 定制工作流程的四个步骤
图 6. 定制工作流程的四个步骤

配置向导会指引用户从步骤 1 一步一步前进直到步骤 4 生成最终的脚本文件。

  1. 设置条件:在步骤 1 中的条件包括两类,一是目标运行平台是何种操作系统,另一种就是工作流程中包含的各种条件参数。设置条件主要是为了过滤掉后续步骤中无关的配置参数。例如,在数据库迁移的工作流程中,如果用户在步骤 1 里对目标数据库类型这一条件参数选择了 DB2,那么在后继步骤中其他数据库类型的相关配置参数就会被自动过滤掉,不会显示给用户造成无谓的干扰。我们在前文中提到过,配置向导可以和 WebSphere Portal 不运行在同一台机器上,因此在这里我们需要知道目标平台的操作系统类型从而最终生成正确的脚本类型(.bat 文件或是 .sh 文件)。
  2. 定制工作流程:经过了步骤 1 的过滤,在步骤 2 里将会分组显示出需要用户按照目标环境做出相应修改的各种配置参数。而且配置向导为其中的配置参数都提供了详细的帮助信息来帮助用户填写,例如缺省值,有效格式,范例等等。
  3. 检查值:在前两步完成之后,在这里我们将所得到的各种配置参数进行各种有效性验证并提供修改的机会。
  4. 创建工作流程:在这里用户可以对工作流程实例生成最终的脚本,指示信息以及所有经过更新的属性文件。用户拿到这些文件之后就可以在目标机器上按照指示信息中的步骤来执行相应的脚本文件就行了。
图 7. 提供了详细帮助信息的配置参数页面
图 7. 提供了详细帮助信息的配置参数页面
图 7. 提供了详细帮助信息的配置参数页面

工作流中的各种术语介绍

看上去很简单,不是么?其实简单的工作流程背后有许多东西值得注意。其中就包括配置向导中涉及到的各种术语,掌握了这些术语及它们的作用可以让我们更好的了解配置向导,而且这也是将来编写你自己的工作流程时必须掌握的概念:

  • 工作流程(Workflow):一个工作流程可以包含多个任务,可以是 ConfigEngine 的任务,也可以是其他类型的任务。并且,工作流程是可以嵌套在另一个工作流程中的。例如,在创建集群环境的工作流程中其实嵌套了多个其他工作流程,包括有:安全性配置的工作流程,数据库迁移的工作流程,重启 WebSphere Portal 的工作流程等等。当用户定制创建集群环境的工作流程时,它所嵌套的子工作流程会被自动包含进来,用户可以一次性就生成最终想要的所有结果。
  • 工作流程定义(Workflow Definition):工作流程定义是作为模板提供给用户定制的,其中包含了所需的任务以及相应的配置参数和它们的缺省值。
  • 工作流程实例(Workflow Instance):工作流程实例是经过用户定制之后生成的,它包括了工作流程所需的任务以及经过用户修改过后的配置参数值。用工作流程实例就可以生成我们所需的最终脚本以相关文件。
  • 工作流程步骤(Workflow Steps):工作流程中所包含的任务。按照类别又可以分为三大类:
  • ConfigEngine 步骤(ConfigTask Step):这类任务对应的就是执行一个 ConfigEngine 命令,这也是最常见的任务类型了。
  • 其他命令步骤(Command Step):这类任务对应的是在命令行里执行其他命令,例如在配置过程中我们经常需要手工执行“ulimit -n”的命令来修改底层操作系统的最大打开文件数,工作流程中自然也需要有地方来包含这类任务。
  • 消息步骤(Info Step):这类任务主要包含一些需要用户手工完成的步骤,例如从一台机器拷贝一些文件去另一台机器。
  • 配置参数(Parameters):配置参数包括了两大类型,一类是执行 ConfigEngine 任务时所需要的存储在 wkplc*.proerties 里面的配置参数。另一类就是供工作流程内部使用的配置参数。
  • 条件参数(Condition):条件参数是非常有用的,它可以作用在很多地方,包括工作流程,工作流程步骤以及配置参数上。当用户定制工作流程时,系统会逐一判断此工作流程中所有的条件参数是否满足,如果不满足就将它对应的对象移除出去。之前我们提到过的移除不相关配置参数就是通过条件参数来实现的。
  • 工作流程存储库(Workflow Repository):工作流程存储库是一个 XML 文件,其中存储了当前包含的所有工作流程模板及所有的配置参数。在 WebSphere Portal 的信息中心中可以找到详细的信息来恢复或者重建这个存储库。

看上去这些术语有些复杂,但这些概念对于普通用户来说是完全透明的,用户完全能够只通过前面介绍的简单四步骤来定制工作流程就能够完成日常所需的工作。而对于 WebSphere Portal 开发者和服务团队来说,掌握了这些概念能够有利于他们更好的把握工作流程的内部结构,创建出高效便利的工作流程。

与他人分享工作流程

我们之前提到过新版的配置向导提供了强大的可扩展性,其体现就在于我们将不再仅限于 WebSphere Portal 缺省提供的这些工作流程,用户可以创建符合自己需求的新工作流程。并且,配置向导还提供了导入和导出工作流程的功能,这样用户可以将自己创建的工作流程与其他用户分享。所谓众人拾柴火焰高,这将极大丰富可用工作流程的种类和数量,避免了重复工作并且能极大简化日常所需的配置工作。

总结

WebSphere Portal 8.0 的配置向导作为一次全新的升级,从传统的 Java 客户端程序转向了 Web 端应用,从多方面有效补充了原有 ConfigEngine 的功能,并且引入了工作流程来简化了日常配置工作所需要的工作,用户还可以导入和导出工作流程并与他人进行分享从而扩大工作流程所覆盖的应用范围。相信在使用了新版的配置向导之后一定会大大提高用户的工作效率 , 简化配置流程 .。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Lotus, WebSphere
ArticleID=830855
ArticleTitle=WebSphere Portal 8.0 的新特性 —— 全新的配置向导助手
publish-date=08172012