PeopleSoft 登录过程详解

当PeopleSoft Windows客户端进程（如Application Designer）进行三层连接的时候，会连接到应用服务器，每个应用服务器进程在启动的时候就与数据库之间建立了一个两层的连接。PIA通常指代第四层。浏览器连接到Servlet，Servlet再连接到应用服务器。任何想要连接到数据库的进程必须通过PeopleSoft用户或者Operator ID识别自身。登录过程的目的是安全的验证PeopleSoft operator（已通过密码验证）能够访问PeopleSoft数据库。当一个PeopleSoft Windows客户端进程启动的时候，会出现一个登录对话框，如下图所示：

如果以如下的命令方式启动登录过程的话，可以抑制登录会话框的出现：

pside.exe -ct Oracle -cd HRDMOVM -co PS -cp PS

为了更好的看到PeopleTools程序与数据库建立两层连接的实际过程，下面一步步的展示进程的PeopleSoft trace。

一、进行初始连接

与7.5x相比较，PeopleTools 8 中第一次连接到数据库的特征发生了变化。从版本8开始，不管PeopleSoft操作者是谁，所有的PeopleSoft进程都连接到同一个低安全性的数据库用户，即Connect ID.

对于Windows客户端程序，各种各样的设置，包括Connect ID的用户名和密码，都在配置管理器中进行设置，如下图。数据库名和用户ID设置Windows客户端登录窗口中的默认值。这个工具也会加密Connect ID的密码。

配置管理器本质上是一个在客户端设置注册值的工具，如下图：

Windows客户端进程，如Application Designer会读取这些注册表值。

如果所有的PeopleSoft数据库不使用相同的Connect  ID和密码，客户端进程（主要是指Application Designer）就不能够在不改变这些注册值的情况下以两层模式连接到所有的数据库。尤其是不能够直接在数据库之间迁移Application Designer项目，因为Application Designer必须以两层模式登录到两个数据库，它会尝试使用同一个Connect ID登录到两个数据库。这个问题的解决办法就是将项目从源数据库导出到一个flat文件中，然后将该文件导入到目标数据库。

配置管理器也可以用于安装和卸载Windows开始菜单中的快捷键、ODBC驱动以及本地的PeopleTools可执行文件。

运行在Windows服务器中的应用服务器进程和进程调度器进程不使用注册表中的值。它们所有的设置都从配置文件中读取，在其他操作系统中也一样。

PeopleSoft应用服务器进程、COBOL程序以及AE进程执行相似的登录步骤。它们详细的连接信息不是保存在应用服务器配置文件psappsrv.cfg中，就是保存在进程调度器配置文件psprcs.cfg中。如下所示：

以下内容截取自psprcs.cfg

;=========================================================================

; Database Signon settings
;=========================================================================
DBName=HRDMOVM
DBType=ORACLE
UserId=APPUSER
UserPswd=APPUSER
ConnectId=people
ConnectPswd=peop1e
ServerName=
StandbyDBName=
StandbyDBType=
StandbyUserId=
StandbyUserPswd=

PeopleTools 客户端trace可以显示登录过程中执行的所有的SQL操作，如下所示：

PID-Line      Time              Elapsed     Trace Data...
-------             --------            ----------        -------------------->
1-1                09.51.31                           Tuxedo session opened {oprid='PS', appname='TwoTier',addr='//TwoTier:7000', open at 057C00D0, pid=1064}
1-2                09.51.33       2.330000   Cur#0.1064.HCM91 RC=0 Dur=2.267000 Create Connection Info=Primary/HCM91/people/ Handle=057E7BC8  

任何PeopleSoft进程的第一个操作就是以ConnectPswd连接到ConnectId，如上面加粗的部分所示。

对于Oracle，SQL*NET连接字符串是people/peop1e@HCM91（trace中没有显示密码）。连接字符串中的TNS服务名HCM91来自登录会话框中输入的PeopleSoft数据库名字。如果一个Oracle数据包含多个PeopleSoft数据库，每个PeopleSoft数据库名字必须有一个TNS服务名对应，而且所有的TNS服务名必须指向同一个Oracle 连接字符串.

TNS服务名也必须存在于默认的SQL*Net域中，因为PeopleSoft不会在连接字符串中指定任何域。在如下的例子中，一个Oracle数据库包含两个PeopleSoft数据库，因此有两个TNS服务名。

HCM91, HCM91_Q =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = HCM91)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = hcm91)
)
)

其中SERVICE_NAME指代Oracle SID，即Oracle数据库实例。

二、直接使用内存共享连接（UseLocalOracleDB）

当SQL*Net客户端进程和数据库位于同一个物理服务器上时，该进程可以通过共享内存直接连接到数据库，而不用使用Oracle监听器或者任何其他网络协议。这种方法会提供更好的性能，消耗更少的CPU时间。

通过共享内存进行的连接有时也叫作IPC（Interprocess Communication）连接。因为在Unix上，连接使用IPC资源，而且在SQL*Net配置文件中指定了IPC协议。早期的Oracle版本中，IPC协议叫作bequeath协议。

如果在连接字符串中没有将TNS服务名附加到用户名和密码之后，SQL*Net就进行共享内存连接。数据库实例通过ORACLE_SID环境变量指定。

如果应用服务器配置文件中的UseLocalOracleDB选项设置为1，如下所示：

以下内容截取自psappsrv.cfg

[Database Options]
;=========================================================================
; Database-specific configuration options
;=========================================================================
SybasePacketSize=
UseLocalOracleDB=1
ORACLE_SID=HCM91
EnableDBMonitoring=1
PSDB Maximum Cursors=

此时SQL*Net连接字符串就简单的只是用户名和密码了。PeopleSoft不会附加上TNS服务名，也不会使用tnsnames.ora文件了。

进程调度器用于启动批处理和报表进程，也可以像上面一样进行配置。在这种情况下，进程调度器以及其产生的COBOL或AE进程也进行直接内存共享连接。

实际上，应用服务器或者进程调度器与数据库共存在于一个服务器上的情况很少见了。一个非常合理的理由就是Oracle数据库许可授权通常基于数据库服务器上的CPU数目，即CPU数目越多，Oracle数据库软件许可证的价格就越高。如果数据库服务器也运行了PeopleSoft中间件，那么PeopleSoft中间件也会消耗你购买的用于数据库许可的CPU。

考虑到性能，PeopleSoft建议将UseLocalOracleDB设置成1。这种方式下，连接到数据库不需要Oracle监听器，因此这种数据库连接应该比使用IPC key稍快。然而对于整体响应时间的比例而言，收效甚微。设置UseLocalOracleDB=1也会使应用服务器和进程调度器对ORACLE_SID环境变量的值比较敏感，虽然ORACLE_SID也可以在配置文件中进行设置。

然而，我建议保持UseLocalOracleDB=0的设置，然后在tnsname.ora文件中指定一个IPC key，如下所示：

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = IPC)(KEY = ORA11gR2))
)
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = HRDMOVM)(PORT = 1521))
)
)

这种情况下，所有运行在数据库服务器上的SQL*Net客户端都进行IPC连接。‘

如果一个连接到数据库的客户端进程偶然终止了，而没有从数据库服务器断掉，特别是当等待数据库的响应时，Oracle影子进程还是会继续运行。当PSAPPSRV或PSQRYSRV进程终止或者因等待一个长时间运行的SQL查询返回结果而超过了Tuxedo服务超时时间，就会出现这种情况。也可以在PeopleSoft操作者安全概要中设置查询超时时间。PeopleSoft不会清理数据库会话所持有的资源，因此在sqlnet.ora文件中应该总是设置SQLNET.EXPIRE_TIME以启用Oracle Terminated Connection Timeout。这项机制可以清理掉断掉的shadow process。

下面是SQLNET.EXPIRE_TIME的说明：

#sqlnet.expire_time = 10
########################
#
#Possible values: 0-any valid positive integer! (in minutes)
#Default: 0 minutes 
#Recommended value: 10 minutes
#
#Purpose: Indicates the time interval to send a probe to verify the 
#          client session is alive (this is used to reclaim watseful 
#          resources on a dead client)

三、获取Owner ID

连接到了Oracle数据库之后，登录进程的第一项任务就是判断哪个数据库schema包含PeopleSoft数据库。下面的几行PeopleTools客户端trace展示了PSDBOWNER表是如何将数据库映射到schema上的。

1-4 09.51.33 0.000000 Cur#1.1064.HCM91 RC=0 Dur=0.000000 COM Stmt=SELECT OWNERID FROM PS.PSDBOWNER WHERE DBNAME=:1
1-5 09.51.33 0.000000 Cur#1.1064.HCM91 RC=0 Dur=0.000000 Bind-1 type=2 length=5 value=HCM91

根据传入的DBNAME获取OWNERID。

包含PeopleSoft数据库的schema叫作Owner ID。直到成功登录，登录程序明确的引用了该schema中的三个对象。因此在安装过程中，SELECT权限被明确的通过Data Mover脚本赋予给了这三张表，如下所示：

GRANT SELECT ON PSSTATUS TO PEOPLE;
GRANT SELECT ON PSOPRDEFN TO PEOPLE;
GRANT SELECT ON PSACCESSPRFL TO PEOPLE;

安装程序本身是连接到了包含这几张的的schema上，所以在GRANT命令中没有指定schema名字。
PS.PSDBOWNER表允许PeopleSoft在一个Oracle或其他数据库中管理多个PeopleSoft数据库。该表包含一行数据，将PeopleSoft数据库的名字映射到其所属Oracle schema上。给同一个PeopleSoft数据库取两个名字也是可能的。可以在该表中添加一行数据，这两个数据库名字映射到同一个OWNERID即可。如下几种情况可能会用到这种特性：

• 如果正在变更一个PeopleSoft数据库的名字，在过渡期间，这两个名字都有效。
• 如果生产数据库被复制到一个只读的报表数据库中，你可能希望在不改变数据库的情况下查询该数据库。

不管使用哪种方式，对于每一个在PS.PSDBOWNER表中指定的数据库名称（DBNAME），在默认的SQL*Net 域中都必须有一个相应的TNS服务。所以可见PSDBOWNER表中的DBNAME并不是指代PeopleSoft数据库名称，而是指TNS服务名，PeopleSoft数据库还是得靠OWNERID说了算。PeopleSoft数据库名称只是逻辑上的一个概念，实际在Oracle数据库中就是一个schema下的一些表集合。一个OWNERID对应一个PeopleSoft数据库。

如果在PS.PSDBOWNER表中没有皮质TNS连接字符串的条目，就会提示”登录用户名或密码无效”。该错误实际上包含了登录过程中所有的错误，因此不要只限于检查用户ID和密码问题。

四、检查PeopleTools的版本

下一项任务就是保证登录程序当前所试图连接的PeopleSoft数据库的PeopleTools版本和客户端的相同。PeopleTools表结构在主要的PeopleTool发行版本（8.1到8.4）中总是在变化。从PeopleTools 8.x 开始，在小版本（如8.50到8.51）之间有些许结构上的变化。大小版本号记录在数据库表PSSTATUS.TOOLSREL列中：

PeopleTools客户端trace显示客户端从PSSTATUS表中查询PeopleTools版本：

1-6 09.51.33 0.001000 Cur#1.1064.HCM91 RC=0 Dur=0.000000 COM Stmt=SELECT OWNERID,TOOLSREL, TO_CHAR(LASTREFRESHDTTM,'YYYY-MM-DD HH24:MI:SS'), TO_CHAR(LASTCHANGEDTTM,'YYYY-MM-DD
HH24:MI:SS') FROM SYSADM.PSSTATUS
1-7 09.51.33 0.001000 Cur#1.1064.HCM91 RC=0 Dur=0.001000 COM Stmt=SELECT DBID FROM SYSADM.PSSTATUS

注：DBID列是在8.46版本中引入的。

将PeopleTools从一个版本升级到另一个版本的过程中，有一步是运行一个PeopleSoft提供的“rel”脚本。该脚本（如下）重建那些结构发生了变化的表，以及更新TOOLSREL列中的PeopleTools版本号。

以下内容截取自rel851.sql

UPDATE PSSTATUS SET TOOLSREL='8.51',
                  LASTREFRESHDTTM = SYSDATE
;

比较版本的操作不会针对PeopleTools补丁级别，即8.50任何补丁级别（如8.50.09）都能够成功的连接到数据。People不会在补丁发行版本中改变PeopleTools的结构。

如果在登录过程中版本号不比配，就会在客户端PC 上显示一个错误对话框（如下图）。该错误指示要么是安装过程出错，要么是使用了错误的可执行文件。

另外需要注意的是，在四层模式中，PIA servlet的版本必须精确匹配应用服务器的版本，否则也会连接失败。如8.50.09的servlet不能够链接到8.50.08的应用服务器。在三层模式中，Windows客户端程序同样如此，比如Application Designer或者nVision。
在应用服务器中，每个PeopleSoft应用服务器进程启动时都会执行PeopleTools版本测试。PeopleTools 8.43引入的PSWATCHSRV服务器进程例外。该进程会检测以及杀死已经成了了僵尸进程的服务器进程，而且这个进程根本不会连接数据库。

当应用服务器启动时，会将消息写到APPSRV.LOG文件中，如下：

截取自APPSRV_<MMDD>.LOG

PSAPPSRV.6812 (0) [09/06/12 10:20:12](0) PeopleTools Release 8.51 (WinX86) starting. Tuxedo
server is APPSRV(99)/2
PSAPPSRV.6812 (0) [09/06/12 10:29:12](1) GenMessageBox(0, 0, M): Security Table Manager (Get):
The database is at release 8.48. The PeopleTools being run require databases at release 8.51.
PSAPPSRV.6812 (0) [09/06/12 10:29:12](0) Server failed to start

五、检查Operator密码

下一步是检索存储在PSOPRDEFN表中PeopleSoft用户的加密密码。

1-8 09.51.33 0.000000 Cur#1.1064.HCM91 RC=0 Dur=0.000000 COM Stmt=SELECT VERSION,OPERPSWD, ENCRYPTED, SYMBOLICID, ACCTLOCK FROM SYSADM.PSOPRDEFN WHERE OPRID = :1
1-9 09.51.33 0.000000 Cur#1.1064.HCM91 RC=0 Dur=0.000000 Bind-1 type=2 length=2 value=PS

下面显示检索后的结果：

VERSION    OPERPSWD                       ENCRYPTED  SYMBOLICID               ACCTLOCK
---------- ------------------------------ ---------- ------------------------ ----------
165        9qSGfTd2aRl/N+N4B7ZUz72qJe6=   1          SYSADM1                  0

检索出密码之后再验证用户输入的或者配置文件中设置的密码是否匹配。

六、获取访问密码

操作者的访问概要是从PSOPRDEFN.SYMBOLICID字段中获取的，用于在PSACCESSPRFL表中查找ACCESSID和ACCESSPSWD。

1-10 09.51.33 0.001000 Cur#1.1064.HCM91 RC=0 Dur=0.000000 COM Stmt=SELECT ACCESSID,ACCESSPSWD, ENCRYPTED FROM SYSADM.PSACCESSPRFL WHERE SYMBOLICID = :1
1-11 09.51.33 0.000000 Cur#1.1064.HCM91 RC=0 Dur=0.000000 Bind-1 type=2 length=7 value=SYSADM1

PSACCESSPRFL表在PeopleTools 7.5中就存在，但是在登录过程中不会检查该表，因为在PSOPRDEFN表中也存在加密的访问密码。在PeopleTools 8 中，访问密码只存在于PSACCESSPRFL中。

七、以Access ID身份重新连接数据库

找到了Access ID以及密码之后，登录进程从数据库断开，然后以Access ID账户登录到数据库。

1-12 09.51.33 0.001000 Cur#1.1064.HCM91 RC=0 Dur=0.000000 Disconnect
1-13 09.51.33 0.002000 Cur#0.1064.notSamTran RC=0 Dur=0.002000 Destroy Connection Handle=057E7BC8
1-14 09.51.35 2.267000 Cur#0.1064.HCM91 RC=0 Dur=2.267000 Create Connection Info=Primary/HCM91/SYSADM/ Handle=057E7BC8
1-15 09.51.35 0.003000 Cur#1.1064.notSamTran RC=0 Dur=0.002000 Open Cursor Handle=057E7BC8
1-16 09.51.36 0.003000 Cur#1.1064.HCM91 RC=0 Dur=0.000000 CEX Stmt=select pt_tde_encrypt_alg from psoptions
1-17 09.51.36 0.001000 TDE Encryption Algorithm: ''
1-18 09.51.36 0.000000 Cur#1.1064.HCM91 RC=0 Dur=0.000000 COM Stmt=SELECT TO_CHAR(SYSTIMESTAMP,'YYYY-MM-DD-HH24.MI.SS.FF') FROM PSCLOCK

PeopleSoft应用会执行更多的检查操作，用于判断操作者是否被允许连接，以及在应用或者设计工具中判断他们能够执行操作的程度。但是在此处，登录进程进行到这里就已经完成了登录操作。

但是PeopleSoft的这一系列的登录过程会使如下几种操作变得困难：

• 判断哪一SQL片段属于哪一个用户
• 使用Oracle资源管理器或者资源概要为不同的用户类型设置不同的资源利用阈值

从PeopleTools 7.53 开始，PeopleSoft使用DBMS_APPLICATION_INFO包帮助辨别用户的会话。

需要注意的是：Access ID的名称不是来自PS.PSDBOWNER.OWNERID字段，而是来自PSACCESSPRFL.ACCESS_ID字段。