portal中oracle数据库连接,Portal开发与配置技巧集锦（三）

1.

6  Portal 6.1.0.3无法查找任何用户或用户组

1.

6.1

问题描述

Portal

系统升级到

6.1.0.3

之后，无法搜索任何用户或用户组，所体现的功能模块有：

WCM

授权、

WCM

管理、

PDM

管理，凡使用到

People Picker Page

的地方，都不行。

1.

6.2

解决方案

这

是由于

Portal 6.1.0.3

的升级程序可能不慎修改了

People Picker Portlet

的属性值，导致该

Portlet

无法查找到合适的用户或用户组，我们必须手工去修正这个问题。修正该问题的步骤如下。

以

WAS

超级管理员(一般是

wpsbind

)身份登录

WAS

管理控制台。

单击

“

Resource

(资源)”→“

Resource Environment

(资源环境)”→“

Resource Environment Providers

(环境资源提供程序)”，找到“

WP PeopleService

”条目，如图

1-

26

所示。

图

1-

26  PeopleFinder

的属性缺少导致许多

Portal

版本出现人员和组织无法查找的问题

单击

“

Custom properties

(自定义属性)”，编辑如图

1-

27

所示的三个属性值。

图

1-

27

修改资源提供程序里的

PeoplePicker

属性

要确保这三个值与

LDAP

中的属性值相对应。例如：

Name

Value

pickerPeopleSearchAttribute

cn,displayName,sn,uid

pickerGroupSearchAttribute

cn,displayName,sn,givenName

configurePeoplePickerSearch

true

重启

Portal

服务器，验证是否可以正常工作。

1.

7  配置Portal 6.1使用Oracle数据库

失败

7.1

问题描述

配置

Portal 6.1.0.0

使用

Oracle

数据库并将

Portal

数据从默认数据库迁移到

Oracle

时失败。多种原因都会导致出现这个问题，但以下提到的三个问题是经常发生的，出现迁移失败时，请首先确定这个问题。

7.2

解决方案

工程师在配置过程中，以下三个问题是经常发生的，它们会导致

Oracle

数据库迁移失败。

(

1

)

Oracle

版本号不是受

Portal 6.1

支持的正确版本号，尤其是小版本号。

例如，用户安装的

Oracle

版本号是

10.2.0.0

，但是

Portal 6.1

支持的版本号是

10.2.0.1

，这个小补丁的差距就会导致迁移失败。

(

2

)

WAS

对交易超时的设置不恰当。

WAS

默认设置的交易超时时间为

130

秒，而

Portal

对

Oracle

数据传输的过程有很多事务是超过

180

秒的，这导致传输过程中由于交易超时而使得某些线程挂起，将这个超时时间改为

300

秒以上再执行传输过程，就可以避免出现这个问题。

(

3

)

Portal

数据库管理员在

Oracle

中不具备创建视图的权限。

用

户在创建

Oracle

数据库表空间的过程中，没有对指定的

Portal

数据库管理员赋予管理员权限，导致数据传输由于权限不足而失败。在

Oracle

中指定该权限后再次传输，可以避免该问题的出现。

8  配置Portal 6.1使用Novell LDAP作为Portal的安全机制

8.1  问题描述

配置

Portal 6.1

使用

Novell LDAP

并作为

Portal

的用户注册表和安全认证机制，配置过程是成功的，但是在

Portal

管理控制台创建出的用户、用户组无法搜索出来。

.2

解决方案

经过检查，发现用户在配置过程中存在以下问题。

LDAP

用户在被

Portal

搜索时设置的过滤条件太多了，用户按照自己的设置文档定义了“

LDAP entity types

”的

8

个属性，这

8

个属性在

Portal

管理员搜索用户时作为搜索的过滤条件。事实上，产品要求只需要两个过滤条件，这两个过滤条件是：

standalone.ldap.et.group.objectClasses=groupOfNames

standalone.ldap.et.personaccount.objectClasses=inetOrgPerson

改正的办法是删除已有的

8

个属性，并添加或更新为以上两个属性。修改完这两个参数后，再次搜索用户、用户组，上述问题就解决了。

9  对portal集群执行同步

1.

9.1

问题描述

对集群执行了

Portlet

安装、主题与皮肤安装、参数配置等之后，发现再次访问时没有起作用。这通常是由于没有执行集群同步导致的。做完以上工作后必须执行集群同步。执行同步有两种方法：一是强制(手工)同步；二是自动同步。

1.9

.2

解决方案

9.2.1

强制同步

以

wpsadmin

身份登录

WAS

管理控制台，如图

1-

28

所示。

图

1-

28

登录管理控制台

依次单击

“系统管理”→“节点”出现现有的节点列表。选中要同步的两台机器，然后单击“同步”按钮，如图

1-

29

所示。

图

1-

29

选中要同步的两台机器

系统开始同步，如图

1-

30

所示。

图

1-

30

开始同步

经过

1

～

2

个小时，系统同步完成。

.2.2

自动同步

在图

1-

29

所示的页面上，检查

Portal

集群的每个

节点

与

dmgr

(

Deployment Manager

)节点的

设置文件

是否

匹配，并确保跨单元配置数据的一致性。

具体操作步骤如下。

登录

管理控制台，单击

“

系统管理

”→“

Node Agent

”→“

node_agent_name

”→“

文件同步服务

”

。

选择

“

配置

”

选项卡

。

服务器启动时启用服务

。

指定服务器是否尝试启动文件同步服务。此设置不会导致启动文件同步操作。

在默认

情况下，此设置已启用。

数据类型

布尔

默认

值

true

指定同步间

隔

时间(以分钟计)。

默认

值为

1

分钟。

数据类型

整型

单位

分钟

默认

值

1

应用程序服务器使用的最小值为

1

。如果指定的值为

，则应用程序服务器忽略该值并使用

默认

值

1

。

设置

自动同步

。

指定是否在指定的时间间隔后自动同步文件。当此设置启用时，

Node Agent

在每次同步时间间隔中自动联系

Deployment Manager

，尝试同步节点的配置库和

Deployment Manager

拥有的主库。

如果启用自动同步设置，则

Node Agent

在与

Deployment Manager

建立联系时尝试文件同步。

Node Agent

在尝试下一次同步之前等待同步时间间隔。

如果要控制文件发送到节点的时间，

则取消选中

“自动同步时间”

复选框。

数据类型

布尔

默认

值

true

启动同步指定

Node Agent

是否在启动应用程序服务器之前尝试同步节点配置和主库中的最新配置。

默认

为在启动应用程序服务器之前不同步文件。启用设置确保

Node Agent

具有最新配置，但增加了启动应用程序服务器所花费的时间量。

注意：此设置不影响

startServer

命令。

startServer

命令直接启动服务器

,

并且不使用

Node Agent

。

数据类型

布尔

默认

值

false

排除

。

指定不应是配置数据同步的一部分文件或模式。此列表中的文件不从主配置库中复制到节点，并且不从节点上的库中删除。

默认

为未指定文件。

iSeries

用户

的默认

值是

*/plugin-cfg.xml

，它从

Web

服务器插件配置文件

中自动同步

。

要指定文件，

应

使用完整的名称或

者

以通配符

*

(

星号)开头或结尾的名称。例如：

cells/cell name/nodes/node name/file name

排除此特定文件

*/file name

排除任何上下文中名为

file name

的文件

dirname/*

排除

dirname

以及

dirname

下面的子属性

在每个条目结尾处按下

“

Enter

”键，

每行出现一个文件名。

因

为这些字符串表示逻辑文

件

位置而不是实际的文件路径，所以无论是什么平台，只需要正斜杠。

当

Node Agent

重新启动时，对排除列表所

做

的更改生效。

数据类型

字符串

单位

文件名或模式