Part 2: PeopleSoft SES Configuration

Previously in Part 1, I wrote about the steps to install Oracle Secure Enterprise Search for use with PeopleSoft and I reviewed some considerations for PeopleSoft Admins.  Part 2 covers the integration configuration required to have PeopleSoft communicate with SES.  On the PeopleSoft side we must setup Integration Broker properly.  On the SES side we need to configure Identity Management for PeopleSoft.

Continue reading

SES for PeopleTools 8.53 Installation

There is a lot of information to cover about Oracle Secure Enterprise Search and PeopleSoft.  As I was writing this I decided it became too much for a single post, so I’ve decided to break it into at least three posts and maybe four:

  • Part 1 – SES Installation:  Installing the SES product for PeopleSoft
  • Part 2 – Integration Configuration:  Configuring PeopleSoft and SES to communicate properly
  • Part 3 – Administration:  How to administer the PeopleSoft/SES functionality
  • Probably Part 4 – PeopleSoft/SES troubleshooting:  Troubleshooting tips and methods for the SES/PeopleSoft relationship


Oracle Secure Enterprise Search is now the new standard search engine for PeopleSoft with the release of the PeopleSoft 9.2 applications.  SES support was introduced in PeopleTools 8.52 with the new PeopleSoft Search Framework.  You can use SES with older applications, however you may need to create search indexes yourself because only the newest Feature Packs may include delivered indexes, HCM 9.1 FP 2 for example.

The PeopleSoft Search Framework provides a standardized method for creating and maintaining search indexes for PeopleSoft that should be considered an improvement over what was required previously.  Very briefly, the Search Framework Designer is used to create a search definition based on PeopleSoft Query.  In the definition you can implement security, data mapping, categories, and related searches for example.  The search is then deployed to Oracle SES through the Search Framework Administration pages.  You then run an AE which will create your index and publish a feed for Oracle SES and initiate the crawler on the SES side.  All the interaction between PeopleSoft and Oracle SES is via Integration Broker.

Verity is no longer supported for the 9.2 applications or later but is still supported in 8.53 for older applications.  SES is a separate product that can be used to index and search just about anything.  According to documentation no additional licenses are needed to use SES with PeopleSoft, so a limited use licenses is probably wrapped into the standard PeopleTools agreements for 8.52+.  SES includes Weblogic, Oracle Database Server, and the SES Application itself.  From my understanding Oracle does not support the separation of these components and has stated “SES is packaged as a ‘software appliance’ where Oracle database, mid-tier, and the SES application are all tightly integrated and shipped in a single bundle”.

When planning your deployment of SES into your environment consider the following. Continue reading

PeopleSoft TEMP/TMP Directories

In PeopleTools 8.53 Oracle has changed how the TEMP and TMP environment variables are handled.  They are taking the responsibility of setting these out of the Admins hands.  In the past we set these as environment variables perhaps in the shell profile or  When we configured the app server / process scheduler these settings would be inherited into the Tuxedo configuration.  With Windows 2008, some were impacted with it’s default of dynamic TEMP/TMP variables based on session and being deleted on logout.  On Windows a previous co-worker of mine got me into the practice of modifying the psappsrv.ubx and prprcs.ubx files and setting these variables there rather than relying on what the user in Windows might have set or trying to adjust them with scripts.  This proved to be helpful in many ways.  Now Oracle has decided to do the same thing by default.

This may impact Admins who are used to having these variables set to something they specifically wanted.  Depending on your setup you may prefer to change these back.  A default psappsrv.ubx file has the following section:

# ————–


{LOGDIR} is $PS_CFG_HOME/appserv/<DOMAIN>/LOGS and {FS} is the OS specific path delimiter.  So this will use a temp directory in the LOGS directory of each domain such as /opt/apps/psoft/domains/appserv/HCM92/LOGS/tmp.

I’m not sure how much of a fan I am of having TEMP in the logs directory.  I guess just knowing it’s moving is half the battle.  It’s easy to change back if you like.

See Oracle support document [ID 1486978.1] for the announcement.  I don’t recall seeing this in the release notes, but I might have missed it.  They also said it would be back ported to 8.52.16, but you would need to recreate all your domains, not just reconfigure in order to get the change.  Oracle is adding these settings to the domain templates, once you create the new domain from a template TEMP and TMP will be set in the appropriate ubx file.

App Server to Database Reconnection issues in 8.51

I ran into a problem a while ago which brought a more severe problem to my attention.  It appears in at least 8.51.02 (but probably back to 8.51.00) to 8.51.09 there are issues with application server processes properly recovering from a disconnection from the database.  I don’t have first hand experience with that problem, but there is some info on Oracle’s support site about it. If you are running in this PeopleTools range and experiencing odd crashes every once in a while this may be worth investigating.  Using Tracesql=31 will create ORA-3113/3114 errors in your logs.  In 8.51.08 a patch went in to fix it, but it broke something else, causing the problem I encountered.  Bug 11724645 has the details.

My particular problem was experienced on 8.51.09 and was limited to only the Integration Broker PUBSUB processes.  So apparently the PSAPPSRV code had been fixed by then as I never had a problem with those.   In this post I’ll discuss what I saw, some of the troubleshooting steps I used to isolate the problem, and some options I came up with to resolve it.

The Problem:

Integration Broker stops processing messages.   The processes don’t crash and look OK from a quick glance (psr and Process Explorer), but do nothing.  The environment was 8.51.09 all Windows 2008 on SQL Server.  The problem occurred everywhere, even in environments that restarted nightly.

Diagnosing the Problem:

I knew from day one something strange was occurring.  I had never needed to restart the PUBSUB processes this often ever before.  Almost daily some environment would need restarted, sometimes multiple environments, sometimes ones that had already been restarted.  Obviously it was off to the logs first.  There I found something interesting.  Here’s an example, the tables might be different depending on the processes (PSPUBDSP, PSSUBDSP AND PSBRKDSP), but the main message is always the same:  The SELECT permission was denied on the object

PSSUBDSP_dflt.6076 (1) [01/28/12 10:00:25](3) File: E:\pt851-903-R1-retail\peopletools\src\pspubsub\statements.cppSQL error. Stmt #: 67  Error Position: 0  Return: 8601 – [Microsoft][SQL Server Native Client 10.0][SQL Server]The SELECT permission was denied on the object ‘PSAPMSGDSPSTAT’, database ‘HCMDEV’, schema ‘dbo’. (SQLSTATE 42000) 229
PSSUBDSP_dflt.6076 (1) [01/28/12 10:00:25](1) GenMessageBox(200, 0, M): E:\pt851-903-R1-retail\peopletools\src\pspubsub\statements.cpp: A SQL error occurred. Please consult your system log for details.
PSSUBDSP_dflt.6076 (1) [01/28/12 10:00:40](3) File: E:\pt851-903-R1-retail\peopletools\src\pspubsub\statements.cppSQL error. Stmt #: 663  Error Position: 0  Return: 8601 – [Microsoft][SQL Server Native Client 10.0][SQL Server]The SELECT permission was denied on the object ‘PSAPMSGSUBCON’, database ‘HCMDEV’, schema ‘dbo’. (SQLSTATE 42000) 229
PSSUBDSP_dflt.6076 (1) [01/28/12 10:00:40](1) GenMessageBox(200, 0, M): E:\pt851-903-R1-retail\peopletools\src\pspubsub\statements.cpp: A SQL error occurred. Please consult your system log for details.
PSSUBDSP_dflt.6076 (1) [01/28/12 10:00:40](3) File: E:\pt85109b-retail\peopletools\src\psmgr\mgrvers.cppSQL error. Stmt #: 881  Error Position: 0  Return: 8601 – [Microsoft][SQL Server Native Client 10.0][SQL Server]The SELECT permission was denied on the object ‘PSVERSION’, database ‘HCMDEV’, schema ‘dbo’.
[Microsoft][SQL Server Native Client 10.0][SQL Server]The cursor was not declared. (SQLSTATE 37000) 16945
PSSUBDSP_dflt.6076 (1) [01/28/12 10:00:40](1) GenMessageBox(200, 0, M): E:\pt85109b-retail\peopletools\src\psmgr\mgrvers.cpp: A SQL error occurred. Please consult your system log for details.

My first reaction was to check the permissions for the ACCESSID user and of course, nothing was out of the ordinary there.  I searched Oracle support and found a case indicating that I needed to Synchronize the ACCESSID after a Tools upgrade to 8.50+ on SQL Server, but from what I could see the account was setup just fine.  That’s when I took a look at the database connections and saw something bizarre. There was a connection to the database as user people. I waited a minute and looked again, the same connection was still there as people.  Now that shouldn’t happen.  As you should know, the people user is very limited in what it can do.  It’s really only used to validate OPERID’s and retrieve the ACCESSID and password.  I queried sys.dm_exec_sessions, I wanted the host_process_id so I could see what process was connected as people for so long.

login_name session_id login_time              program_name host_process_id status
psaccess   77         2012-01-28 04:16:11.970 PeopleSoft   5624            sleeping
people     81         2012-01-28 04:16:12.030 PeopleSoft   6076            sleeping
psaccess   82         2012-01-28 04:16:12.030 PeopleSoft   5612            sleeping

Once I got the host_process_id, I went back to the app server and confirmed what the log was already telling me.  PID 6076 on the app server was the PSSUBDSP process.  The same one that didn’t have select permission anymore and of course it couldn’t select, it was connected as people.  I also noticed the login_time of the processes seemed odd.  I didn’t restart that system at 04:16 and in fact looking at the processes in Process Explorer indicated the processes had been running quite a while longer.  Now the processes will restart after a certain amount of work load, but that should rarely have them all reconnecting to the database at the same time.  In the logs I didn’t see anything around that time, in fact, the errors didn’t show up until several hours after the login_time.

I restarted the PUBSUB processes and saw that after restarting all processes were once again connected as the ACCESSID.  I decided to see what happened if I killed the connection for the process from the database.  I killed a newly connected PSSUBDSP process by matching the session_id from sys.dm_exec_sessions with the host_process_id again.  The process reconnected as people and never made the switch to the ACCESSID again.

The Test Plan:

I decided to dig in a little deeper.   I was going to file a case with Oracle since I had not found anything on their support site that seemed to address this at all.  I also wanted to have someone else try to replicate it on a different version of PeopleTools.  Plus I didn’t know why the error didn’t really show up until some time later.  To make this section shorter, I did several things to validate my theory (after network/database disconnection the reconnect process was broke) and ensure I had the detail needed for the support case.  I validated outbound port numbers changed with netstat, turned up tracing a bit, and forced messages through.  Something I found during this was that the error would not start showing in the app server logs until a message had tried to be processed.  I ended up coming up with the following test plan to provide to Oracle and others to use:

  1. Set TraceSql=7 in psappsrv.cfg
  2. Review newly created <USER>_PSSUBDSP_dflt.tracesql log to determine pid for PSSUBDSP process
  3. While reviewing the log, verify that after every SQL statement is run transactions are “commited”;  look for a line like:
    PSSUBDSP_dflt.17196 (4)      1-3      16.25.27    0.005000 Cur#20.17196.FINDEV RC=0 Dur=0.003000 Commit
  4. Run netstat -a -o |find “<pid>”  : noting outbound TCP port
  5. Determine SID to kill and the user it’s logged in as
    select session_id, login_name from sys.dm_exec_sessions where host_name=”<App Server HOSTNAME>” and host_process_id=<pid>
  6. kill <sid> :  to kill connection
  7. Wait 15 – 30 seconds
  8. Rerun netstat -a -o |find “<pid>”  : noting outbound TCP port, did it change?  it should have.
  9. Review <USER>_PSSUBDSP_dflt.tracesql log to determine if transactions are now failing; look for a line like
    PSSUBDSP_dflt.17196 (62)      1-3      17.00.24    0.002000 Cur#1.5844.FINDEV RC=0 Dur=0.001000 Rollback
  10. Rerun the SQL above to determine if the login_name has changed
    select session_id, login_name from sys.dm_exec_sessions where host_name=”<App Server HOSTNAME>” and host_process_id=<pid>
  11. If login_name = people or transactions are saying Rollback in the log, you have a problem, review APPSRV log to check for the following errors. None should exist until the next message is processed. PSSUBDSP_dflt.5844 (63) [11/12/12 15:14:56 Dispatch](3) File: E:\pt851-903-R1-retail\peopletools\src\pspubsub\statements.cppSQL error. Stmt #: 67  Error Position: 0  Return: 8601 – [Microsoft][SQL Server Native Client 10.0][SQL Server]The SELECT permission was denied on the object ‘PSAPMSGDSPSTAT’, database ‘FINDEV’, schema ‘dbo’. (SQLSTATE 42000) 229
    PSSUBDSP_dflt.5844 (63) [11/12/12 15:14:56 Dispatch](1) GenMessageBox(200, 0, M): E:\pt851-903-R1-retail\peopletools\src\pspubsub\statements.cpp: A SQL error occurred. Please consult your system log for details.
  12. Force a message through the system. I was just locking and unlocking my account on the HR side to force the message over to another application.
  13. Check to see if the message was processed and review APPSRV log for error.
  14. Test either Passed: Message proccessed ok, or Failed: Message stuck in New status on subscription side and error in the APPSRV log.
  15. Set TraceSql=0 in psappsrv.cfg
  16. Restart PUBSUB processes to correct any connection problem.

The Fix:

In a test environment I validated that the PUBSUB processes were fixed in 8.51.10, unfortunately, a minor PeopleTools patch was not an option at the time for production, so a work around was in order.  What would be the best way to identify this problem and take corrective action?  If you’ve read some of my other posts you might know blindly restarting every night isn’t my style, and as I saw didn’t guarantee anything.  What ever was causing the disconnect could happen any time, you might need to restart every 30 minutes to ensure a decent availability for integration.  I needed to detect the problem, identify which database on the SQL Server was impacted, and restart only what was impacted.  Time to break out my scripting fingers.  I came up with two scripted solutions.  The first solution I wrote was a SQL script that could be scheduled which would:

  1. Identify connections to the database as people that were older than X minutes
  2. Execute a power shell script on the database server providing  the server name, database, and host PID of the offending process
  3. That database server side PowerShell script would then remotely execute PowerShell commands on the correct app server which
  4. Ensured the host PID provided was for a PUBSUB process and
  5. Executed my normal PUBSUB restart script for the domain

This method had several challenges that I did not try to overcome really.

  1. The database user running the SQL script needs xp_cmdshell.  This is a big security concern in many shops and in general something that should probably be frowned upon.  It would probably be easy enough to have the PowerShell script run the SQL and collect the data as well.  But I didn’t look into it.
  2. My SQL script assumed the app server domain running PUBSUB was the same as the database name.  If you ran multiple or different named domains it would need to be tweaked to take those into account.
  3. Remote PowerShell capabilities had to be turned on, another possible security concern.

I also wrote another Powershell script that was application server side based.  I have a large script infrastructure that is already deployed to any windows app servers that some what mimics on the nix servers.  This script leverages that infrastructure, and with one additional script, I can monitor all domain APPSRV logs on a server for the error.  This script does the following:

  1. Reads a central file that includes all application domains on the server
  2. Uses pattern matching to find a domain with “select permission was denied” in the log file
  3. If an error is found, the script waits for 20 seconds and rechecks the log file
  4. It compares the number of error lines before and after the 20 seconds (default polling interval is 15 seconds)
  5. If the count increases, it restarts PUBSUB and emails me notification of the restart
  6. If the count is the same, we must have restarted previously, so we do nothing

This method also has some disadvantages, but is the route I chose

  1. It won’t detect the problem until the error is in the log, which could be hours later.  However, there is no user/functional impact until the error arrives as that is the first time a message is actually processed.
  2. I’m not doing anything fancy to track file offsets and start reading where I left off, therefore, the larger the file the longer the script will take to run.  I would not recommend running this against log files that are growing really large or have tracing on.
  3. This script needs to be scheduled on each physical application server instead of a smaller number of database servers.

I never did identify the real culprit of why the processes are being disconnected from the database, it seems to be pretty hit and miss.  I had some ideas, but once I got the automatic restarts scheduled everyone’s interest in the problem died down significantly.

Parallel Pagelet Loading

PeopleTools 8.52 added a performance enhancement for systems that have multiple pagelets on a page.  Previously pagelets were loaded in a sequential fashion, one after another.  With this enhancement the pagelets can be loaded in a parallel fashion allowing your pages to load faster.  Oracle indicates that a page with seven pagelets can reduce it’s loading time by 15%.

With 8.53.01 this setting is delivered enabled, but in 8.52 this feature is not enabled.  In fact, the configuration setting does not even exist.  You have to add it manually.  That was apparently an misstep by the development team according to Oracle support [ID 1503803.1].

To enable this option in 8.52 add the line
to your file which is located at <PS_HOME>/<domain name>/applications/peoplesoft/PORTAL.war/WEB-INF/psftdocs/<site name>/  Jolt pooling is also required for this setting.

If you deploy lots of pagelets on your homepage you may want to do some performance analysis of how your system will handle peak  times prior to enabling this feature.  Adding lots of pagelets to the homepage, especially in Portal / Interaction HUB, should be done with caution particularly in older versions of PeopleSoft.  I’d really like to post a detailed article on this topic with an analysis of how 8.52 and 8.53 may have improved how this type of configuration responds.  But if I had to sum it up in one sentence it would be this.  While some analysts, developers, or management types may think it’s a great idea to provide data to the user in Portal /  Interaction HUB in the form of pagelets upon logon, it can have a substantial impact on system performance and possibly even bring down your systems.  It needs to be tested thoroughly and under substantial load.  Parallel Pagelet Loading may help alleviate some of the issues I’ve seen in the past, but I will need to test it first hand to know.

PeopleSoft Test Framework

The PeopleSoft Test Framework (PTF) is a testing tool that was released with PeopleTools 8.51 and has seen improvements and active development from Oracle in 8.52 and 8.53.  PTF is a record and playback tool that is somewhat similar to other testing automation tools.  It distinguishes itself from other tools for a few reasons:

  1. It’s provided as part of PeopleTools 8.51+ so there is no additional cost
  2. Tests, related settings, and objects are stored as managed objects in your PeopleSoft database and can be migrated to other environments with App Designer.
  3. It can be combined with Usage Monitor data to validate test coverage.
  4. It’s written by Oracle so they are able to leverage PeopleSoft functionality directly by providing specialized commands.

PTF does have it’s limitations though so you should check the release notes (under the Lifecycle Management Tools section) and PeopleBooks documentation for your PeopleTools release.  It’s designed to automate functional testing, it unfortunately does not provide any type of performance/load testing capabilities.

PTF Setup

I’ve setup PTF on both 8.51 and 8.52.  I have not had a chance to install the 8.53 version but I think the differences will be limited.  There were some nice improvements going from 8.51 to 8.52.  I’m going to rehash my notes here, the standard documentation was pretty good in describing the installation process.  First off there are some prereqs for PTF:

  1. Your PIA domain needs SSL to be functioning.
  2. IB needs to be working
  3. You need to assign some PTF roles
    1. The ANONYMOUS Node Default User Id must have PTF User Role
    2. Users running the PTF client must have PTF User, Editor, or Administrator
  4. The web profile needs to be configured properly
    1. Generate HTML for testing must be enabled
    2. Show Connection & Sys Info must be enabled
    3. Both of those are on the Debugging tab and should be on by default if your using some variation of the delivered “DEV” profile.

Here is a link to the 8.52 PeopleBooks install page which has a diagram of a PTF environment.  Once your PeopleSoft environment is setup and you’ve confirmed the above items you should review the Configuration Options page at PeopleTools –> Lifecycle Tools –> Test Framework-> Define Configuration Options.  This page differs quite a bit on 8.52 from 8.51.  In 8.51 it has a single option: Allow Untrusted SSL.  Depending on your tools release choose your options accordingly. In many cases you may be relying on a self signed certificate that was delivered with your web server.  You will get an SSL error when you try to connect if you need this setting.  If that is the case, ensure that Allow Untrusted SSL is enabled here.

PTF Config Options 8.51PTF Config Options 8.52PTF Config Options 8.53

After the PeopleSoft configuration is done it’s time to install the client or record/playback tool.  I installed this on a Windows 7 VM.  A few things to note about the client.

  1. It’s a Microsoft based client and requires .Net 3.5; sorry no Linux
  2. It requires Internet Explorer, it will not work with other browsers
  3. If you are installing on Vista or Windows 7 the client should be run with the run as administrator option in order to hook the browser and record properly.  Without doing this I had problems.
  4. The Internet Options for the Windows client should include both http and https entries for your domain in the Local Intranet security zone.  Most companies have this in place already, but could be a problem if they are not there and changes are restricted by AD.

To install the PTF client, run the Setup.exe file from your File Server or your local PeopleTools install.  The setup file is <PS_HOME>\setup\PsTestFramework\setup.exe

Next, run the PeopleSoft Test Framework client (as administrator) and add a new connection to your PTF enabled environment. Populate the required fields as setup connection FINDEV needed.  The server:port number combo is you webserver address and the SSL/HTTPS port.  If your running on the default 443 port the port number is optional.  The user specified here must have one of the PTF roles mentioned previously.  Once connected you can edit some local settings by selecting the @environment on the top left of the menu bar. Local Options  I have left these default except in 8.51.  In the 8.51 version this is where you configure your Process Server List for the Execution Options section.  If you looked at the screen shots above of the Online Configurations options earlier you’ll see they moved this from a Local Option in 8.51 to a Database based option in 8.52.  After reviewing the Local Options, open the Execution Options.  These options are also stored in the database and can be managed online by a user with the PTF Administrator role.  These options are used to configure settings for the application your testing.  You’ll need to create at least one set of Execute Options ( you can create multiple settings for different tests or configurations you would like to run).  The URL defined here should be the URL with the logout command, for example: The documentation explains everything else pretty good so refer to it.

You should now be ready to record a test!

Your First Test

Once you have PTF ready to go there are some older 8.51 YouTube videos currently available at  These videos provide a simple overview of how to get started using PTF and provide good introduction material.  They should get you started on recording your first test.

Essentially the process is as follows in 8.52 (it’s pretty much the same in 8.51 but the Test Recorder window has less options and looks a bit different):

  1. Select menu option Create and chose to create a Test.
  2. Click the red stop sign button which is the Show Test Recorder button, the Test Recorder window will open
  3. Press the house button which will open and hook a new browser, it should also take you to your PeopleSoft login page if your Execution Options are configured properly.  Note:  The PTF window may stay on top of the IE window, just look to see if IE opened and bring it on top of the other windows.
  4. Click the Red Circle in the Test Recorder window to start recording.
  5. Use IE to login, pull up some page, and logout.
  6. Click the Black Square in the Test Recorder window to stop recording
  7. Close the Test Recorder window
  8. Your test steps are displayed and once you give the test a name it can be saved. Menu option Test , Save As
  9. Once the test is saved, the playback button will turn green and you can now run your test by pressing it.

That should do it.  You should be up, running, and recording now.  I’m hoping to do another post on this topic with some more interesting test scripts soon.  And possibly show how PeopleSoft Admins can leverage this for things other than functional testing.

HCM 9.2 and 8.53 Demo Install Notes

These are my notes from a recent HCM 9.2 / 8.53.02 setup I did.   I tried out the database wizard again this time.  Had a few hiccups but it seemed to work.  I still think it’s easier and quicker to create the database manually, especially when the java process ran at 100% on one cpu for about 20 to 30 minutes as the notes indicate below.  All said, it was an easy build and I didn’t see any significant issues/problems.

Update:  See the notes for HCM 9.2 / 8.54.03 / Patch Image 9

Install web componenents on web server

Things needed:
  1. wls1036_generic.jar
  2. jdk-7u17-linux-x64.tar.gz  or jdk-7u9-linux-x64.rpm (actually anything jdk7u2 +)
  3. License key for PeopleTools Oracle Install:
  4. PeopleTools 8.53.02 patch
  • Weblogic Media location: /opt/media/media/8.53/ptools.weblogic
  • Weblogic/JDK Install location: /opt/apps/
  • PeopleTools Media location: /opt/media/media/8.53/ptools
  • PeopleTools Install location: /opt/apps/psoft/pt853
  • HCM Application Install location: /opt/apps/psoft/hcm92

The Install

$ cd /opt/apps
$ tar zxvf /opt/media/media/8.53/ptools.weblogic/jdk-7u17-linux-x64.tar.gz
$ export JAVA_HOME=/opt/apps/jdk1.7.0_17
$ $JAVA_HOME/bin/java -jar /opt/media/media/8.53/ptools.weblogic/wls1036_generic.jar -log=./logs/wls1036HcmInstall.log

Weblogic Install prompts
Middleware Home= /opt/apps/wls1036.hcm92
Typical Install
JDK detected fine
Default product install directories

$ cd /opt/apps/psoft
$ /opt/media/media/8.53/ptools/Disk1/

PeopleTools Install Prompts

$ /opt/media/media/hcm92/Disk1/

HCM Application Install Prompts

$ /opt/media/media/8.53/patch.02/cd85302/Disk1/

Patch Install Prompts

Install app components on app/prcs server:

Things needed:
  1. tuxedo111130_64_Linux_01_x86.bin
  2. COBOL Compiler ?
  3. License key for Oracle Install:
  4. HCM license key for Oracle:
  5. PeopleTools 8.53.02 patch
  • Weblogic Media location: /opt/media/media/8.53/ptools.tuxedo
  • Tuxedo Install location: /opt/apps/
  • PeopleTools Media location: /opt/media/media/8.53/ptools
  • PeopleTools Install location: /opt/apps/psoft/pt853
  • HCM Application Install location: /opt/apps/psoft/hcm92

The Install

$ cd /opt/apps

$ /opt/media/media/8.53/ptools.tuxedo/tuxedo111130_64_Linux_01_x86.bin -i console

Tuxedo Install Prompts
Use existing ORACLE_HOME=/opt/apps
Use default TUXDIR=/opt/apps/tuxedo11gR1
Install Samples = Y
tlisten password = ********
Install SSL Support = N
$ cd tuxedo11gR1
$ . tux.env
$ tmadmin -v
INFO: Oracle Tuxedo, Version, 64-bit, Patch Level (none)

$ cd /opt/apps/psoft
$ /opt/media/media/8.53/ptools/Disk1/

PeopleTools Install Prompts
$ /opt/media/media/hcm92/Disk1/
HCM Application Install Prompts
$ /opt/media/media/8.53/patch.02/cd85302/Disk1/
Patch Install Prompts

On Change Assistant VM

Install all tools options to D:\PT.853
Install application to D:\HCM92

Install 8.53.02 patch to D:\PT.853

Try out DB wizard for 8.53

Install 8.53 and 8.53.02 patch to /u01/psoft/pt853
Install HCM 9.2 to /u01/psoft/hcm92
Install Tuxdo Full Install to /u01/tux

# mkdir /u01/tux
# chown oracle:oracle /u01/tux/
$ export PS_HOME=/u01/psoft/pt853; export PS_APP_HOME=/u01/psoft/hcm92
$ . $PS_HOME/
$ . /u01/tux/tuxedo11gR1/tux.env

Database prereqs
$ mkdir /u01/app/oracle/oradata/HCM92
$ mkdir /u01/app/oracle/admin/HCM92
$ mkdir /u01/app/oracle/admin/HCM92/pfile
$ mkdir /u01/app/oracle/admin/HCM92/adump
$ mkdir /u01/app/oracle/fast_recovery_area/HCM92
$ orapwd file=$ORACLE_HOME/dbs/orapwHCM92 entries=5
$ vi $PS_HOME/scripts/unix/createdb10.sql
$ vi $PS_HOME/scripts/unix/utlspace.sql
$ vi $PS_APP_HOME/scripts/unix/hcddl.sql
$ vi $ORACLE_HOME/network/admin/tnsnames.ora
add HCM92 entry
$ export ORACLE_SID=HCM92
$ cd $PS_HOME/setup/PsMpDbInstall
$ ./

Installation Location: (DEFAULT: /u01/psoft/pt853):
PS_APP_HOME: /u01/psoft/hcm92
database platform: ->1- Non-Unicode Database
Character Set: ->1- Western European ISO 8859-1
Database type: ->1- Demo
PeopleSoft Application: ->1- PeopleSoft HCM Database – US English
sqlplus path: [/u01/app/oracle/product/11.2.0/dbhome_1/bin]:
ORACLE_HOME: [/u01/app/oracle/product/11.2.0/dbhome_1]:
Location of modified scripts: /u01/psoft/hcm92/modifiedscripts
Create or use existing SID: ->1- Create new SID
Oracle SID: HCM92
DatabaseName; HCM92
Mount Point 1: u01
Mount Point 2: u01
Mount Point 3: u01
Enable AutoExtend: ->1- Yes
Peoplesoft owner ID: SYSADM
Peoplesoft owner password: ********
Peoplesoft connect ID: people
Peoplesoft connect password: ********
Peoplesoft default tablespace: [PSDEFAULT]:
Location of init.ora file complete path: [/u01/app/oracle/product/11.2.0/dbhome_1/dbs/initHCM92.ora]:
Appserver User []: PSAPPS
Password []: ********
Webserver User : PTWEBSERVER  * Webserver User name was not a prompt.
Password []: ********
enable or disable all other user profiles: ->2- Enable
Password for other OPRIDs: ->2- I would like to set a different password
Password []: ********
Base Language: ->1- ENG – US English

Failure 1:  ORACLE_SID not set, so hung on
Failure 2:  had undo_tablespace=UNDOTBS1 in initHCM92.ora which did not match psundo name
Failure 3:  tried to do install with only tux client installed, needed full install
Failure 4:  didn’t shutdown running instance from Failure 3

Java process ran at 100% for a while after utlspace, probably parsing output.

SQL> select toolsrel from sysadm.psstatus;

SQL> select count(*) from sysadm.ps_maintenance_log;

Update HCM92 database to 8.53.02

Overall steps, some already complete  As always, read the README file as these steps could change
  1.  Backup pristine database
    1.  Shutdown immediate
    2.  startup mount
    3.  rman target /
    4.  configure controlfile autobackup on;
    5.  configure device type disk parallelism 2 backup type to compressed backupset;
    6.  backup database;
    7.  SQL> alter database open;
  2.  Download and extract patch
  3.  Shutdown all processes for ENV to patch
  4.  Backup existing Tools directories
  5.  Install patch files
  6.  Update database patch version (PS_MAINTENANCE_LOG entry)
    1.  run %PS_HOME%\scripts\ptpatch.dms
  7.  Apply patch project
    1.  Launch patched App Designer
    2.  Tools -> Copy Project -> From File
    3.  %PS_HOME%\projects select PATCH853
    4.  select Common and English language only
    5.  Copy the project
    6.  Build project
      1.  Build Options: create tables/view, alter tables, create script only
      2.  Create Settings: Skip table, recreate view, recreate index only if modified
      3.  Alter Settings: Drop Column, truncate data, add/change/rename/delete, alter by rename
      4.  Script settings: write alter comments, split scripts and change path if desired
    7.  Edit generated SQL script if needed
    8.  Run Script
  8.  Load Messages and Data Project (Skipped, no new script delivered)
    1.  run %PS_HOME%\scripts\msgtlsupg.dms via Data Mover in bootstrapmode
  9.  Multilingual steps (Skipped, not running ML)
    1.  Load Translations: Copy PATCH853ML to Database via App Designer
    2.  Load Messages: Run %PS_HOME%\scripts\msgtl<lang_cd>.dms via Data Mover
  10.  Reinstall needed apps and reconfigure
    1.  Change Assistant
    2.  PIA -> Redeploy
    3.  PeopleSoft Test Framework
    4.  Client tools
    5.  Clear rowset cache; run %PS_HOME%\scripts\clear_rowset_cache.dms
    6.  Purge App/Web cache
    7.  Re-create app domains (you may miss new options if ony only reconfigure)
    8.  restart processes
  11. Take database backup

Webserver detected with incorrect Version of JDK

Now that PeopleTools 8.53 is out, I’ve seen people that are doing PIA installs posting about this problem a few places.

The only  reason I’ve seen so far for this error is the value for JAVA_HOME is not properly set in $WL_HOME/wlserver_10.3/common/bin/  This is set when performing the install of Weblogic.  Fix this and try to install PIA again.

To fix it, look at commEnv file, and find where JAVA_HOME is set.  Double check that it’s the right location to the JDK 7 location.  PeopleTools 8.53 now requires JDK 7 and it is available with the rest of the PeopleTools downloads on Oracle’s Edelivery site.  However, the version provided on edelivery is an rpm and by default will install to /usr/java.  If you are like me, you may want to install this JDK for Weblogic at a specific location.  If that’s the case, I recommend skipping the JDK rpm from edelivery and grab the JDK tarball from the OTN download site.  Download the tar.gz version and do what you want with it.  If you do not have root access this will be helpful too as the rpm installer will want you to be root.  If you do want to use the rpm you can use the – -prefix  (2 dashes without a space) option to install to another location. You’ll still need to be root and it will still place some things in /etc.

I still prefer just extracting the tarball.  There is something to be said about the simplicity of it.  If you:

  1. install the tarball
  2. export JAVA_HOME=/path/to/jdk
  3. install Weblogic with $JAVA_HOME/bin/java -jar /path/to/wls1036_generic.jar -whatever -other -options you want
  4. source and run $PS_HOME/setup/PsMpPIAInstall/

You should have no problems, it worked fine for me on OEL 5.8.  If you used the RPM and are still having problems.  Try running as root

/usr/sbin/alternatives --config java

Which will change system wide the default version of java used.  But you shouldn’t have this problem if you used my method above.

Hope this helps.

Reload Web Profile

Today I’m writing about a simple trick I use when I need to reload web profiles.  This is documented several places, but I’ve referenced reloading the web profile this way in previous posts so I’m adding it here.

PeopleSoft has the ability to reload the web profile on the fly through a command to the psp servlet.  That command is conveniently, ReloadConfig.  The command is specified on the URL like this ?cmd=ReloadConfig. The command itself is case insensitive.  You could use ?cmd=reloadconfig just as easily as ?cmd=RELOADCONFIG (cmd itself IS case sensitive).

webprofileIn order to use this feature you must have the auditPWD value defined on the custom properties of the currently used Web Profile.  The default password is “dayoff” and this feature is delivered enabled on the DEV and TEST Web Profiles.

Putting it all together we get a URL Query String like this. ?cmd=ReloadConfig&pwd=dayoff

The command can be specified anywhere after the site name.  I most commonly just specify it directly after the site name like this. Config Complete

Once you run the command you’ll get a message back indicating the Config was reloaded and it will list the number of active sessions impacted.

Another command I use is ViewConfig which allows you to view the Web Profile config, I don’t use this one all that often, but I have used it in the past.  It’s specified the same way

There’s are a few other commands available as well, however I’ve not used them nearly as much.  There is a purge command which clears web cache, but it only purges in memory cache on the web server.  It will not clear disk cache that the web server has built.